Hypertext Transfer Protocol (HTTP) 1.0 Hypertext Transfer Protocol (HTTP) Tim Berners-Lee, CERN Internet Draft Expires 5 May 1994 5 Nov 1993 Hypertext Transfer Protocol (HTTP) A Stateless Search, Retrieve and Manipulation Protocol Status of this memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are working documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". This document is a DRAFT specification of a protocol in use on the internet and to be proposed as an Internet standard. Discussion of this protocol takes place on the www-talk@info.cern.ch mailing list -- to subscribe mail to www-talk-request@info.cern.ch. Distribution of this memo is unlimited. Abstract HTTP is a protocol with the lightness and speed necessary for a distributed collaborative hypermedia information system. It is a generic stateless object-oriented protocol, which may be used for many similar tasks such as name servers, and distributed object-oriented systems, by extending the commands, or "methods", used. A feature if HTTP is the negotiation of data representation, allowing systems to be built independently of the development of new advanced representations. Note: This specification This HTTP protocol is an upgrade on the original protocol as implemented in the earliest WWW releases. It is back-compatible with that more limited protocol. This specification includes the following parts: The Request Methods A list of headers in the request message The response Status codes A list of headers on any object transmitted The content of any object content transmitted Format negotiation algorithm The HTTP Registration Authority Security Considerations Unresolved points References The following notes form recommended practice not part of the specification: Servers tolerating clients Clients tolerating servers Purpose When many sources of networked information are available to a reader, and when a discipline of reference between different sources exists, it is possible to rapidly follow references between units of information which are provided at different remote locations. As response times should ideally be of the order of 100ms in, for example, a hypertext jump, this requires a fast, stateless, information retrieval protocol. Practical information systems require more functionality than simple retrieval, including search, front-end update and annotation. This protocol allows an open-ended set of methods to be used. It builds on the discipline of reference provided by the Universal Resource Identifier (URI) as a name (URN, RFCxxxx) or address (URL, RFCxxxx) allows the object of the method to be specified. Reference is made to the Multipurpose Internet Mail Extensions (MIME, RFC1341) which are used to allow objects to be transmitted in an open variety of representations. Overall operation On the internet, the communication takes place over a TCP/IP connection. This does not preclude this protocol being implemented over any other protocol on the internet or other networks. In these cases, the mapping of the HTTP request and response structures onto the transport data units of the protocol in question is outside the scope of this specification. It should not however be at all complicated. The protocol is basically stateless, a transaction consisting of Connection The establishment of a connection by the client to the server - when using TCP/IP port 80 is the well-known port, but other non-reserverd ports may be specified in the URL; Request The sending, by the client, of a request message to the server; Response The sending, by the server, of a response to the client; Close The closing of the connection by either both parties. The format of the request and response parts is defined in this specification. Whilst header information defined in this specification is sent in ISO Latin-1 character set in CRLF terminated lines, object transmission in binary is possible. Character sets In all cases in HTTP where RFC822 characters are allowed, these may be extended to use the full ISO Latin 1 character set. 8-bit transmission is always used. tableofcontents REQUEST The request is sent with a first line containing the method to be applied to the object requested, the identifier of the object, and the protocol version in use, followed by further information encoded in the RFC822 header style. The format of the request is: Request = SimpleRequest | FullRequest SimpleRequest = GET CrLf FullRequest = Method UR ProtocolVersion CrLf [*] [ ] = ProtocolVersion = HTTP/V1.0 uri = = : = MIME-conforming-message The URI is the Uniform Resource Locator (URL) as defined in the specification, or may be (when it is defined) a Uniform Resource Name (URN) when a specification for this is settled, for servers which support URN resolution. Unless the server is being used as a gateway, a partial URL shall be given with the assuptions of the protocol (HTTP:) and server (the server) being obvious. The URI should be encoded using the escaping scheme described in the URL specification to a level such that (at least) spaces and control characters (decimal 0-31 and 128-159) do not appear unesacaped. Note. The rest of an HTTP url after the host name and optional port number is completely opaque to the client: The client may make no deductions about the object from its URL. Protocol Version The Protocol/Version field defines the format of the rest of the request.. At the moment only HTRQ is defined . If the protocol version is not specified, the server assumes that the browser uses HTTP version 0.9. Uniform Resource Identifier This is a string identifying the object. It contains no blanks. It may be a Uniform Resource Locator [ URL ] defining the address of an object as described in RFCxxxx, or it may be a representation of the name of an object (URN, Universal Resource Name) where that object has been registered in some name space. At the time of writing, no suitable naming system exists, but this protocol will accept such names so long as they are distinguishable from the existing URL name spaces. Methods Method field indicates the method to be performed on the object identified by the URL. More details are with the list of method names below . Request Headers These are RFC822 format headers with special field names given in the list below , as well as any other HTTP object headers or MIME headers. Object Body The content of an object is sent (depending on the method) with the request and/or the reply. Methods The Method field in HTTP indicates the method to be performed on the object identified by the URL. The method GET below is always supported, The list of other methods acceptable by the object are returned in response to either of these two requests. This list may be extended from time to time by a process of registration with the design authority. Method names are case sensitive. Currently specified methods are as follows: GET means retrieve whatever data is identified by the URI, so where the URI refers to a data-producing process, or a script which can be run by such a process, it is this data which will be returned, and not the source text of the script or process. Also used for searches . HEAD is the same as GET but returns only HTTP headers and no document body. CHECKOUT Similar to GET but locks the object against update by other people. The lock may be broken by a higher authority or on timeout: in this case a future CHECKIN will fail. ( Phase out? ) SHOWMETHOD Returns a description (perhaps a form) for a given method when applied to the given object. The method name is specified in a For-Method: field. (TBS) PUT specifies that the data in the body section is to be stored under the supplied URL. The URL must already exist. The new contenst of the document are the data part of the request. POST and REPLY should be used for creating new documents. DELETE Requests that the server delete the information corresponding to the given URL. After a successfull DELETE method, the URL becomes invalid for any future methods. POST Creates a new object linked to the specified object. The message-id field of the new object may be set by the client or else will be given by the server. A URL will be allocated by the server and returned to the client. The new document is the data part of the request. It is considered to be subordinate to the specified object, in the way that a file is subordinate to a directory containing it, or a news article is subordinate to a newsgroup to which it is posted. LINK Links an existing object to the specified object. UNLINK Removes link (or other meta-) information from an object. CHECKIN Similar to PUT, but releases the lock set on the object. Fails if no lock has been set by CHECKOUT. Suggestion : phase out this (rcs-like) model in favor of the PUT (cvs-like, non-locking) model of code management. TEXTSEARCH The object may be queried with a text string. The search form of the GET method is used to query the object. SPACEJUMP The object will accept a query whose terms are the cooridnates of a point within the object. The method is implemented using GET with a derived URL . SEARCH Proposed only. The index (etc) identified by the URL is to be searched for something matching in some sense the enclosed message. How does the client know what message fromats are acceptable to the server? (Suggestion of Fred Williams) (Some of these methods require more detailed specification) Note: case sensitivity of method names Although lack of case sensitivity in methos names would be a tolerant approach with a limited method set, we require the extensibility of HTTP to cover an arbitrary underlying object system. In such a system, method names may be case sensitive, and so we must preserve case in HTTP. GET A representation of the object is transferred to the client. Some URIs refer to specific variants of an object, and some refer to objects with many variants. In the latter case, the representations, encodings, and languages acceptable may be specified in the header request fields, and may affect the particular value which is returned. Other possible replies allow a set of URIs to be returned to the client, who may use them to retrieve the object. This allows name servers to be implemented using HTTP, and also forwarding address to be given when objects have been moved. Annotation replies Some servers keep 'parallel webs" -- separate stores of information about other server's objects. Typically this incldues annotation links. This information may be retrieved using the GET method, but a special reply is returned. Searching using GET When the TEXTSEARCH or SPACEJUMP methods are supported, their implementation is in fact by means of the GET method, by constructing a derived URL. The URL used with GET is the URL of the object, suffixed by a "?" character and the text to be searched. If the object being searched is in fact itself the result of a search (ie the URL contains a "?"), then those search terms are first stripped off, so the search is performed on the original object. In the URL, keywords are seperated with plus signs ("+"). Real spaces, plus signs, and other illegal characters [who defines illegal characters?] are represented as hexadecimal ASCII escape sequences (%##, e.g., space = %20, plus = %2B) Browsers accepting text input should define keywords as seperated by spaces (and therefore map them to plus signs). More advanced browsers may allow separate keyword input and, therefore, a finer level of control over the content without users needing to understand the underlying mechanisms (e.g., that they must use %20 to get a real space). Examples The following is a request on an object supporting TEXTSEARCH: GET /indexes/botany?annual+plants HTTP/1.0 This request on an object supporting SPACEJUMP selects point (0.2,3.8) within a map: GET /maps/uk/dorset/winspit/0.2+3.8 HTTP/1.0 LINK The link method of HTTP adds meta information (Object header information) to an object, without touching the object's content. For example, it requests the creation of a link from the specified object to another object. The request is followed by a set of object headers which are to be added. In cases in which a new header is added and the semantics of the header do not allow it to coexist with a similar header, then the previous header is deleted. For example, an object may only have one title, so specifying a title overwrites and preexsiting title. Link Types The link type unless void is specified in the WWW-Link object field for each link. If not specified, void is assumed. Unresolved points As this is generalised to allow any metainformation to be added, a better name might be DESCRIBE or attribute (as a verb). I don't like "describe" as it does not suggest alteration. "Bestow"/"Rescind" might be better. For example, one could bestow a title or author on something previously title-less. We are looking at a general data model behind here a little like a relational database. This function adds records. "Set" and "Reset"? Related Methods LINK is like POST except that no storage is requested for the destination object, and the destination is not assumed to be subordinate to the specified object. See also: UNLINK. Tim BL POST This method of HTTP creates a new object linked to and subordinate to the specified object. The content of the new object is enclosed as the body of the request. The POST method is desiged to allow a uniform function to cover Annotation existing documents; Posting a message to a bulletin board topic, newsgroup, mailing list, or similar group of articles; Adding a file to a directory; Extending a document during authorship. The client may not assume any postconditions of the method in terms of web topology. For example, if a POST is accepted, the effect may be delayed or overruled by human moderation, batch processing, etc. The client should not be surprised if a link is not immediately (or never) created. However, the semantics are a request for a link to be made from the object whose URL is quoted to the new, enclosed, object. If no URL for the NEW object is given by the client, the server is requested to see to the storage of the new object. That is, the server does not have to store it but will have to return a URL be which it can later be retrieved. The semantics of this method (currently) imply nothing of any undertakings by the server to maintain the availability of the object. If the client gives a URL, then the server is not obliged to store the object, but may take a copy and may in that case issue a new URL. Return object headers The method shall return a set (possibly empty) of object headers for the newly posted object. If a URL has been assigned by the server, then that may be included. Similarly, if a URN has been assigned, then that shall be returned. Other things which may be returned include for example the expiry-date if any. The server may return the entire metadata for the object (as in the HEAD command), or a subset of it. The object body shall not be returned, so the transaction shall end with the blank line terminating the headers. Link type The link type may be specified by explicitly giving a (reverse) link in the object header of the linked object. If a link or links between the two objects are present in those headers, then that link is used. If no such link is specified, then the server should generate a link. The link type in this case is determined by the server. The server may perform other operations as a result of the new object being added: lists and indexes might be updated, for example. Submission When articles are submitted, the analogy of being addeed to a body of knowledge by being linked is close. When a form is submitted, this can be done with POST, though in this case side-effects will be expected. (Should submission for action have a different method -- see showmethod -- or should it be just POST for simplicity? When interfacing with other systems such as bews and mail, the distinction is not made as the system does not have the ability to distinguish different methods. We now have a possibility of making a separate action, though.) Unresolved points The client has no way of knowing what data formats the server is prepared to accept. This may not be a serious problem, but it may be if the server has some restrictions. This applies to all submissions of object content from client to server, for all methods. Related methods. When a new URL has been returned by the server, it may in general (typically, but not necessarily) be usable as the argument of DELETE , GET , PUT , etc, methods. To make a link between two existing objects, see LINK. Tim BL SEARCH Some correspondance about SEARCH: Q How did the client know that the server could search for tex? Maybe t his server can only serach for text and GIF patterns, even though it g ave out tex. How can the client know that a GIF search is possible? Answer I assume the following has happened: client requests with ACCEPT: text/x-TeX If the server, which it should if possible, replies with the doc requested in ``TeX''. Therefore a server can obviously do an ``internal representation'' to ``TeX'' conversion. Since the server responded in a particular representation (ie TeX) The client should be able to search in ``TeX'' provide the ``SEARCH'' method is in the required ALLOWED: section of the response. The server should only respond with ALLOWED: SEARCH ... if it can do a Tex to ``internal representation'' conversion for searching. Fred Williams fwilliam@ccs.carleton.ca SHOWMETHOD When an object can support more operations than are defined in this specification, SHOWMETHOD allows a client to understand the interface to that operation sufficiently to allow the user to perform it interactively. Required parameter field For-Method: This filed contains only the method name about which the client is inquiring. Preconditions The methodname spacified in the For-Method field must have been previously issued in a "Allowed:" field returned with the given object. The client should specify an Accept: field which includes at least one form langauge it it wants to be able to interpret the result. Postcondidtion SHOWMETHOD returns, if possible, a form in a representation acceptable to the client. This form will contain instructions for ordering the operation, and fields for the parameters. A suitable language for the form might be HTTP2, but any language may be used which is acceptable to the client. SPACEJUMP This method is similar to the TEXTSEARCH method, but instead of the search criterion being a text string, it is a set of coordinates defining a point within the image. The semantics of the operation are not defined here. Typically, the user clicks on a point within the image with a mouse or other pointing device. Two or more coordinates are supplied, in the order x, y z, t. All coordinates are scaled so that 0 represents the bottom left hand point and 1.0 represents the top right hand point. The z access direction follows the normal right-hand rule, that is extends toward the viewer when the x and y axes are flat as in the normal two-dimensional representation. In the case of a time-occupying object, 0 represents the starting instance, and 1.0 represents the finishing instant. The method is implemented using GET with a derived URL . TEXTSEARCH This is a simple form of search. The text is assumed to derive from the requesting user, and is in no special format. The exact algorithm to be applied is not defined in this specification, but techniques such as vocabulary proximity matching between the request data portion and the contents or titles of documents, keyword matching, stemming, and the use of a thesaurus are quite appropriate. Whilst this method name is given as a flag to specify that the function is available, the search form of the GET method is in fact used to query the object. UNLINK This method deletes metainformation about an object. The request contains object geaders which are to be removed. Only headers exactly matching the headers given are removed. Obviously the operation may be used for unlinking objects. It may also be used for removing other metainformation such as object title, expiry date, etc. Related methods See LINK. Tim BL HTTP Request fields These header lines are sent by the client in a HTTP protocol transaction. All lines are RFC822 format headers. The list of headers is terminated by an empty line. FROM: In Internet mail format, this gives the name of the requesting user. This field may be used for logging purposes and an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsability for the method performed. The Internet mail address in this field does not have to correspond to the internet host which issued the request. (For example, when a request is passed through a gateway, then the original issuer's address should be used). The mail address should, if possible, be a valid mail address, whether or not it is in fact an internet mail address or the internet mail representation of an address on some other mail system. ACCEPT: This field contains a comma-separated list of representation schemes (Content-Type metainformation values) which will be accepted in the response to this request. The set given may of course vary from request to request from the same user. This field may be wrapped onto several lines according to RCFC822, and also more than one occurence of the field is allowed with the signifiance being the same as if all the entries has been in one field. The format of each entry in the list is (/ meaning "or") = Accept: *[ ; ] = *[ , ] = = = q / mxs / mxb = See the appendix on the negotiation algorithm as a function and penalty model. If no Accept: field is present, then it is assumed that text/plain and text/html are accepted. Example Accept: text/plain; text/html Accept: text/x-dvi, q=.8, mxb=100000, mxt=5.0; text/x-c Wildcards In order to save time, and also allow clients to receive content types of which they may not be aware, an asterisk "*" may be used in place of either the second half of the content-type value, or both halves. This only applies to the Accept: filed, and not to the content-type field of course. Example Accept: *.*, q=0.1 Accept: audio/*, q=0.2 Accept: audio/basic q=1 may be interpreted as "if you have basic audio, send it; otherwise send me some other audio, or failing that, just give me what you've got." ACCEPT-ENCODING: Similar to Accept, but lists the Content-Encoding types which are acceptable in the response. = Accept-Encoding: *[ , ] = *[ , ] Example Accept-Encoding: x-compress; x-zip ACCEPT-LANGUAGE: Similar to Accept, but lists the Language values which are preferable in the response. A response in an unspecifies language is not illegal. See also: Language . Language coding TBS. (ISO standard xxxx) USER-AGENT: This line if present gives the software program used by the original client. This is for statistical purposes and the tracing of protocol violations. It should be included. The first white space delimited word must be the software product name, with an optional slash and version designator. Other products which form part of the user agent may be put as separate words. = User-Agent: + = [/] = Example: UserAgent: LII-Cello/1.0 libwww/2.5 REFERER: This optional header field allows the client to specify, for the server's benefit, the address ( URI ) of the document (or element within the document) from which the URI in the request was obtained. This allows a server to generate lists of back-links to documents, for interest, logging, etc. It allows bad links to be traced for maintenance. If a partial URI is given, then it should be parsed relative to the URI of the object of the request. Example: Referer: http://info.cern.ch/hypertext/DataSources/Over view.html AUTHORIZATION: If this line is present it contains authorization information. The format is To Be Specified (TBS). The format of this field is in extensible form. The first word is a specification of the authorisation system in use. Proposals have been as follows: (see the specification for current one implemented by AL Sep 1993) User/Password scheme Authorization: user fred:mypassword The scheme name is "user". The second word is a user name (typically derived from a USER environment variable or prompted for), with an optional password separated by a colon (as in the URL syntax for FTP). Without a password, this povides very low level security. With the password, it provides a low-level security as used by unmodified FTP, Telnet, etc. Kerberos Authorization: kerberos kerberosauthenticationsparam eters The format of the kerberosauthenticationsparameters is to be specified. CHARGETO: This line if present contains account information for the costs of the application of the method requested. The format is TBS. The format of this field must be in extensible form. The first word starts with a specification of the namespace in which the account is . (This is similar to extensible URL definition.) No namespaces are currently defined. Namespaces will be registered with the registration authority . The format of the rest of the line is a function of the charging system, but it is recommended that this include a maximum cost whose payment is authorized by the client for this transaction, and a cost unit. Note: Server tolerance of bad clients Whilst it is seen appropriate for testing parsers to check full conformance to this specification, it is recommended that operational parsers be tolerant of deviations. In particular, lines should be regarded as terminated by the Line Feed, and the preceeding Carriage Return character ignored. Any HTTP Header Field Name which is not recognised should be ignored in operational parsers. It is recommended that servers use URIs free of "variant" characters whose representation differs in some of the national variant character sets, punctuation characters, and spaces. This will make URIs easier to handle by humans when the need (such as debugging, or transmission through non hypertext systems) arises. RESPONSE The response from the server shall start with the following syntax (See also: note on client tolerance ): ::= ::= 3* ::= 3* ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ::= * identifies the HyperText Transfer Protocol version being used by the server. For the version described by this document version it is "HTTP/1.0" (without the quotes). < status code > gives the coded results of the attempt to understand and satisfy the request. A three digit ASCII decimal number. gives an explanation for a human reader, except where noted for particular status codes. Fields on the status line are delimited by a single blank (parsers should accept any amount of white space). The possible values of the status code are listed below . Response headers The headers on returned objects those RFC822 format headers listed as object headers , as well as any MIME conforming headers, notably the Content-Type field. Note that this specification doesnot define any headers particular to the response which are not also apropriate to any transmission of an object with a request. Response data Additional information may follow, in the format of a MIME message body. The significance of the data depends on the status code. The Content-Type used for the data may be any Content-Type which the client has expressed his ability to accept, or text/plain, or text/html. That is, one can always assume that the client can handle text/plain and text/html. Status codes The values of the numeric status code to HTTP requests are as follows. The data sections of messages Error, Forward and redirection responses may be used to contain human-readable diagnostic information. SUCCESS 2XX These codes indicate success. The body section if present is the object returned by the request. It is a MIME format object. It is in MIME format, and may only be in text/plain, text/html or one fo the formats specified as acceptable in the request. OK 200 The request was fulfilled. CREATED 201 Following a POST command, this indicates success, but the textual part of the response line indicates the URI by which the newly created document should be known. Accepted 202 The request has been accepted for processing, but the processing has not been completed. The request may or may not eventually be acted upon, as it may be disallowed when processing actually takes place. there is no facility for status returns from asynchronous operations such as this. Partial Information 203 When received in the response to a GET command, this indicates that the returned metainformation is not a definitive set of the object from a server with a copy of the object, but is from a private overlaid web. This may include annotation information about the object, for example ERROR 4XX, 5XX The 4xx codes are intended for cases in which the client seems to have erred, and the 5xx codes for the cases in which the server is aware that the server has erred. It is impossible to distinguish these cases in general, so the difference is only informational. The body section may contain a document describing the error in human readable form. The document is in MIME format, and may only be in text/plain, text/html or one for the formats specified as acceptable in the request. Bad request 400 The request had bad syntax or was inherently impossible to be satisfied. Unauthorized 401 The parameter to this message gives a specification of authorization schemes which are acceptable. The client should retry the request with a suitable Authorization header. PaymentRequired 402 The parameter to this message gives a specification of charging schemes acceptable. The client may retry the request with a suitable ChargeTo header. Forbidden 403 The request is for something forbidden. Authorization will not help. Not found 404 The server has not found anything matching the URI given Internal Error 500 The server encountered an unexpected condition which prevented it from fulfilling the request. Not implemented 501 The server does not support the facility required. REDIRECTION 3XX The codes in this section indicate action to be taken (normally automatically) by the client in order to fulfill the request. Moved 301 The data requested has been assigned a new URI, the change is permanent. (N.B. this is an optimisation, which must, pragmatically, be included in this definition. Browsers with link editing capabiliy should automatically relink to the new reference, where possible) The response contains one or more header lines of the form URI: String CrLf Which specify alternative addresses for the object in question. The String is an optional comment field. If the response is to indicate a set of variants which each correspond to the requested URI, then the multipart/alternative wrapping may be used to distinguish different sets Found 302 The data requested actually resides under a different URL, however, the redirection may be altered on occasion (when making links to these kinds of document, the browser should default to using the Udi of the redirection document, but have the option of linking to the final document) as for "Forward". The response format is the same as for Moved . Method 303 Method: body-section Like the found response, this suggests that the client go try another network address. In this case, a different method may be used too, rather than GET. The body-section contains the parameters to be used for the method. This allows a document to be a pointer to a complex query operation. @@TBS in more detail. The body may be preceded by the following additional fields as listed . Object MetaInformation The header fields given with or in relation to objects in HTTP are as follows. All are optional. These headers specify metainformation: that is, information about the object, not the information which is contained in the object. There is no reason for limiting these fields to HTTP use, as any other system which requires metainformation is encouraged to use them. The order of header lines withing the HTTP header has no significance. However, those fields which are not MIME fields should occur before the MIME fields, so that the MIME fields and following form a valid MIME document. This is not mandatory. Any header fields which are not understood should be ignored. (TBS in more detail) ALLOWED: *METHOD Lists the set of requests which the requesting user is allowed to issue for this URL. If this header line is omitted, the default allowed methods are "GET HEAD" Example of use: Allow: GET HEAD PUT PUBLIC: *METHOD As "Allow" but lists those requests which anyone may use. If omitted, the default is "GET" only. Example of use: Public: GET HEAD TEXTSEARCH CONTENT-LENGTH: INT Implies that the body is binary and should be read directly from the communications link, without parsing lines, etc. When the data is part of the request, prevents the escaping and de-escaping of the termination sequence . @@@ This should be part of the MIME header, as it applies to any binary encoded part. Note HTML is the first internet protocol to allow MIME "binary" encoding. In MIME, the use of Content-Length is currently allowed only for external messages. CONTENT-TYPE: As defined in MIME, except where noted here. Extra non-MIME types It is reasonable to put strict limits on transfer formats for mail, where there is no guarantee that the receiver will understand a weird format. However, in HTTP one knows that the receiver will be able to receive it because it will have been sent in the Accept: field. There is therefore a lot to be gained from a very complete registry of well-defined types for HTTP which may nevertheless not be recommended for mail. In this case, the content-type list for HTTP may be a superset of the MIME list. The x- convention for experimental types is of course still available as well. Type parameters Parameters on the content type are extremely useful for describing resolutions, colour depths, etc. They will allow a client to specify in the Accept: field the resolution of its device. This may allow the server to economise greatly on transmission time by reducing the resultion of an image, for example. These parameters are to be specified when types are registered.. @@ TBS. Multipart types MIME provides for a number of "multipart" types. These are encapsulations of several body parts in the one message. In HTTP,