*** draft-ietf-http-v10-spec-01.txt Sat Aug 5 10:52:50 1995 --- draft-ietf-http-v10-spec-02.txt Mon Aug 14 11:20:44 1995 *************** *** 2,5 **** INTERNET-DRAFT R. Fielding, UC Irvine ! H. Nielsen, MIT/W3C ! Expires February 3, 1996 August 3, 1995 --- 2,5 ---- INTERNET-DRAFT R. Fielding, UC Irvine ! H. Frystyk, MIT/W3C ! Expires February 13, 1996 August 13, 1995 *************** *** 48,51 **** HTTP has been in use by the World-Wide Web global information ! initiative since 1990. This specification reflects preferred usage ! of the protocol referred to as "HTTP/1.0". --- 48,51 ---- HTTP has been in use by the World-Wide Web global information ! initiative since 1990. This specification reflects common usage of ! the protocol referred to as "HTTP/1.0". *************** *** 68,80 **** 3.3 Date/Time Formats ! 3.3.1 Full Date ! 3.3.2 Delta Seconds ! 3.4 Media Types ! 3.4.1 Canonicalization and Text Defaults ! 3.4.2 Multipart Types ! 3.5 Character Set Encodings ! 3.6 Encoding Mechanisms ! 3.7 Transfer Encodings ! 3.8 Language Tags ! 3.9 Quality Values ! 3.10 Product Tokens --- 68,75 ---- 3.3 Date/Time Formats ! 3.4 Coded Character Sets ! 3.5 Encoding Mechanisms ! 3.6 Media Types ! 3.6.1 Canonicalization and Text Defaults ! 3.6.2 Multipart Types ! 3.7 Product Tokens *************** *** 91,96 **** 5.2.3 POST - 5.2.4 PUT - 5.2.5 DELETE - 5.2.6 LINK - 5.2.7 UNLINK 5.3 Request-URI --- 86,87 ---- *************** *** 115,164 **** 8. Header Field Definitions ! 8.1 Accept ! 8.2 Accept-Charset ! 8.3 Accept-Encoding ! 8.4 Accept-Language ! 8.5 Allow ! 8.6 Authorization ! 8.7 Content-Encoding ! 8.8 Content-Language ! 8.9 Content-Length ! 8.10 Content-Transfer-Encoding ! 8.11 Content-Type ! 8.12 Date ! 8.13 Expires ! 8.14 Forwarded ! 8.15 From ! 8.16 If-Modified-Since ! 8.17 Last-Modified ! 8.18 Link ! 8.19 Location ! 8.20 MIME-Version ! 8.21 Orig-URI ! 8.22 Pragma ! 8.23 Public ! 8.24 Referer ! 8.25 Retry-After ! 8.26 Server ! 8.27 Title ! 8.28 URI ! 8.29 User-Agent ! 8.30 WWW-Authenticate ! 9. Content Negotiation ! 10. Access Authentication ! 10.1 Basic Authentication Scheme ! 11. Security Considerations ! 11.1 Authentication of Clients ! 11.2 Idempotent Methods ! 11.3 Abuse of Server Log Information ! 11.4 Transfer of Sensitive Information ! 12. Acknowledgments ! 13. References - 14. Authors' Addresses - Appendix A. Internet Media Type message/http --- 106,140 ---- 8. Header Field Definitions ! 8.1 Allow ! 8.2 Authorization ! 8.3 Content-Encoding ! 8.4 Content-Length ! 8.5 Content-Type ! 8.6 Date ! 8.7 Expires ! 8.8 From ! 8.9 If-Modified-Since ! 8.10 Last-Modified ! 8.11 Location ! 8.12 MIME-Version ! 8.13 Pragma ! 8.14 Referer ! 8.15 Server ! 8.16 User-Agent ! 8.17 WWW-Authenticate ! 9. Access Authentication ! 9.1 Basic Authentication Scheme ! 10. Security Considerations ! 10.1 Authentication of Clients ! 10.2 Idempotent Methods ! 10.3 Abuse of Server Log Information ! 10.4 Transfer of Sensitive Information ! 11. Acknowledgments ! 12. References ! 13. Authors' Addresses Appendix A. Internet Media Type message/http *************** *** 170,174 **** C.1.1 Representation of Line Breaks ! C.1.2 Default Character Set Encoding ! C.2 Default Content-Transfer-Encoding C.3 Introduction of Content-Encoding --- 146,151 ---- C.1.1 Representation of Line Breaks ! C.1.2 Default Coded Character Set ! C.2 Conversion of Date Formats C.3 Introduction of Content-Encoding + C.4 No Content-Transfer-Encoding *************** *** 184,191 **** by the World-Wide Web global information initiative since 1990. ! This specification reflects preferred usage of the protocol ! referred to as "HTTP/1.0". This specification does not necessarily ! reflect the "current practice" of any single HTTP server or client ! implementation. It does, however, seek to remain compatible with ! existing implementations wherever possible, and is the reference ! for future implementations of HTTP/1.0. --- 161,167 ---- by the World-Wide Web global information initiative since 1990. ! This specification reflects common usage of the protocol referred ! to as "HTTP/1.0". This specification is not intended to become an ! Internet standard; rather, it defines those features of the HTTP ! protocol that can reasonably be expected of any implementation ! which claims to be using HTTP/1.0. *************** *** 195,201 **** to indicate the purpose of a request. It builds on the discipline ! of reference provided by the Uniform Resource Identifier (URI) [3], ! as a location (URL) [5] or name (URN) [18], for indicating the resource on which a method is to be applied. Messages are passed in ! a format similar to that used by Internet Mail [8] and the ! Multipurpose Internet Mail Extensions (MIME) [6]. --- 171,177 ---- to indicate the purpose of a request. It builds on the discipline ! of reference provided by the Uniform Resource Identifier (URI) [2], ! as a location (URL) [4] or name (URN) [16], for indicating the resource on which a method is to be applied. Messages are passed in ! a format similar to that used by Internet Mail [7] and the ! Multipurpose Internet Mail Extensions (MIME) [5]. *************** *** 203,206 **** various gateways, allowing hypermedia access to existing Internet ! protocols like SMTP [14], NNTP [12], FTP [16], Gopher [2], and ! WAIS [9]. HTTP/1.0 is designed to allow such gateways, via proxy servers, without any loss of the data conveyed by those earlier --- 179,182 ---- various gateways, allowing hypermedia access to existing Internet ! protocols like SMTP [12], NNTP [11], FTP [14], Gopher [1], and ! WAIS [8]. HTTP/1.0 is designed to allow such gateways, via proxy servers, without any loss of the data conveyed by those earlier *************** *** 225,227 **** On the Internet, the communication generally takes place over a ! TCP/IP connection. The default port is TCP 80 [17], but other ports can be used. This does not preclude the HTTP/1.0 protocol from --- 201,203 ---- On the Internet, the communication generally takes place over a ! TCP/IP connection. The default port is TCP 80 [15], but other ports can be used. This does not preclude the HTTP/1.0 protocol from *************** *** 228,242 **** being implemented on top of any other protocol on the Internet, or ! on other networks. The mapping of the HTTP/1.0 request and response ! structures onto the transport data units of the protocol in ! question is outside the scope of this specification. ! For most implementations, the connection is established by the client prior to each request and closed by the server after sending ! the response. However, this is not a feature of the protocol and is ! not required by this specification. Both clients and servers must ! be capable of handling cases where either party closes the ! connection prematurely, due to user action, automated time-out, or ! program failure. In any case, the closing of the connection by ! either or both parties always terminates the current request, ! regardless of its status. --- 204,218 ---- being implemented on top of any other protocol on the Internet, or ! on other networks. HTTP only presumes a reliable transport; any ! protocol that provides such guarantees can be used, and the mapping ! of the HTTP/1.0 request and response structures onto the transport ! data units of the protocol in question is outside the scope of this ! specification. ! Current practice requires that the connection be established by the client prior to each request and closed by the server after sending ! the response. Both clients and servers must be capable of handling ! cases where either party closes the connection prematurely, due to ! user action, automated time-out, or program failure. In any case, ! the closing of the connection by either or both parties always ! terminates the current request, regardless of its status. *************** *** 268,270 **** A network data object or service which can be identified by a ! URI. --- 244,246 ---- A network data object or service which can be identified by a ! URI (Section 3.2). *************** *** 285,287 **** The client program which is closest to the user and which ! initiates requests at their behest. --- 261,265 ---- The client program which is closest to the user and which ! initiates requests at their behest. These are often browsers, ! editors, spiders (web-traversing robots), or other end user ! tools. *************** *** 321,323 **** both prose and an augmented Backus-Naur Form (BNF) similar to that ! used by RFC 822 [8]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented --- 299,301 ---- both prose and an augmented Backus-Naur Form (BNF) similar to that ! used by RFC 822 [7]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented *************** *** 412,415 **** The following rules are used throughout this specification to ! describe basic parsing constructs. The US-ASCII character set ! encoding is defined by [19]. --- 390,393 ---- The following rules are used throughout this specification to ! describe basic parsing constructs. The US-ASCII coded character set ! is defined by [17]. *************** *** 431,435 **** for all protocol elements except the Entity-Body (see Appendix B ! for tolerant applications). The end-of-line marker within an Entity- ! Body is defined by its associated media type, as described in ! Section 3.4. --- 409,413 ---- for all protocol elements except the Entity-Body (see Appendix B ! for tolerant applications). The end-of-line marker within an ! Entity-Body is defined by its associated media type, as described ! in Section 3.6. *************** *** 437,439 **** ! HTTP/1.0 headers can be folded onto multiple lines if the continuation lines begin with linear whitespace characters. All --- 415,417 ---- ! HTTP/1.0 headers may be folded onto multiple lines if the continuation lines begin with linear whitespace characters. All *************** *** 443,444 **** --- 421,425 ---- + However, folding of header lines is not expected by some + applications, and should not be generated by HTTP/1.0 applications. + Many HTTP/1.0 header field values consist of words separated by LWS *************** *** 454,459 **** | "/" | "[" | "]" | "?" | "=" ! | SP | HT ! Comments can be included in HTTP header fields by surrounding the ! comment text with parentheses. --- 435,441 ---- | "/" | "[" | "]" | "?" | "=" ! | "{" | "}" | SP | HT ! Comments may be included in some HTTP header fields by surrounding ! the comment text with parentheses. Comments are only allowed in ! fields containing "comment" as part of their field value definition. *************** *** 462,469 **** - Note: Use of comments within HTTP headers is generally - discouraged, since they are rarely seen by human eyes and - hence only increase network traffic. However, they may be - useful for messages posted or retrieved via NNTP and SMTP - gateways. - A string of text is parsed as a single word if it is quoted using --- 444,445 ---- *************** *** 476,491 **** ! The backslash character ("\") may be used as a single-character ! quoting mechanism only within quoted-string and comment constructs. - quoted-pair = "\" CHAR - - When left unquoted and not within a comment, HTTP uses angle - brackets to delimit machine-processable addresses; any LWS inside - the angle brackets should be ignored. - - addr-string = ( "<" *(qatext) ">" ) - - qatext = ", and CTLs, - but including LWS> - The text rule is only used for descriptive field contents and --- 452,456 ---- ! Single-character quoting using the backslash ("\") character is not ! permitted in HTTP/1.0. The text rule is only used for descriptive field contents and *************** *** 492,496 **** values that are not intended to be interpreted by the message ! parser. Words of *text may contain octets from character set ! encodings other than US-ASCII only when encoded according to the ! rules of RFC 1522 [13]. --- 457,460 ---- values that are not intended to be interpreted by the message ! parser. Words of *text may contain octets from coded character sets ! other than US-ASCII. *************** *** 500,504 **** Recipients of header field text containing octets outside the ! US-ASCII character set encoding may assume that they are ISO-8859-1 ! characters if there is no other encoding indicated by an RFC 1522 ! mechanism. --- 464,467 ---- Recipients of header field text containing octets outside the ! US-ASCII coded character set may assume that they represent ! ISO-8859-1 characters. *************** *** 540,591 **** ! HTTP servers must be able to recognize the format of the ! Request-Line for all lower-version requests, to understand any ! valid request in the format of the immediately-prior major version ! (), to understand any valid request in the format of their ! own native major version () with the same or lower minor ! version, and to respond appropriately with a message within the ! same protocol version used by the client, even when the ! response is simply an error message. ! HTTP clients must be able to recognize the format of the ! Status-Line for all lower-version responses, to understand any ! valid response in the format of the immediately-prior major version ! (), and to understand any valid response in the format of ! their own native major version () with the same or lower ! minor version. The following hypothetical example illustrates the ! required behavior. ! o A valid HTTP/3.5 request is received and the server's native ! protocol version is ! o Less than 3.0: it should attempt to understand the request ! and respond (possibly with an error) in its native format; ! o Major number of 3: It should understand the request and ! respond in its native format; ! o Major number of 4: It should understand the request and ! respond with a version 3 message; ! o Major number higher than 4: It should attempt to understand ! the request and respond (possibly with an error) with a ! version 3 message; - o User agent receives a response to an HTTP/3.5 request, and the - response version is - - o Less than 2.0: It should attempt to understand the response - and unobtrusively warn the user of the version mismatch; - - o 2.0--3.4: It should understand the response and be aware - that its request may not have been fully understood by the - server; - - o 3.5 or higher 3: It should understand the response and can - assume that the server understood all aspects of the request - if the response does not indicate an error; - - o 4.0 or higher: It should attempt to understand the response - and unobtrusively warn the user of the version mismatch. - Proxies must be careful in forwarding requests that are received in --- 503,522 ---- ! HTTP/1.0 servers must: ! o recognize the format of the Request-Line for HTTP/0.9 and ! HTTP/1.0 requests; ! o understand any valid request in the format of HTTP/0.9 or ! HTTP/1.0; ! o respond appropriately with a message in the same protocol ! version used by the client. ! HTTP/1.0 clients must: ! o recognize the format of the Status-Line for HTTP/1.0 responses; ! o understand any valid response in the format of HTTP/0.9 or ! HTTP/1.0. Proxies must be careful in forwarding requests that are received in *************** *** 604,608 **** URIs have been known by many names: WWW addresses, Universal ! Document Identifiers, Universal Resource Identifiers [3], and ! finally the combination of Uniform Resource Locators (URL) [5] and ! Names (URN) [18]. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, --- 535,539 ---- URIs have been known by many names: WWW addresses, Universal ! Document Identifiers, Universal Resource Identifiers [2], and ! finally the combination of Uniform Resource Locators (URL) [4] and ! Names (URN) [16]. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, *************** *** 613,615 **** URIs in HTTP/1.0 can be represented in absolute form or relative to ! some known base URI [10], depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs --- 544,546 ---- URIs in HTTP/1.0 can be represented in absolute form or relative to ! some known base URI [9], depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs *************** *** 653,662 **** ! For more information on URL syntax and semantics, see RFC 1738 [5] ! and RFC 1808 [10]. The BNF above includes characters--all those ! marked as national--not allowed in valid URLs as specified by RFC ! 1738, since HTTP servers are not restricted in the set of ! unreserved characters allowed to represent the rel_path part of ! addresses. In fact, the only real requirement for HTTP is that the ! URI not contain any LWS; any other invalid URI can be identified ! and rejected by the server. --- 584,591 ---- ! For definitive information on URL syntax and semantics, see ! RFC 1738 [4] and RFC 1808 [9]. The BNF above includes national ! characters not allowed in valid URLs as specified by RFC 1738, ! since HTTP servers are not restricted in the set of unreserved ! characters allowed to represent the rel_path part of addresses, and ! HTTP proxies may receive requests for URIs not defined by RFC 1738. *************** *** 687,690 **** - 3.3.1 Full Date - HTTP/1.0 applications have historically allowed three different --- 616,617 ---- *************** *** 697,706 **** The first format is preferred as an Internet standard and ! represents a fixed-length subset of that defined by RFC 1123 [7] ! (an update to RFC 822 [8]). The second format is in common use, but ! is based on the obsolete RFC 850 [11] date format and lacks a four- ! digit year. HTTP/1.0 clients and servers must accept all three ! formats, though they must never generate the third (asctime) ! format. Future clients and servers must only generate the RFC 1123 ! format for representing date/time stamps in HTTP/1.0 requests and ! responses. --- 624,631 ---- The first format is preferred as an Internet standard and ! represents a fixed-length subset of that defined by RFC 1123 [6] ! (an update to RFC 822 [7]). The second format is in common use, but ! is based on the obsolete RFC 850 [10] date format and lacks a four- ! digit year. HTTP/1.0 clients and servers that parse the date value ! should accept all three formats, though they must never generate ! the third (asctime) format. *************** *** 743,747 **** - Comments and/or extra LWS are not permitted inside an HTTP-date - value generated by a conformant application. - Note: HTTP/1.0 requirements for the date/time stamp format --- 668,669 ---- *************** *** 751,766 **** ! 3.3.2 Delta Seconds ! Some HTTP header fields allow a time value to be specified as an ! integer number of seconds, represented in decimal, after the time ! that the message was received. This format should only be used to ! represent short time periods or periods that cannot start until ! receipt of the message. ! delta-seconds = 1*DIGIT ! 3.4 Media Types ! HTTP uses Internet Media Types [15] (formerly referred to as MIME ! Content-Types [6]) in order to provide open and extensible data typing and type negotiation. For mail applications, where there is --- 673,767 ---- ! 3.4 Coded Character Sets ! HTTP uses the same definition of the term "character set" as that ! described for MIME: ! The term "character set" is used in this document to ! refer to a method used with one or more tables to convert ! a sequence of octets into a sequence of characters. Note ! that unconditional conversion in the other direction is ! not required, in that not all characters may be available ! in a given character set and a character set may provide ! more than one sequence of octets to represent a ! particular character. This definition is intended to ! allow various kinds of character encodings, from simple ! single-table mappings such as US-ASCII to complex table ! switching methods such as those that use ISO 2022's ! techniques. However, the definition associated with a ! MIME character set name must fully specify the mapping to ! be performed from octets to characters. In particular, ! use of external profiling information to determine the ! exact mapping is not permitted. ! However, this is more commonly referred to as a coded character ! set. Coded character sets are identified by case-insensitive ! tokens. The complete set of tokens are defined by the IANA ! Character Set registry [15]. However, because that registry does ! not define a single, consistent token for each coded character set, ! we define here the preferred names for those coded character sets ! most likely to be used with HTTP entities. This set of charset ! values includes those registered by RFC 1521 [5] -- the ! US-ASCII [17] and ISO-8859 [18] coded character sets -- and other ! names specifically recommended for use within MIME charset ! parameters. ! charset = "US-ASCII" ! | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" ! | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" ! | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" ! | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" ! | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" ! | token ! ! Although HTTP allows an arbitrary token to be used as a charset ! value, any token that has a predefined value within the IANA ! Character Set registry [15] must represent the coded character set ! defined by that registry. Applications are encouraged, but not ! required, to limit their use of coded character sets to those ! defined by the IANA registry. ! ! 3.5 Encoding Mechanisms ! ! Encoding mechanism values are used to indicate an encoding ! transformation that has been or can be applied to a resource. ! Encoding mechanisms are primarily used to allow a document to be ! compressed or encrypted without losing the identity of its ! underlying media type. Typically, the resource is stored in this ! encoding and only decoded before rendering or analogous usage. ! ! encoding-mechanism = "x-gzip" | "x-compress" | token ! ! Note: For future compatibility, HTTP/1.0 applications should ! consider "gzip" and "compress" to be equivalent to "x-gzip" ! and "x-compress", respectively. ! ! All encoding-mechanism values are case-insensitive. HTTP/1.0 uses ! encoding-mechanism values in the Content-Encoding (Section 8.3) ! header field. Although the value describes the encoding-mechanism, ! what is more important is that it indicates what decoding mechanism ! will be required to remove the encoding. Note that a single program ! may be capable of decoding multiple encoding-mechanism formats. Two ! values are defined by this specification: ! ! x-gzip ! An encoding format produced by the file compression program ! "gzip" (GNU zip) developed by Jean-loup Gailly. This format is ! typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. Gzip is ! available from the GNU project at ! . ! ! x-compress ! The encoding format produced by the file compression program ! "compress". This format is an adaptive Lempel-Ziv-Welch coding ! (LZW). ! ! Note: Use of program names for the identification of ! encoding formats is not desirable and should be discouraged ! for future encodings. Their use here is representative of ! historical practice, not good design. ! ! 3.6 Media Types ! ! HTTP uses Internet Media Types [13] (formerly referred to as MIME ! Content-Types [5]) in order to provide open and extensible data typing and type negotiation. For mail applications, where there is *************** *** 768,774 **** to put strict limits on the set of allowed media types. With HTTP, ! however, user agents can identify acceptable media types as part of ! the connection, and thus are allowed more freedom in the use of non- ! registered types. The following grammar for media types is a ! superset of that for MIME because it does not restrict itself to ! the official IANA and x-token types. --- 769,775 ---- to put strict limits on the set of allowed media types. With HTTP, ! where the sender and recipient can communicate directly, ! applications are allowed more freedom in the use of non-registered ! types. The following grammar for media types is a superset of that ! for MIME because it does not restrict itself to the official IANA ! and x-token types. *************** *** 785,789 **** ! The type, subtype, and parameter attribute names are not case- ! sensitive. Parameter values may or may not be case-sensitive, ! depending on the semantics of the parameter name. LWS should not be generated between the type and subtype, nor between an attribute --- 786,790 ---- ! The type, subtype, and parameter attribute names are case- ! insensitive. Parameter values may or may not be case-sensitive, ! depending on the semantics of the parameter name. LWS must not be generated between the type and subtype, nor between an attribute *************** *** 791,792 **** --- 792,799 ---- + Many current applications do not recognize media type parameters. + Since parameters are a fundamental aspect of media types, this must + be considered an error in those applications. Nevertheless, + HTTP/1.0 applications should only use media type parameters when + they are necessary to define the content of a message. + If a given media-type value has been registered by the IANA, any *************** *** 796,798 **** strongly encouraged to register their media types with IANA via the ! procedures outlined in RFC 1590 [15]. --- 803,805 ---- strongly encouraged to register their media types with IANA via the ! procedures outlined in RFC 1590 [13]. *************** *** 805,807 **** ! 3.4.1 Canonicalization and Text Defaults --- 812,814 ---- ! 3.6.1 Canonicalization and Text Defaults *************** *** 810,815 **** canonical form prior to transmission. If the body has been encoded ! via a Content-Encoding and/or Content-Transfer-Encoding, the data ! must be in canonical form prior to that encoding. However, HTTP ! modifies the canonical form requirements for media of primary type ! "text" and for "application" types consisting of text-like records. --- 817,822 ---- canonical form prior to transmission. If the body has been encoded ! via a Content-Encoding, the data must be in canonical form prior to ! that encoding. However, HTTP modifies the canonical form ! requirements for media of primary type "text" and for "application" ! types consisting of text-like records. *************** *** 819,829 **** LF alone as representing a single line break in text media. ! Furthermore, if the text media is represented in a character set ! encoding which does not use octets 13 and 10 for CR and LF ! respectively, as is the case for some multi-byte character set ! encodings, HTTP allows the use of whatever octet sequence(s) is ! defined by that character set encoding to represent the equivalent ! of CRLF, bare CR, and bare LF. It is assumed that any recipient ! capable of using such a character set encoding will know the ! appropriate octet sequence for representing line breaks within that ! character set encoding. --- 826,835 ---- LF alone as representing a single line break in text media. ! Furthermore, if the text media is represented in a coded character ! set which does not use octets 13 and 10 for CR and LF respectively, ! as is the case for some multi-byte coded character sets, HTTP ! allows the use of whatever octet sequence(s) is defined by that ! coded character set to represent the equivalent of CRLF, bare CR, ! and bare LF. It is assumed that any recipient capable of using such ! a coded character set will know the appropriate octet sequence for ! representing line breaks within that coded character set. *************** *** 831,836 **** contents of an Entity-Body and only after any Content- ! Transfer-Encoding and/or Content-Encoding has been removed. ! All other HTTP constructs use CRLF exclusively to indicate a ! line break. Encoding mechanisms define their own line break ! requirements. --- 837,841 ---- contents of an Entity-Body and only after any Content- ! Encoding has been removed. All other HTTP constructs use ! CRLF exclusively to indicate a line break. Encoding ! mechanisms define their own line break requirements. *************** *** 843,849 **** ! HTTP also redefines the default character set encoding for text ! media in an entity body. If a textual media type defines a charset parameter with a registered default value of "US-ASCII", HTTP ! changes the default to be "ISO-8859-1". Since the ISO-8859-1 [20] ! character set encoding is a superset of US-ASCII [19], this has no effect upon the interpretation of entity bodies which only contain --- 848,854 ---- ! HTTP also redefines the default coded character set for text media ! in an entity body. If a textual media type defines a charset parameter with a registered default value of "US-ASCII", HTTP ! changes the default to be "ISO-8859-1". Since the ISO-8859-1 [18] ! coded character set is a superset of US-ASCII [17], this has no effect upon the interpretation of entity bodies which only contain *************** *** 853,860 **** ! It is recommended but not required that the character set encoding ! of an entity body be labelled as the lowest common denominator of ! the character codes used within a document, with the exception that ! no label is preferred over the labels US-ASCII or ISO-8859-1. ! 3.4.2 Multipart Types --- 858,865 ---- ! It is recommended that the coded character set of an entity body be ! labelled as the lowest common denominator of the character codes ! used within a document, with the exception that no label is ! preferred over the labels US-ASCII or ISO-8859-1. ! 3.6.2 Multipart Types *************** *** 862,864 **** several entities within a single message's Entity-Body. The ! multipart types registered by IANA [17] do not have any special meaning for HTTP/1.0, though user agents may need to understand --- 867,869 ---- several entities within a single message's Entity-Body. The ! multipart types registered by IANA [15] do not have any special meaning for HTTP/1.0, though user agents may need to understand *************** *** 868,870 **** ! As in MIME [6], all multipart types share a common syntax and must include a boundary parameter as part of the media type value. The --- 873,875 ---- ! As in MIME [5], all multipart types share a common syntax and must include a boundary parameter as part of the media type value. The *************** *** 875,1079 **** ! A URI-header field (Section 8.28) should be included in the body- ! part for each enclosed entity that can be identified by a URI. - 3.5 Character Set Encodings - - HTTP uses the same definition of the term "character set" as that - described for MIME: - - The term "character set" is used in this document to - refer to a method used with one or more tables to convert - a sequence of octets into a sequence of characters. Note - that unconditional conversion in the other direction is - not required, in that not all characters may be available - in a given character set and a character set may provide - more than one sequence of octets to represent a - particular character. This definition is intended to - allow various kinds of character encodings, from simple - single-table mappings such as US-ASCII to complex table - switching methods such as those that use ISO 2022's - techniques. However, the definition associated with a - MIME character set name must fully specify the mapping to - be performed from octets to characters. In particular, - use of external profiling information to determine the - exact mapping is not permitted. - - However, since this is more commonly referred to as a character - encoding, this document will refer to them as character set - encodings. Character set encodings are identified by case- - insensitive tokens. The complete set of tokens are defined by the - IANA Character Set registry [17]. However, because that registry - does not define a single, consistent token for each character set - encoding, we define here the preferred names for those character - set encodings most likely to be used with HTTP entities. This set - of charset values includes those registered by RFC 1521 [6] -- the - US-ASCII [19] and ISO-8859 [20] character set encodings -- and other - names specifically recommended for use within MIME charset - parameters. - - charset = "US-ASCII" - | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" - | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" - | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" - | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" - | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" - | token - - Although HTTP allows an arbitrary token to be used as a charset - value, any token that has a predefined value within the IANA - Character Set registry [17] must represent the character set - encoding defined by that registry. Applications are encouraged, but - not required, to limit their use of character set encodings to - those defined by the IANA registry. - - 3.6 Encoding Mechanisms - - Encoding mechanism values are used to indicate an encoding - transformation that has been or can be applied to a resource. - Encoding mechanisms are primarily used to allow a document to be - compressed or encrypted without losing the identity of its - underlying media type. Typically, the resource is stored in this - encoding and only decoded before rendering or analogous usage. - - encoding-mechanism = "gzip" | "compress" | token - - Note: For historical reasons, HTTP/1.0 applications should - consider "x-gzip" and "x-compress" to be equivalent to - "gzip" and "compress", respectively. - - All encoding-mechanism values are case-insensitive. HTTP/1.0 uses - encoding-mechanism values in the Accept-Encoding (Section 8.3) and - Content-Encoding (Section 8.7) header fields. Although the value - describes the encoding-mechanism, what is more important is that it - indicates what decoding mechanism will be required to remove the - encoding. Note that a single program may be capable of decoding - multiple encoding-mechanism formats. Two values are defined by this - specification: - - gzip An encoding format produced by the file compression - program "gzip" (GNU zip) developed by Jean-loup Gailly. - This format is typically a Lempel-Ziv coding (LZ77) with - a 32 bit CRC. Gzip is available from the GNU project at - . - - compress The encoding format produced by the file compression - program "compress". This format is an adaptive - Lempel-Ziv-Welch coding (LZW). - - Note: Use of program names for the identification of - encoding formats is not desirable and should be discouraged - for future encodings. Their use here is representative of - historical practice, not good design. - - 3.7 Transfer Encodings - - Transfer encoding values are used to indicate an encoding - transformation that has been, can be, or may need to be applied to - an Entity-Body in order to ensure safe transport through the - network. Current transfer encodings are only used with entities - destined for or retrieved from MIME-conformant systems, and thus - will rarely occur in an HTTP/1.0 message. This differs from an - encoding-mechanism in that the transfer encoding is a property of - the message, not of the original resource. - - transfer-encoding = "binary" | "8bit" | "7bit" - | "quoted-printable" | "base64" - | token - - All transfer-encoding values are case-insensitive. HTTP/1.0 may use - transfer-encoding values in the Content-Transfer-Encoding - (Section 8.10) header field. - - Note: Transfer encodings were designed for MIME with the - assumption of their being used only within the context of - Internet mail and SMTP. "Safe transport" has a different - focus for an 8bit-clean transfer protocol. In HTTP, the only - unsafe characteristic of message bodies is the difficulty in - determining the exact body length (Section 7.2.2). - - The values "7bit", "8bit", and "binary" are used to indicate that - no transfer encoding has been performed. Instead, they describe the - sort of encoding that might be needed for transmission through an - unsafe transport system. Binary indicates that the body may contain - any set of octets. 8bit adds the restrictions that CR and LF - characters only occur as part of CRLF line separators, all lines - are short (less than 1000 octets), and no NULs (octet 0) are - present. 7bit adds a further restriction that all octets are 7-bit - US-ASCII characters. - - The "quoted-printable" and "base64" values indicate that the - associated encoding (as defined in MIME [6]) has been applied to - the body. These encodings consist entirely of 7-bit US-ASCII - characters. - - 3.8 Language Tags - - A language tag identifies a natural language spoken, written, or - otherwise conveyed by human beings for communication of information - to other human beings. Computer languages are explicitly excluded. - The HTTP/1.0 protocol uses language tags within the - Accept-Language, Content-Language, and URI-header fields. - - The syntax and registry of HTTP language tags is the same as that - defined by RFC 1766 [1]. In summary, a language tag is composed of - 1 or more parts: A primary language tag and a possibly empty series - of subtags: - - language-tag = primary-tag *( "-" subtag ) - - primary-tag = 1*8ALPHA - subtag = 1*8ALPHA - - Whitespace is not allowed within the tag and all tags are not case- - sensitive. The namespace of language tags is administered by the - IANA. Example tags include: - - en, en-US, en-cockney, i-cherokee, x-pig-latin - - where any two-letter primary-tag is an ISO 639 language - abbreviation and any two-letter initial subtag is an ISO 3166 - country code. - - In the context of the Accept-Language header (Section 8.4), a - language tag is not to be interpreted as a single token, as per - RFC 1766, but as a hierarchy. A server should consider that it has a - match when a language tag received in an Accept-Language header - matches the initial portion of the language tag of a document. An - exact match should be preferred. This interpretation allows a - browser to send, for example: - - Accept-Language: en-US, en; ql=0.95 - - when the intent is to access, in order of preference, documents in - US-English ("en-US"), 'plain' or 'international' English ("en"), - and any other variant of English (initial "en-"). - - Note: Using the language tag as a hierarchy does not imply - that all languages with a common prefix will be understood - by those fluent in one or more of those languages; it simply - allows the user to request this commonality when it is true - for that user. - - 3.9 Quality Values - - HTTP content negotiation (Section 9) uses short "floating point" - numbers to indicate the relative importance ("weight") of various - negotiable parameters. The calculated weights are normalized to a - real number in the range 0 through 1, where 0 is the minimum and 1 - the maximum value. In order to discourage misuse of this feature, - HTTP/1.0 applications must not generate more than three digits - after the decimal point. User configuration of these values should - also be limited in this fashion. - - qvalue = ( "0" [ "." 0*3DIGIT ] ) - | ( "." 0*3DIGIT ) - | ( "1" [ "." 0*3("0") ] ) - - "Quality values" is a slight misnomer, since these values actually - measure relative degradation in perceived quality. Thus, a value of - "0.8" represents a 20% degradation from the optimum rather than a - statement of 80% quality. - - 3.10 Product Tokens - Product tokens are used to allow communicating applications to --- 880,883 ---- ! 3.7 Product Tokens Product tokens are used to allow communicating applications to *************** *** 1097,1102 **** advertizing or other non-essential information is explicitly ! forbidden. Although any token character may appear in a product- ! version, this token should only be used for a version identifier ! (i.e., successive versions of the same product should only differ ! in the product-version portion of the product value). --- 901,906 ---- advertizing or other non-essential information is explicitly ! forbidden. Although any token character may appear in a ! product-version, this token should only be used for a version ! identifier (i.e., successive versions of the same product should ! only differ in the product-version portion of the product value). *************** *** 1115,1120 **** Full-Request and Full-Response use the generic message format of ! RFC 822 [8] for transferring entities. Both messages may include optional header fields (a.k.a. "headers") and an entity body. The ! entity body is separated from the headers by a null line (i.e., a ! line with nothing preceding the CRLF). --- 919,924 ---- Full-Request and Full-Response use the generic message format of ! RFC 822 [7] for transferring entities. Both messages may include optional header fields (a.k.a. "headers") and an entity body. The ! entity body is separated from the headers by a null line ! (i.e., a line with nothing preceding the CRLF). *************** *** 1142,1145 **** Use of the Simple-Request format is discouraged because it prevents ! the client from using content negotiation and the server from ! identifying the media type of the returned entity. --- 946,948 ---- Use of the Simple-Request format is discouraged because it prevents ! the server from identifying the media type of the returned entity. *************** *** 1150,1157 **** Entity-Header (Section 7.1) fields, follow the same generic format ! as that given in Section 3.1 of RFC 822 [8]. Each header field ! consists of a name followed by a colon (":") and the field value. ! Field names are never case-sensitive. The field value may be ! preceded by any amount of LWS, though a single SP is preferred. ! Header fields can be extended over multiple lines by preceding each ! extra line with at least one LWS. --- 953,960 ---- Entity-Header (Section 7.1) fields, follow the same generic format ! as that given in Section 3.1 of RFC 822 [7]. Each header field ! consists of a name followed immediately by a colon (":"), a single ! space (SP) character, and the field value. Field names are case- ! insensitive. Header fields can be extended over multiple lines by ! preceding each extra line with at least one LWS, though this is not ! recommended. *************** *** 1160,1162 **** field-name = 1* ! field-value = *( field-content | comment | LWS ) --- 963,965 ---- field-name = 1* ! field-value = *( field-content | LWS ) *************** *** 1183,1188 **** both request and response messages, but which do not apply to the ! communicating parties or the content being transferred. Although ! none of the General-Header fields are required, they are all ! strongly recommended where their use is appropriate, and should be ! understood by all future HTTP/1.0 clients and servers. These headers apply only to the message being transmitted. --- 986,988 ---- both request and response messages, but which do not apply to the ! communicating parties or the content being transferred. These headers apply only to the message being transmitted. *************** *** 1189,1194 **** ! General-Header = Date ; Section 8.12 ! | Forwarded ; Section 8.14 ! | MIME-Version ; Section 8.20 ! | Pragma ; Section 8.22 --- 989,993 ---- ! General-Header = Date ; Section 8.6 ! | MIME-Version ; Section 8.12 ! | Pragma ; Section 8.13 *************** *** 1233,1235 **** Request-Line of a Full-Request is the presence of the HTTP-Version ! field and the availability of methods other than "GET". --- 1032,1034 ---- Request-Line of a Full-Request is the presence of the HTTP-Version ! field and the availability of methods other than GET. *************** *** 1238,1244 **** The Method token indicates the method to be performed on the ! resource identified by the Request-URI. The method is case- ! sensitive. ! Method = "GET" | "HEAD" | "PUT" | "POST" ! | "DELETE" | "LINK" | "UNLINK" | extension-method --- 1037,1042 ---- The Method token indicates the method to be performed on the ! resource identified by the Request-URI. The method is ! case-sensitive. ! Method = "GET" | "HEAD" | "POST" | extension-method *************** *** 1245,1261 **** ! extension-method = token ! The list of methods acceptable by a specific resource can be ! specified in an "Allow" Entity-Header (Section 8.5). However, the ! client is always notified through the return code of the response ! whether a method is currently allowed on a specific resource, as ! this can change dynamically. Servers should return the status code ! "405 Method Not Allowed" if the method is known by the server but ! not allowed for the requested resource, and "501 Not Implemented" ! if the method is unknown or not implemented by the server. - The methods GET and HEAD must be supported by all general-purpose - servers. Servers which provide Last-Modified dates for resources - must also support the conditional GET method. - The set of common methods for HTTP/1.0 is described below. Although --- 1043,1052 ---- ! extension-method=token ! The list of methods acceptable by a specific resource can change ! dynamically; the client is notified through the return code of the ! response if a method is not allowed on a resource. Servers should ! return the status code 501 (not implemented) if the method is ! unknown or not implemented. The set of common methods for HTTP/1.0 is described below. Although *************** *** 1263,1267 **** assumed to share the same semantics for separately extended clients ! and servers. In order to maintain compatibility, the semantic ! definition for extension methods should be registered with the ! IANA [17]. --- 1054,1056 ---- assumed to share the same semantics for separately extended clients ! and servers. *************** *** 1280,1282 **** transferred only if it has been modified since the date given by ! the If-Modified-Since header, as described in Section 8.16. The conditional GET method is intended to reduce network usage by --- 1069,1071 ---- transferred only if it has been modified since the date given by ! the If-Modified-Since header, as described in Section 8.9. The conditional GET method is intended to reduce network usage by *************** *** 1314,1316 **** o Providing a block of data, such as the result of submitting a ! form [4], to a data-handling process; --- 1103,1105 ---- o Providing a block of data, such as the result of submitting a ! form [3], to a data-handling process; *************** *** 1325,1340 **** - The client can suggest a URI for identifying the new resource by - including a URI-header field in the request. However, the server - should treat that URI as advisory and may store the entity under a - different URI or without any URI. - - The client may apply relationships between the new resource and - other existing resources by including Link header fields, as - described in Section 8.18. The server may use the Link information - to perform other operations as a result of the new resource being - added. For example, lists and indexes might be updated. However, no - mandatory operation is imposed on the origin server. The origin - server may also generate its own or additional links to other - resources. - A successful POST does not require that the entity be created as a --- 1114,1115 ---- *************** *** 1348,1351 **** If a resource has been created on the origin server, the response ! should be 201 (created) and contain the allocated URI, all ! applicable Link header fields, and an entity (preferably of type "text/html") which describes the status of the request and refers --- 1123,1125 ---- If a resource has been created on the origin server, the response ! should be 201 (created) and contain an entity (preferably of type "text/html") which describes the status of the request and refers *************** *** 1357,1465 **** - 5.2.4 PUT - - The PUT method requests that the enclosed entity be stored under - the supplied Request-URI. If the Request-URI refers to an already - existing resource, the enclosed entity should be considered as a - modified version of the one residing on the origin server. If the - Request-URI does not point to an existing resource, and that URI is - capable of being defined as a new resource by the requesting user - agent, the origin server can create the resource with that URI. If - a new resource is created, the origin server must inform the user - agent via the 201 (created) response. If an existing resource is - modified, either the 200 (ok) or 204 (no content) response codes - should be sent to indicate successful completion of the request. If - the resource could not be created or modified with the Request-URI, - an appropriate error response should be given that reflects the - nature of the problem. - - The fundamental difference between the POST and PUT requests is - reflected in the different meaning of the Request-URI. The URI in a - POST request identifies the resource that will handle the enclosed - entity as an appendage. That resource may be a data-accepting - process, a gateway to some other protocol, or a separate entity - that accepts annotations. In contrast, the URI in a PUT request - identifies the entity enclosed with the request -- the user agent - knows what URI is intended and the server must not attempt to apply - the request to some other resource. If the server desires that the - request be applied to a different URI, it must send a 301 (moved - permanently) response; the user agent may then make its own - decision regarding whether or not to redirect the request. - - A single resource may be identified by many different URIs. For - example, an article may have a URI for identifying "the current - version" which is separate from the URI identifying each particular - version. In this case, a PUT request on a general URI may result in - several other URIs being defined by the origin server. The user - agent should be informed of these URIs via one or more URI header - fields in the response. The Location header field should be used to - identify the exact location URI if it is different than the - Request-URI. - - A valid Content-Length is required on all HTTP/1.0 PUT requests. An - HTTP/1.0 server should respond with a 400 (bad request) message if - it cannot determine the length of the request message's content. - - The client can create or modify relationships between the enclosed - entity and other existing resources by including Link header - fields, as described in Section 8.18. As with POST, the server may - use the Link information to perform other operations as a result of - the request. However, no mandatory operation is imposed on the - origin server. The origin server may generate its own or additional - links to other resources. - - The actual method for determining how the resource is placed, and - what happens to its predecessor, is defined entirely by the origin - server. If version control is implemented by the origin server, - then Link relationships should be defined by the server to help - identify and control revisions to a resource; suggested - relationship names include "Derived-From", "Obsoletes", and - "Updates". - - Note: The model of sending an entire PUT request within a - single message, without first checking if the server is - willing to accept that data, will break if the server is - unwilling to accept the request or desires some form of - authentication beforehand. Worse, the client won't be - notified of the reason for error if a TCP reset is received - prior to reading the response buffer (see note in - Section 6.2.4). It should therefore be recognized that - HTTP/1.0 PUT and large POST requests will only work reliably - if the client's intentions and server's desires are - negotiated prior to the request. - - 5.2.5 DELETE - - The DELETE method requests that the origin server delete the - resource identified by the Request-URI. This method may be - overridden by human intervention (or other means) on the origin - server. The client cannot be guaranteed that the operation has been - carried out, even if the status code returned from the origin - server indicates that the action has been completed successfully. - However, the server should not indicate success unless, at the time - the response is given, it intends to delete the resource or move it - to an inaccessible location. - - A successful response should be 200 (ok) if the response includes - an entity describing the status, 202 (accepted) if the action has - not yet been enacted, or 204 (no content) if the response is OK but - does not include an entity. - - 5.2.6 LINK - - The LINK method establishes one or more Link relationships between - the existing resource identified by the Request-URI and other - existing resources. The difference between LINK and other methods - allowing links to be established between resources is that the LINK - method does not allow any Entity-Body to be sent in the request and - does not result in the creation of new resources. - - 5.2.7 UNLINK - - The UNLINK method removes one or more Link relationships from the - existing resource identified by the Request-URI. These - relationships may have been established using the LINK method or by - any other method supporting the Link header. The removal of a link - to a resource does not imply that the resource ceases to exist or - becomes inaccessible for future references. - 5.3 Request-URI --- 1131,1132 ---- *************** *** 1469,1482 **** ! Request-URI = "*" | absoluteURI | abs_path ! The three options for Request-URI are dependent on the nature of ! the request. The asterisk "*" means that the request does not apply ! to a particular resource, but to the server itself, and is only ! allowed when the Method used does not necessarily apply to a ! resource. Note that this is not the case for any of the methods ! defined by this document; however, it may be true of extension ! methods. One example would be - OPTIONS * HTTP/1.0 - The absoluteURI form is only allowed when the request is being made --- 1136,1142 ---- ! Request-URI = absoluteURI | abs_path ! The two options for Request-URI are dependent on the nature of the ! request. The absoluteURI form is only allowed when the request is being made *************** *** 1485,1492 **** response is cached, the proxy may return the cached message if it ! passes any restrictions in the Pragma and Expires header fields. ! Note that the proxy may forward the request on to another proxy or ! directly to the origin server specified by the absoluteURI. In ! order to avoid request loops, a proxy must be able to recognize all ! of its server names, including any aliases, local variations, and ! the numeric IP address. An example Request-Line would be: --- 1145,1152 ---- response is cached, the proxy may return the cached message if it ! passes any restrictions in the Expires header field. Note that the ! proxy may forward the request on to another proxy or directly to ! the origin server specified by the absoluteURI. In order to avoid ! request loops, a proxy must be able to recognize all of its server ! names, including any aliases, local variations, and the numeric IP ! address. An example Request-Line would be: *************** *** 1496,1501 **** resource on an origin server. In this case, only the absolute path ! of the URI (abs_path) is transmitted. For example, a client wishing ! to retrieve the resource above directly from the origin server ! would create a TCP connection to port 80 of the host "www.w3.org" ! and send the line: --- 1156,1161 ---- resource on an origin server. In this case, only the absolute path ! of the URI is transmitted (see Section 3.2.1, abs_path). For ! example, a client wishing to retrieve the resource above directly ! from the origin server would create a TCP connection to port 80 of ! the host "www.w3.org" and send the line: *************** *** 1514,1525 **** ! Request-Header = Accept ; Section 8.1 ! | Accept-Charset ; Section 8.2 ! | Accept-Encoding ; Section 8.3 ! | Accept-Language ; Section 8.4 ! | Authorization ; Section 8.6 ! | From ; Section 8.15 ! | If-Modified-Since ; Section 8.16 ! | Orig-URI ; Section 8.21 ! | Referer ; Section 8.24 ! | User-Agent ; Section 8.29 --- 1174,1180 ---- ! Request-Header = Authorization ; Section 8.2 ! | From ; Section 8.8 ! | If-Modified-Since ; Section 8.9 ! | Referer ; Section 8.14 ! | User-Agent ; Section 8.16 *************** *** 1536,1538 **** ! Simple-Response = [ Entity-Body ] --- 1191,1193 ---- ! Simple-Response= [ Entity-Body ] *************** *** 1574,1576 **** Full-Request, most HTTP/0.9 servers are limited to responses of ! type "text/html" and therefore never generate such a response. --- 1229,1231 ---- Full-Request, most HTTP/0.9 servers are limited to responses of ! type "text/html" and therefore would never generate such a response. *************** *** 1612,1616 **** | "202" ; Accepted - | "203" ; Non-Authoritative Information | "204" ; No Content - | "300" ; Multiple Choices | "301" ; Moved Permanently --- 1267,1269 ---- *************** *** 1617,1619 **** | "302" ; Moved Temporarily - | "303" ; See Other | "304" ; Not Modified --- 1270,1271 ---- *************** *** 1621,1623 **** | "401" ; Unauthorized - | "402" ; Payment Required | "403" ; Forbidden --- 1273,1274 ---- *************** *** 1624,1632 **** | "404" ; Not Found - | "405" ; Method Not Allowed - | "406" ; None Acceptable - | "407" ; Proxy Authentication Required - | "408" ; Request Timeout - | "409" ; Conflict - | "410" ; Gone - | "411" ; Authorization Refused | "500" ; Internal Server Error --- 1275,1276 ---- *************** *** 1635,1637 **** | "503" ; Service Unavailable - | "504" ; Gateway Timeout | extension-code --- 1279,1280 ---- *************** *** 1642,1656 **** ! HTTP status codes are extensible and should be registered with the ! IANA. HTTP applications are not required to understand the meaning ! of all registered status codes, though such understanding is ! obviously desirable. However, applications must understand the ! class of any status code, as indicated by the first digit, and ! treat any unknown response as being equivalent to the x00 status ! code of that class. For example, if an unknown status code of 421 ! is received by the client, it can safely assume that there was ! something wrong with its request and treat the response as if it ! had received a 400 status code. In such cases, user agents are ! encouraged to present the entity returned with the response to the ! user, since that entity is likely to include human-readable ! information which will explain the unusual status. --- 1285,1300 ---- ! HTTP status codes are extensible, but the above codes are the only ! ones generally recognized in current practice. HTTP applications ! are not required to understand the meaning of all registered status ! codes, though such understanding is obviously desirable. However, ! applications must understand the class of any status code, as ! indicated by the first digit, and treat any unknown response as ! being equivalent to the x00 status code of that class. For example, ! if an unknown status code of 421 is received by the client, it can ! safely assume that there was something wrong with its request and ! treat the response as if it had received a 400 status code. In such ! cases, user agents are encouraged to present the entity returned ! with the response to the user, since that entity is likely to ! include human-readable information which will explain the unusual ! status. *************** *** 1662,1664 **** ! This class of status codes indicates a provisional response, consisting only of the Status-Line and optional headers, and is --- 1306,1308 ---- ! This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is *************** *** 1665,1669 **** terminated by an empty line. HTTP/1.0 does not define any 1xx ! status codes and they are not a valid response to a standard ! HTTP/1.0 request. However, they may be useful for experimental ! applications which are outside the scope of this specification. --- 1309,1313 ---- terminated by an empty line. HTTP/1.0 does not define any 1xx ! status codes and they are not a valid response to a HTTP/1.0 ! request. However, they may be useful for experimental applications ! which are outside the scope of this specification. *************** *** 1671,1673 **** ! This class of status codes indicates that the client's request was successfully received, understood, and accepted. --- 1315,1317 ---- ! This class of status code indicates that the client's request was successfully received, understood, and accepted. *************** *** 1685,1695 **** ! POST an entity describing or containing the result of the action; - PUT, DELETE, LINK, UNLINK - an entity describing the result of the action; - - If the entity corresponds to a resource, the response may include a - Location header field giving the actual location of that specific - resource for later reference. - 201 Created --- 1329,1332 ---- ! POST an entity describing or containing the result of the action. 201 Created *************** *** 1698,1708 **** created. The newly created resource can be referenced by the URI(s) ! returned in the URI-header field of the response, with the most ! specific URL for the resource given by a Location header field. The ! origin server is encouraged, but not obliged, to actually create ! the resource before using this Status-Code. If the action cannot be ! carried out immediately, or within a clearly defined timeframe, the ! server should respond with 202 (accepted) instead. ! Of the methods defined by this specification, only PUT and POST can ! create a resource. --- 1335,1344 ---- created. The newly created resource can be referenced by the URI(s) ! returned in the entity of the response. The origin server is ! encouraged, but not obliged, to actually create the resource before ! using this Status-Code. If the action cannot be carried out ! immediately, or within a clearly defined timeframe, the server ! should respond with 202 (accepted) instead. ! Of the methods defined by this specification, only POST can create ! a resource. *************** *** 1725,1737 **** - 203 Non-Authoritative Information - - The returned metainformation in the Entity-Header is not the - definitive set as available from the origin server, but is gathered - from a local or a third-party copy. The set presented may be a - subset or superset of the original version. For example, including - local annotation information about the resource may result in a - superset of the metainformation known by the origin server. Use of - this response code is not required and is only appropriate when the - response would otherwise be 200 (ok). - 204 No Content --- 1361,1362 ---- *************** *** 1760,1763 **** ! The requested resource is available at one or more locations and a ! preferred location could not be determined via content negotiation. Unless it was a HEAD request, the response should include an entity --- 1385,1391 ---- ! This response code is not directly used by HTTP/1.0 applications, ! but serves as the default for interpreting the 3xx class of ! responses. ! ! The requested resource is available at one or more locations. Unless it was a HEAD request, the response should include an entity *************** *** 1765,1773 **** which the user or user agent can choose the one most appropriate. ! The entity format is specified by the media type given in the ! Content-Type header field. Depending upon the format and the ! capabilities of the user agent, selection of the most appropriate ! choice may be performed automatically. If the server has a ! preferred choice, it should include its URL in a Location field; ! user agents not capable of complex selection may use the Location ! value for automatic redirection. --- 1393,1397 ---- which the user or user agent can choose the one most appropriate. ! If the server has a preferred choice, it should include the URL in ! a Location field; user agents may use the Location value for ! automatic redirection. *************** *** 1775,1789 **** ! The requested resource has been assigned a new permanent URI and ! any future references to this resource should be done using one of ! the returned URIs. Clients with link editing capabilities are ! encouraged to automatically relink references to the Request-URI to ! one or more of the new references returned by the server, where ! possible. ! If the new URI is a single location, its URL must be given by the ! Location field in the response. If more than one URI exists for the ! resource, the primary URL should be given in the Location field and ! the other URIs given in one or more URI-header fields. The Entity- ! Body of the response should contain a short hypertext note with a ! hyperlink to the new URI(s). --- 1399,1409 ---- ! The requested resource has been assigned a new permanent URL and ! any future references to this resource should be done using that ! URL. Clients with link editing capabilities are encouraged to ! automatically relink references to the Request-URI to the new ! reference returned by the server, where possible. ! The new URL must be given by the Location field in the response. ! The Entity-Body of the response should contain a short hypertext ! note with a hyperlink to the new URL. *************** *** 1790,1795 **** If the 301 status code is received in response to a request using ! the PUT, POST, or DELETE methods, the user agent must not ! automatically redirect the request unless it can be confirmed by ! the user, since this might change the conditions under which the ! request was issued. --- 1410,1414 ---- If the 301 status code is received in response to a request using ! the POST method, the user agent must not automatically redirect the ! request unless it can be confirmed by the user, since this might ! change the conditions under which the request was issued. *************** *** 1797,1799 **** ! The requested resource resides temporarily under a different URI. Since the redirection may be altered on occasion, the client should --- 1416,1418 ---- ! The requested resource resides temporarily under a different URL. Since the redirection may be altered on occasion, the client should *************** *** 1801,1808 **** ! If the new URI is a single location, its URL must be given by the ! Location field in the response. If more than one URI exists for the ! resource, the primary URL should be given in the Location field and ! the other URIs given in one or more URI-header fields. The Entity- ! Body of the response should contain a short hypertext note with a ! hyperlink to the new URI(s). --- 1420,1424 ---- ! The URL must be given by the Location field in the response. The ! Entity-Body of the response should contain a short hypertext note ! with a hyperlink to the new URI(s). *************** *** 1809,1830 **** If the 302 status code is received in response to a request using ! the PUT, POST, or DELETE methods, the user agent must not ! automatically redirect the request unless it can be confirmed by ! the user, since this might change the conditions under which the ! request was issued. - 303 See Other - - The requested resource resides under a different URI and should be - accessed using a GET method on that resource. This method exists - primarily to allow the output of a POST-activated script to - redirect the user agent to a selected resource. The new resource is - not a replacement reference for the original Request-URI. - - If the new URI is a single location, its URL must be given by the - Location field in the response. If more than one URI exists for the - resource, the primary URL should be given in the Location field and - the other URIs given in one or more URI-header fields. The Entity- - Body of the response should contain a short hypertext note with a - hyperlink to the new URI(s). - 304 Not Modified --- 1425,1430 ---- If the 302 status code is received in response to a request using ! the POST method, the user agent must not automatically redirect the ! request unless it can be confirmed by the user, since this might ! change the conditions under which the request was issued. 304 Not Modified *************** *** 1842,1844 **** ! The 4xx class of status codes is intended for cases in which the client seems to have erred. If the client has not completed the --- 1442,1444 ---- ! The 4xx class of status code is intended for cases in which the client seems to have erred. If the client has not completed the *************** *** 1863,1867 **** ! The request could not be understood by the server due to it having ! a malformed syntax. The client is discouraged from repeating the ! request without modifications. --- 1463,1467 ---- ! The request could not be understood by the server due to malformed ! syntax. The client is discouraged from repeating the request ! without modifications. *************** *** 1870,1872 **** The request requires user authentication. The response must include ! a WWW-Authenticate header field (Section 8.30) containing a challenge applicable to the requested resource. The client may --- 1470,1472 ---- The request requires user authentication. The response must include ! a WWW-Authenticate header field (Section 8.17) containing a challenge applicable to the requested resource. The client may *************** *** 1873,1881 **** repeat the request with a suitable Authorization header field. HTTP ! access authentication is explained in Section 10. - 402 Payment Required - - This code is not currently supported, but is reserved for future - use. - 403 Forbidden --- 1473,1476 ---- repeat the request with a suitable Authorization header field. HTTP ! access authentication is explained in Section 9. 403 Forbidden *************** *** 1883,1888 **** The server understood the request, but is refusing to perform the ! request because of an unspecified reason. Authorization will not ! help and the request should not be repeated. This status code can ! be used if the server does not want to make public why the request ! has not been fulfilled. --- 1478,1483 ---- The server understood the request, but is refusing to perform the ! request for an unspecified reason. Authorization will not help and ! the request should not be repeated. This status code can be used if ! the server does not want to make public why the request has not ! been fulfilled. *************** *** 1894,1986 **** available to the client, the status code 403 (forbidden) can be ! used instead. The 410 (gone) status code should be used if the ! server knows, through some internally configurable mechanism, that ! an old resource is permanently unavailable and has no forwarding ! address. - 405 Method Not Allowed - - The method specified in the Request-Line is not allowed for the - resource identified by the Request-URI. The response must include - an Allow header containing a list of valid method's for the - requested resource. - - 406 None Acceptable - - The server has found a resource matching the Request-URI, but not - one that satisfies the conditions identified by the Accept and - Accept-Encoding request headers. Unless it was a HEAD request, the - response should include an entity containing a list of resource - characteristics and locations from which the user or user agent can - choose the one most appropriate. The entity format is specified by - the media type given in the Content-Type header field. Depending - upon the format and the capabilities of the user agent, selection - of the most appropriate choice may be performed automatically. - - 407 Proxy Authentication Required - - This code is reserved for future use. It is similar to 401 - (unauthorized), but indicates that the client must first - authenticate itself with the proxy. HTTP/1.0 does not provide a - means for proxy authentication. - - 408 Request Timeout - - The client did not produce a request within the time that the - server was prepared to wait. The client may repeat the request - without modifications at any later time. - - 409 Conflict - - The request could not be completed due to a conflict with the - current state of the resource. This code is only allowed in - situations where it is expected that the user may be able to - resolve the conflict and resubmit the request. The response body - should include enough information for the user to recognize the - source of the conflict. Ideally, the response entity would include - enough information for the user or user-agent to fix the problem; - however, that may not be possible and is not required. - - Conflicts are most likely to occur in response to a PUT request. If - versioning is being used and the entity being PUT includes changes - to a resource which conflict with those made by an earlier (third- - party) request, the server may use the 409 response to indicate - that it can't complete the PUT. In this case, the response entity - may contain a list of the differences between the two versions. - - 410 Gone - - The requested resource is no longer available at the server and no - forwarding address is known. This condition should be considered - permanent. Clients with link editing capabilities are encouraged to - delete references to the Request-URI after user approval. If the - server does not know, or has no facility to determine, whether or - not the condition is permanent, the status code 404 (not found) - should be used instead. - - The 410 response is primarily intended to assist the task of web - maintenance by notifying the recipient that the resource is - intentionally unavailable and that the server owners desire that - remote links to that resource be removed. Such an event is common - for limited-time, promotional services and for resources belonging - to individuals no longer working at the server's site. It is not - necessary to mark all permanently unavailable resources as "gone" - or to keep the mark for any length of time -- that is left to the - discretion of the server owner. - - 411 Authorization Refused - - The request credentials provided by the client were rejected by the - server or insufficient to grant authorization to access the - resource. This is similar to the 403 (forbidden) response, but - allows more information to be provided to the user. The content of - the response should contain a description of the problem and may - suggest corrective action. HTTP access authentication is explained - in Section 10. - - The response must include a WWW-Authenticate header field - (Section 8.30) containing a challenge applicable to the requested - resource. If the challenge is different from that assumed by the - last request, the client may repeat the request with a suitable - Authorization header field after obtaining the user's approval. - 6.2.5 Server Errors 5xx --- 1489,1492 ---- available to the client, the status code 403 (forbidden) can be ! used instead. 6.2.5 Server Errors 5xx *************** *** 2019,2023 **** is that this is a temporary condition which will be alleviated ! after some delay. If known, the length of the delay may be ! indicated in a Retry-After header. If no Retry-After is given, the ! client should handle the response as it would for a 500 response. --- 1525,1527 ---- is that this is a temporary condition which will be alleviated ! after some delay. *************** *** 2027,2033 **** - 504 Gateway Timeout - - The server did not receive a timely response from the gateway or - upstream server it accessed in attempting to complete the request. - 6.3 Response Header Fields --- 1531,1532 ---- *************** *** 2040,2046 **** ! Response-Header= Location ; Section 8.19 ! | Public ; Section 8.23 ! | Retry-After ; Section 8.25 ! | Server ; Section 8.26 ! | WWW-Authenticate ; Section 8.30 --- 1539,1543 ---- ! Response-Header= Location ; Section 8.11 ! | Server ; Section 8.15 ! | WWW-Authenticate ; Section 8.17 *************** *** 2053,2057 **** Full-Request and Full-Response messages may transfer an entity ! within some requests and responses. An entity consists of Entity- ! Header fields and (usually) an Entity-Body. In this section, both ! sender and recipient refer to either the client or the server, depending on who sends and who receives the entity. --- 1550,1554 ---- Full-Request and Full-Response messages may transfer an entity ! within some requests and responses. An entity consists of ! Entity-Header fields and (usually) an Entity-Body. In this section, ! both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity. *************** *** 2064,2076 **** ! Entity-Header = Allow ; Section 8.5 ! | Content-Encoding ; Section 8.7 ! | Content-Language ; Section 8.8 ! | Content-Length ; Section 8.9 ! | Content-Transfer-Encoding ; Section 8.10 ! | Content-Type ; Section 8.11 ! | Expires ; Section 8.13 ! | Last-Modified ; Section 8.17 ! | Link ; Section 8.18 ! | Title ; Section 8.27 ! | URI-header ; Section 8.28 | extension-header --- 1561,1568 ---- ! Entity-Header = Allow ; Section 8.1 ! | Content-Encoding ; Section 8.3 ! | Content-Length ; Section 8.4 ! | Content-Type ; Section 8.5 ! | Expires ; Section 8.7 ! | Last-Modified ; Section 8.10 | extension-header *************** *** 2077,2079 **** ! extension-header=HTTP-header --- 1569,1571 ---- ! extension-header = HTTP-header *************** *** 2092,2099 **** An entity-body is included with a request message only when the ! request method calls for one. This specification defines two ! request methods, "POST" and "PUT", that allow an entity-body. In ! general, the presence of an entity-body in a request is signaled by ! the inclusion of a Content-Length and/or Content-Transfer-Encoding ! header field in the request message headers. HTTP/1.0 requests ! containing content must include a valid Content-Length header field. --- 1584,1591 ---- An entity-body is included with a request message only when the ! request method calls for one. This specification defines one ! request method, POST, that allows an entity-body. In general, the ! presence of an entity-body in a request is signaled by the ! inclusion of a Content-Length header field in the request message ! headers. HTTP/1.0 requests containing content must include a valid ! Content-Length header field. *************** *** 2109,2126 **** When an Entity-Body is included with a message, the data type of ! that body is determined via the header fields Content-Type, ! Content-Encoding, and Content-Transfer-Encoding. These define a ! three-layer, ordered encoding model: ! entity-body <- ! Content-Transfer-Encoding( Content-Encoding( Content-Type ) ) ! The default for both encodings is none (i.e., the identity ! function). A Content-Type specifies the media type of the ! underlying data. A Content-Encoding may be used to indicate any ! additional encoding mechanisms applied to the type, usually for the ! purpose of data compression, that is a property of the resource ! requested. A Content-Transfer-Encoding may be applied by a ! transport agent to ensure safe and proper transfer of the message. ! Note that the Content-Transfer-Encoding is a property of the ! message, not of the resource. --- 1601,1613 ---- When an Entity-Body is included with a message, the data type of ! that body is determined via the header fields Content-Type and ! Content-Encoding. These define a two-layer, ordered encoding model: ! entity-body := Content-Encoding( Content-Type( data ) ) ! A Content-Type specifies the media type of the underlying data. A ! Content-Encoding may be used to indicate any additional encoding ! mechanism applied to the type, usually for the purpose of data ! compression, that is a property of the resource requested. The ! default for the content encoding is none (i.e., the identity ! function). *************** *** 2140,2143 **** of the Entity-Body. Otherwise, the body length is determined by the - Content-Type (for types with an explicit end-of-body delimiter), - the Content-Transfer-Encoding (for packetized encodings), or the closing of the connection by the server. --- 1627,1628 ---- *************** *** 2146,2156 **** request body, since it leaves no possibility for the server to send ! back a response. Furthermore, there is no guarantee that an ! HTTP/1.0 server will recognize types with an explicit end-of-body ! delimiter, and there is no packetized Content-Transfer-Encoding ! defined for HTTP/1.0. Therefore, HTTP/1.0 requests containing ! content must include a valid Content-Length header field. If a ! request contains an entity body and Content-Length is not ! specified, and the server does not recognize or cannot calculate ! the length from other fields, then the server should send a 400 ! (bad request) response. --- 1631,1638 ---- request body, since it leaves no possibility for the server to send ! back a response. Therefore, HTTP/1.0 requests containing content ! must include a valid Content-Length header field. If a request ! contains an entity body and Content-Length is not specified, and ! the server does not recognize or cannot calculate the length from ! other fields, then the server should send a 400 (bad request) ! response. *************** *** 2171,2371 **** ! 8.1 Accept - The Accept header field can be used to indicate a list of media - ranges which are acceptable as a response to the request. The - asterisk "*" character is used to group media types into ranges, - with "*/*" indicating all media types and "type/*" indicating all - subtypes of that type. The set of ranges given by the client should - represent what types are acceptable given the context of the - request. The Accept field should only be used when the request is - specifically limited to a set of desired types, as in the case of a - request for an in-line image, or to indicate qualitative - preferences for specific media types. - - The field may be folded onto several lines and more than one - occurrence of the field is allowed, with the semantics being the - same as if all the entries had been in one field value. - - Accept = "Accept" ":" #( - media-range - [ ";" "q" "=" qvalue ] - [ ";" "mxb" "=" 1*DIGIT ] ) - - media-range = ( "*/*" - | ( type "/" "*" ) - | ( type "/" subtype ) - ) *( ";" parameter ) - - The parameter q is used to indicate the quality factor, which - represents the user's preference for that range of media types. The - parameter mxb gives the maximum acceptable size of the Entity-Body, - in decimal number of octets, for that range of media types. - Section 9 describes the content negotiation algorithm which makes - use of these values. The default values are: q=1 and mxb=undefined - (i.e., infinity). - - The example - - Accept: audio/*; q=0.2, audio/basic - - should be interpreted as "I prefer audio/basic, but send me any - audio type if it is the best available after an 80% mark-down in - quality." - - If no Accept header is present, then it is assumed that the client - accepts all media types with quality factor 1. This is equivalent - to the client sending the following accept header field: - - Accept: */*; q=1 - - or - - Accept: */* - - A more elaborate example is - - Accept: text/plain; q=0.5, text/html, - text/x-dvi; q=0.8; mxb=100000, text/x-c - - Verbally, this would be interpreted as "text/html and text/x-c are - the preferred media types, but if they do not exist then send the - Entity-Body in text/x-dvi if the entity is less than 100000 bytes, - otherwise send text/plain." - - Note: In earlier versions of this document, the mxs - parameter defined the maximum acceptable delay in seconds - before the response would arrive. This has been removed as - the server has no means of obtaining a useful reference - value. However, this does not prevent the client from - internally measuring the response time and optimizing the - Accept header field accordingly. - - Media ranges can be overridden by more specific media ranges or - specific media types. If more than one media range applies to a - given type, the most specific reference has precedence. For example, - - Accept: text/*, text/html, text/html;version=2.0, */* - - have the following precedence: - - 1) text/html;version=2.0 - 2) text/html - 3) text/* - 4) */* - - The quality value associated with a given type is determined by - finding the media range with the highest precedence which matches - that type. For example, - - Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, - */*;q=0.5 - - would cause the following values to be associated: - - text/html;version=2.0 = 1 - text/html = 0.7 - text/plain = 0.3 - image/jpeg = 0.5 - text/html;level=3 = 0.7 - - It must be emphasized that the Accept field should only be used - when it is necessary to restrict the response media types to a - subset of those possible or when the user has been permitted to - specify qualitative values for ranges of media types. If no quality - factors have been set by the user, and the context of the request - is such that the user agent is capable of saving the entity to a - file if the received media type is unknown, then the only - appropriate value for Accept is "*/*". - - Note: A user agent may be provided with a default set of - quality values for certain media ranges. However, unless the - user agent is a completely closed system which cannot - interact with other rendering agents, this default set - should be configurable by the user. - - 8.2 Accept-Charset - - The Accept-Charset request header field can be used to indicate a - list of preferred character set encodings other than the default - US-ASCII and ISO-8859-1. This field allows clients capable of - understanding more comprehensive or special-purpose character set - encodings to signal that capability to a server which is capable of - representing documents in those character set encodings. - - Accept-Charset = "Accept-Charset" ":" #charset - - Character set encoding values are described in Section 3.5. An - example is - - Accept-Charset: iso-8859-5, unicode-1-1 - - The value of this field should not include "US-ASCII" or - "ISO-8859-1", since those values are always assumed by default. If - a resource is only available in a character set encoding other than - the defaults, and that character set encoding is not listed in the - Accept-Charset field, it is only acceptable for the server to send - the entity if the character set encoding can be identified by an - appropriate charset parameter on the media type or within the - format of the media type itself. - - Note: User agents are not required to be able to render the - characters associated with the ISO-8859-1 character set - encoding. However, they must be able to interpret their - meaning to whatever extent is required to properly handle - messages in that character set encoding. - - 8.3 Accept-Encoding - - The Accept-Encoding request header field is similar to Accept, but - restricts the encoding-mechanism values which are acceptable in the - response. - - Accept-Encoding = "Accept-Encoding" ":" - #( encoding-mechanism ) - - An example of its use is - - Accept-Encoding: compress, gzip - - If no Accept-Encoding field is present in a request, the server - should assume that the client will accept any encoding-mechanism. - - 8.4 Accept-Language - - The Accept-Language request header field is similar to Accept, but - restricts the set of natural languages that are preferred as a - response to the request. - - Accept-Language = "Accept-Language" ":" - #( language-tag [ ";" "ql" "=" qvalue ] ) - - The language-tag is described in Section 3.8. Each language may be - given an associated quality value which represents an estimate of - the user's comprehension of that language. The quality value - defaults to "ql=1" (100% comprehension) for listed languages. This - value may be used in the server's content negotiation algorithm - (Section 9). For example, - - Accept-Language: da, en-gb;ql=0.8, de;ql=0.55 - - would mean: "I prefer Danish, but will accept British English (with - 80% comprehension) or German (with a 55% comprehension)." - - If the server cannot fulfill the request with one or more of the - languages given, or if the languages only represent a subset of a - multi-linguistic Entity-Body, it is acceptable to serve the request - in an unspecified language. This is equivalent to asssigning a - quality value of "ql=0.001" to any unlisted language. - - If no Accept-Language header is present in the request, the server - should assume that all languages are equally acceptable. - - Note: As intelligibility is highly dependent on the - individual user, it is recommended that client applications - make the choice of linguistic preference available to the - user. If the choice is not made available, then the Accept- - Language header field must not be given in the request. - - 8.5 Allow - The Allow header field lists the set of methods supported by the --- 1653,1656 ---- ! 8.1 Allow The Allow header field lists the set of methods supported by the *************** *** 2373,2380 **** is strictly to inform the recipient of valid methods associated ! with the resource. An Allow header field must be present in a 405 ! (method not allowed) response. The Allow header field is not ! permitted in a request using the POST method, and thus should be ! ignored if it is received as part of a POST entity. ! Allow = "Allow" ":" #method --- 1658,1664 ---- is strictly to inform the recipient of valid methods associated ! with the resource. The Allow header field is not permitted in a ! request using the POST method, and thus should be ignored if it is ! received as part of a POST entity. ! Allow = "Allow" ":" 1#method *************** *** 2382,2384 **** ! Allow: GET, HEAD, PUT --- 1666,1668 ---- ! Allow: GET, HEAD *************** *** 2390,2397 **** - The Allow header field may be provided with a PUT request to - recommend the methods to be supported by the new or modified - resource. The server is not required to support these methods and - should include an Allow header in the response giving the actual - supported methods. - A proxy must not modify the allow header even if it does not --- 1674,1675 ---- *************** *** 2401,2407 **** The Allow header field does not indicate what methods are ! implemented at the server level. Servers must use the Public ! response header field (Section 8.23) if they wish to describe what ! methods are implemented on the server as a whole. ! 8.6 Authorization --- 1679,1683 ---- The Allow header field does not indicate what methods are ! implemented by the server. ! 8.2 Authorization *************** *** 2408,2424 **** A user agent that wishes to authenticate itself with a server-- ! usually, but not necessarily, after receiving a 401 or 411 response-- ! may do so by including an Authorization header field with the ! request. The Authorization field value consists of credentials ! containing the authentication information of the user agent for the ! realm of the resource being requested. ! Authorization = "Authorization" ":" 1#credentials ! HTTP access authentication is described in Section 10. If a request is authenticated and a realm specified, the same credentials should ! be valid for all other requests within this realm, until the server ! indicates otherwise with a 411 (authorization refused) response. ! 8.7 Content-Encoding The Content-Encoding header field is used as a modifier to the --- 1684,1702 ---- A user agent that wishes to authenticate itself with a server-- ! usually, but not necessarily, after receiving a 401 response--may do ! so by including an Authorization header field with the request. The ! Authorization field value consists of credentials containing the ! authentication information of the user agent for the realm of the ! resource being requested. ! Authorization = "Authorization" ":" credentials ! HTTP access authentication is described in Section 9. If a request is authenticated and a realm specified, the same credentials should ! be valid for all other requests within this realm. ! Proxies must not cache the response to a request containing an ! Authorization field. + 8.3 Content-Encoding + The Content-Encoding header field is used as a modifier to the *************** *** 2425,2428 **** media-type. When present, its value indicates what additional ! encoding mechanisms have been applied to the resource, and thus ! what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. The --- 1703,1706 ---- media-type. When present, its value indicates what additional ! encoding mechanism has been applied to the resource, and thus what ! decoding mechanism must be applied in order to obtain the media-type referenced by the Content-Type header field. The *************** *** 2431,2435 **** ! Content-Encoding = "Content-Encoding" ":" 1#encoding-mechanism ! Encoding mechanisms are defined in Section 3.6. An example of its use is --- 1709,1713 ---- ! Content-Encoding = "Content-Encoding" ":" encoding-mechanism ! Encoding mechanisms are defined in Section 3.5. An example of its use is *************** *** 2436,2438 **** ! Content-Encoding: gzip --- 1714,1716 ---- ! Content-Encoding: x-gzip *************** *** 2442,2490 **** ! If multiple encodings have been applied to a resource, the ! encoding-mechanisms must be listed in the order in which they were ! applied. Additional information about the encoding parameters may ! be provided by other Entity-Header fields not defined by this ! specification. - 8.8 Content-Language - - The Content-Language field describes the natural language(s) of the - intended audience for the enclosed entity. Note that this may not - be equivalent to all the languages used within the entity. - - Content-Language = "Content-Language" ":" #language-tag - - Language tags are defined in Section 3.8. The primary purpose of - Content-Language is to allow a selective consumer to identify and - differentiate resources according to the consumer's own preferred - language. Thus, if the body content is intended only for a Danish- - literate audience, the appropriate field is - - Content-Language: dk - - If no Content-Language is specified, the default is that the - content is intended for all language audiences. This may mean that - the sender does not consider it to be specific to any natural - language, or that the sender does not know for which language it is - intended. - - Multiple languages may be listed for content that is intended for - multiple audiences. For example, a rendition of the "Treaty of - Waitangi," presented simultaneously in the original Maori and - English versions, would call for - - Content-Language: mi, en - - However, just because multiple languages are present within an - entity does not mean that it is intended for multiple linguistic - audiences. An example would be a beginner's language primer, such - as "A First Lesson in Latin," which is clearly intended to be used - by an English-literate audience. In this case, the Content-Language - should only include "en". - - Content-Language may be applied to any media type -- it should not - be limited to textual documents. - - 8.9 Content-Length - The Content-Length header field indicates the size of the --- 1720,1723 ---- ! 8.4 Content-Length The Content-Length header field indicates the size of the *************** *** 2514,2543 **** ! 8.10 Content-Transfer-Encoding - The Content-Transfer-Encoding (CTE) header indicates what (if any) - type of transformation has been applied to the entity in order to - safely transfer it between the sender and the recipient. This - differs from the Content-Encoding in that the CTE is a property of - the message, not of the original resource. - - Content-Transfer-Encoding = "Content-Transfer-Encoding" ":" - transfer-encoding - - Transfer encodings are defined in Section 3.7. Because all HTTP - transactions take place on an 8-bit clean connection, the default - Content-Transfer-Encoding for all messages is binary. However, HTTP - may be used to transfer MIME messages which already have a defined - CTE. An example is: - - Content-Transfer-Encoding: quoted-printable - - Many older HTTP/1.0 applications do not understand the - Content-Transfer-Encoding header. However, since it may appear in - any MIME message (i.e., entities retrieved via a gateway to a MIME- - conformant protocol), future HTTP/1.0 applications must understand - it upon receipt. Gateways are the only HTTP applications that would - generate a CTE. - - 8.11 Content-Type - The Content-Type header field indicates the media type of the --- 1747,1750 ---- ! 8.5 Content-Type The Content-Type header field indicates the media type of the *************** *** 2549,2553 **** ! Media types are defined in Section 3.4. An example of the field is ! Content-Type: text/html; charset=ISO-8859-4 --- 1756,1760 ---- ! Media types are defined in Section 3.6. An example of the field is ! Content-Type: text/html *************** *** 2557,2559 **** ! 8.12 Date --- 1764,1766 ---- ! 8.6 Date *************** *** 2560,2563 **** The Date header represents the date and time at which the message ! was originated, having the same semantics as orig-date in RFC ! 822.The field value is an HTTP-date, as described in Section 3.3. --- 1767,1770 ---- The Date header represents the date and time at which the message ! was originated, having the same semantics as orig-date in RFC 822. ! The field value is an HTTP-date, as described in Section 3.3. *************** *** 2576,2582 **** Clients should only send a Date header field in messages that ! include an entity body, as in the case of the PUT and POST ! requests, and even then it is optional. A received message which ! does not have a Date header field should be assigned one by the ! receiver if and only if the message will be cached by that receiver ! or gatewayed via a protocol which requires a Date. --- 1783,1789 ---- Clients should only send a Date header field in messages that ! include an entity body, as in the case of the POST request, and ! even then it is optional. A received message which does not have a ! Date header field should be assigned one by the receiver if and ! only if the message will be cached by that receiver or gatewayed ! via a protocol which requires a Date. *************** *** 2592,2594 **** ! 8.13 Expires --- 1799,1801 ---- ! 8.7 Expires *************** *** 2632,2677 **** Note: Applications are encouraged to be tolerant of bad or ! misinformed implementations of the Expires header. In ! particular, recipients may wish to recognize a delta-seconds ! value (any decimal integer) as representing the number of ! seconds after receipt of the message that its contents ! should be considered expired. Likewise, a value of zero (0) ! or an invalid date format should be considered equivalent to ! an "expires immediately." Although these values are not ! legitimate for HTTP/1.0, a robust implementation is always ! desirable. ! 8.14 Forwarded - The Forwarded header is to be used by proxies to indicate the - intermediate steps between the user agent and the server on - requests, and between the origin server and the client on - responses. It is analogous to the "Received" field of RFC 822 [8] - and is intended to be used for tracing transport problems and - avoiding request loops. - - Forwarded = "Forwarded" ":" #( "by" URI [ "(" product ")" ] - [ "for" FQDN ] ) - - FQDN = - - For example, a message could be sent from a client on - ptsun00.cern.ch to a server at www.ics.uci.edu port 80, via an - intermediate HTTP proxy at info.cern.ch port 8000. The request - received by the server at www.ics.uci.edu would then have the - following Forwarded header field: - - Forwarded: by http://info.cern.ch:8000/ for ptsun00.cern.ch - - Multiple Forwarded header fields are allowed and should represent - each proxy that has forwarded the message. It is strongly - recommended that proxies used as a portal through a network - firewall do not, by default, send out information about the - internal hosts within the firewall region. This information should - only be propagated if explicitly enabled. If not enabled, the for - token and FQDN should not be included in the field value, and any - Forwarded headers already present in the message (those added - behind the firewall) should be removed. - - 8.15 From - The From header field, if given, should contain an Internet e-mail --- 1839,1848 ---- Note: Applications are encouraged to be tolerant of bad or ! misinformed implementations of the Expires header. A value ! of zero (0) or an invalid date format should be considered ! equivalent to an "expires immediately." Although these ! values are not legitimate for HTTP/1.0, a robust ! implementation is always desirable. ! 8.8 From The From header field, if given, should contain an Internet e-mail *************** *** 2678,2681 **** address for the human user who controls the requesting user agent. ! The address should be machine-usable, as defined by mailbox in RFC ! 822 [8] (as updated by RFC 1123 [7]): --- 1849,1852 ---- address for the human user who controls the requesting user agent. ! The address should be machine-usable, as defined by mailbox in ! RFC 822 [7] (as updated by RFC 1123 [6]): *************** *** 2696,2701 **** ! The Internet e-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 proxy the original ! issuer's address should be used. --- 1867,1872 ---- ! The Internet e-mail address in this field may be separate from the ! Internet host which issued the request. For example, when a request ! is passed through a proxy, the original issuer's address should be ! used. *************** *** 2708,2710 **** ! 8.16 If-Modified-Since --- 1879,1881 ---- ! 8.9 If-Modified-Since *************** *** 2713,2717 **** modified since the time specified in this field, a copy of the ! resource will not be returned from the server; instead, a ! "304 Not Modified" response will be returned without any ! Entity-Body. --- 1884,1887 ---- modified since the time specified in this field, a copy of the ! resource will not be returned from the server; instead, a 304 ! (not modified) response will be returned without any Entity-Body. *************** *** 2729,2731 **** a) If the request would normally result in anything other than ! a "200 OK" status, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a --- 1899,1901 ---- a) If the request would normally result in anything other than ! a 200 (ok) status, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a *************** *** 2737,2741 **** ! c) If the resource has not been modified since the If-Modified- ! Since date, the server shall return a "304 Not Modified" ! response. --- 1907,1911 ---- ! c) If the resource has not been modified since the ! If-Modified-Since date, the server shall return a 304 ! (not modified) response. *************** *** 2744,2752 **** ! Note: The same functionality can be obtained, though with ! much greater overhead, by issuing a HEAD request and ! following it with a GET request if the server indicates that ! the entity has been modified. - 8.17 Last-Modified - The Last-Modified header field indicates the date and time at which --- 1914,1917 ---- ! 8.10 Last-Modified The Last-Modified header field indicates the date and time at which *************** *** 2766,2820 **** implementation of the sender and the nature of the original ! resource. For files, it may be just the file system last-mod date. ! For entities with dynamically included parts, it may be the most ! recent of the set of last-modify times for its component parts. For ! database gateways, it may be the last-update timestamp of the ! record. For virtual objects, it may be the last time the internal ! state changed. ! 8.18 Link - The Link header provides a means for describing a relationship - between the entity and some other resource. An entity may include - multiple Link values. Links at the metainformation level typically - indicate relationships like hierarchical structure and navigation - paths. The Link field is semantically equivalent to the - element in HTML [4]. - - Link = "Link" ":" #("<" URI ">" - [ ";" "rel" "=" relationship ] - [ ";" "rev" "=" relationship ] - [ ";" "title" "=" quoted-string ] ) - - relationship = sgml-name - | ( <"> sgml-name *( SP sgml-name) <"> ) - - sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) - - Relation values are not case-sensitive and may be extended within - the constraints of the sgml-name syntax. There are no predefined - link relationship values for HTTP/1.0. The title parameter may be - used to label the destination of a link such that it can be used as - identification within a human-readable menu. Examples of usage - include: - - Link: ; rel="Previous" - - Link: ; rev="Made"; title="Tim Berners-Lee" - - The first example indicates that the entity is previous to chapter2 - in a logical navigation path. The second indicates that the person - responsible for making the resource available is identified by the - given e-mail address. - - 8.19 Location - The Location response header field defines the exact location of ! the resource that was identified by the Request-URI. For 2xx ! responses, the location should be the URL needed to retrieve that ! same resource again (i.e., if variants of that resource are ! available, the value of the Location field should locate the ! variant chosen by the server if it has its own specific URL). For ! 3xx responses, the location should indicate the server's preferred ! URL for automatic redirection to the resource. Only one absolute ! URL is allowed. --- 1931,1946 ---- implementation of the sender and the nature of the original ! resource. For files, it may be just the file system last-modified ! time. For entities with dynamically included parts, it may be the ! most recent of the set of last-modify times for its component ! parts. For database gateways, it may be the last-update timestamp ! of the record. For virtual objects, it may be the last time the ! internal state changed. ! 8.11 Location The Location response header field defines the exact location of ! the resource that was identified by the Request-URI. For 3xx ! responses, the location must indicate the server's preferred URL ! for automatic redirection to the resource. Only one absolute URL is ! allowed. *************** *** 2826,2833 **** ! If no base URL is provided by or within the entity, the value of ! the Location field should be used as the base for resolving ! relative URLs [10]. - 8.20 MIME-Version - HTTP is not a MIME-conformant protocol (see Appendix C). However, --- 1952,1955 ---- ! 8.12 MIME-Version HTTP is not a MIME-conformant protocol (see Appendix C). However, *************** *** 2837,2839 **** that the message is in full compliance with the MIME protocol (as ! defined in [6]). Unfortunately, current versions of HTTP/1.0 clients and servers use this field indiscriminately, and thus --- 1959,1961 ---- that the message is in full compliance with the MIME protocol (as ! defined in [5]). Unfortunately, current versions of HTTP/1.0 clients and servers use this field indiscriminately, and thus *************** *** 2851,2877 **** ! 8.21 Orig-URI - The Orig-URI request header field allows the client to specify, for - the server's benefit, the original Uniform Resource Identifier - (Section 3.2) of the resource being requested, as it was obtained - from the user or the referring resource. This allows a server to - differentiate between internally-ambiguous URLs (such as the root - "/" URL of a server harboring multiple virtual hostnames), to learn - about new URNs used to reference resources on the server, and to - provide some additional assistance in identifying and redirecting - moved resources and resource fragments. - - Orig-URI = "Orig-URI" ":" absoluteURI [ "#" fragment ] - - Example: - - Orig-URI: http://www.w3.org/ - - The URI must be in absolute form and should include the fragment if - one is given to the client. It should include exactly what was - referenced by the Referer resource, with the exception that a - relative reference must first be resolved to its absolute form. - - 8.22 Pragma - The Pragma message header field is used to specify directives that --- 1973,1976 ---- ! 8.13 Pragma The Pragma message header field is used to specify directives that *************** *** 2883,2886 **** systems may require that behavior be consistent with the ! directives. HTTP/1.0 defines semantics for the "no-cache" and ! "max-age" directives. --- 1982,1984 ---- systems may require that behavior be consistent with the ! directives. HTTP/1.0 defines semantics for the "no-cache" directive. *************** *** 2889,2891 **** pragma-directive = "no-cache" - | "max-age" "=" delta-seconds | extension-pragma --- 1987,1988 ---- *************** *** 2894,2896 **** When the "no-cache" directive is present in a request message, a ! caching intermediary should forward the request toward the origin server even if it has a cached copy of what is being requested. --- 1991,1993 ---- When the "no-cache" directive is present in a request message, a ! caching intermediary must forward the request toward the origin server even if it has a cached copy of what is being requested. *************** *** 2900,2931 **** - When the "no-cache" directive is present in a response message, - caching intermediaries are requested to not cache this response. - This allows an origin server to state that the message is intended - for only one recipient and may not be a valid response for other - requests. - - When the "max-age" directive is present in a request message, a - caching intermediary should forward the request toward the origin - server if it has no cached copy, or refresh its cached copy if it - is older than the age value given (in seconds) prior to returning a - response. A cached copy's "age" is determined by the cached - message's Date header field, or the equivalent as stored by the - cache manager. In most cases, a cached copy can be refreshed by - forwarding a conditional GET request toward the origin server with - the stored message's Date value in the If-Modified-Since field. If - a 304 (not modified) response is received, the cache should replace - the cached message's Date with that of the 304 response and send - this refreshed message as the response. Any other response should - be forwarded directly to the requestor and, depending on the - response code and the discretion of the cache manager, may replace - the message in the cache. - - When the "max-age" directive is present in a cached response - message, a caching intermediary should refresh the message if it is - older than the age value given (in seconds) at the time of a new - request for that resource. The behavior should be equivalent to - what would occur if the request had included that pragma directive. - If both the new request and the cached message have max-age - specified, then the lesser of the two values should be used. - Pragma directives must be passed through by a proxy, regardless of --- 1997,1998 ---- *************** *** 2938,2971 **** Pragma directives do not apply to the end-points of a ! request/response chain. For example, a user agent's internal (non- ! shared) cache and/or history mechanism should ignore all pragma ! directives in received messages. Similarly, pragma directives are ! not applicable to the origin of a resource, though they may be ! applicable to a server's internal response cache. ! 8.23 Public - The Public response header field lists the set of non-standard - methods supported by the server. The purpose of this field is - strictly to inform the recipient of the capabilities of the server - regarding unusual methods. The methods listed may or may not be - applicable to the Request-URI; the Allow header field (Section 8.5) - should be used to indicate methods allowed for a particular URI. - This does not prevent a client from trying other methods. The field - value should not include the methods predefined for HTTP/1.0 in - Section 5.2. - - Public = "Public" ":" #method - - Example of use: - - Public: OPTIONS, MGET, MHEAD - - This header field applies only to the server directly connected to - the client (i.e., the nearest neighbor in a chain of connections). - If the response passes through a proxy, the proxy must either - remove the Public header field or replace it with one applicable to - its own capabilities. - - 8.24 Referer - The Referer request header field allows the client to specify, for --- 2005,2014 ---- Pragma directives do not apply to the end-points of a ! request/response chain. For example, a user agent's internal ! (non-shared) cache and/or history mechanism should ignore all ! pragma directives in received messages. Similarly, pragma ! directives are not applicable to the origin of a resource, though ! they may be applicable to a server's internal response cache. ! 8.14 Referer The Referer request header field allows the client to specify, for *************** *** 2983,2985 **** ! Referer: http://info.cern.ch/hypertext/DataSources/Overview.html --- 2026,2028 ---- ! Referer: http://www.w3.org/hypertext/DataSources/Overview.html *************** *** 2996,3017 **** ! 8.25 Retry-After - The Retry-After response header field can be used with a 503 - (service unavailable) response to indicate how long the service is - expected to be unavailable to the requesting client. The value of - this field can be either an HTTP-date or an integer number of - seconds (in decimal) after the time of the response. - - Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) - - Two examples of its use are - - Retry-After: Wed, 14 Dec 1994 18:22:54 GMT - - Retry-After: 120 - - In the latter example, the delay is 2 minutes. - - 8.26 Server - The Server response header field contains information about the --- 2039,2042 ---- ! 8.15 Server The Server response header field contains information about the *************** *** 3018,3025 **** software used by the origin server to handle the request. The field ! can contain multiple product tokens (Section 3.10) identifying the ! server and any significant subproducts. By convention, the product ! tokens are listed in order of their significance for identifying ! the application. ! Server = "Server" ":" 1*( product ) --- 2043,2050 ---- software used by the origin server to handle the request. The field ! can contain multiple product tokens (Section 3.7) and comments ! identifying the server and any significant subproducts. By ! convention, the product tokens are listed in order of their ! significance for identifying the application. ! Server = "Server" ":" 1*( product | comment ) *************** *** 3030,3033 **** If the response is being forwarded through a proxy, the proxy ! application must not add its data to the product list. Instead, it ! should include a Forwarded field (as described in Section 8.14). --- 2055,2057 ---- If the response is being forwarded through a proxy, the proxy ! application should not add its data to the product list. *************** *** 3039,3130 **** ! 8.27 Title - The Title header field indicates the title of the entity - - Title = "Title" ":" *text - - An example of the field is - - Title: Hypertext Transfer Protocol -- HTTP/1.0 - - This field is isomorphic with the element in HTML [4]. - - 8.28 URI - - The URI-header field may contain some or all of the Uniform - Resource Identifiers (Section 3.2) by which the Request-URI - resource can be identified. There is no guarantee that the resource - can be accessed using the URI(s) specified. - - URI-header = "URI" ":" #( "<" ( absoluteURI | relativeURI ) ">" - [ ";" vary ] *( ";" characteristic) ) - - vary = "vary" "=" - ( vary-dimension | ( <"> 1#vary-dimension <"> ) ) - - vary-dimension = "type" | "charset" | "language" | "encoding" - | "user-agent" | "version" | token - - characteristic = ( "type={" media-type "}" ) - | ( "language={" 1#language-tag "}" ) - | ( "encoding={" 1#encoding-mechanism "}" ) - | ( "length=" 1*DIGIT ) - | ( "qs=" qvalue ) - - Any URI specified in this field can be either absolute or relative - to the Request-URI. - - If the Location header field is present in a 2xx response, its - value defines an implicit URI header with the characteristic - parameters defined by the associated Content-* header fields. - - The URI-header may be used by a client performing a POST request to - suggest a URI for the new entity. Whether or not the suggested URI - is used is entirely up to the server to decide. In any case, the - server's response must include the actual URI(s) of the new - resource if one is successfully created (status 201). - - If a URI refers to a set of variants, then the dimensions of that - variance must be given with a vary parameter. One example is: - - URI: <http://info.cern.ch/hypertext/WWW/TheProject.multi>; - vary="type,language" - - which indicates that the URI covers a group of entities that vary - in media type and natural language. A request for that URI will - result in a response that depends upon the client's request headers - for Accept and Accept-Language. Similar dimensions exist for the - Accept-Encoding, Accept-Charset, and User-Agent header fields, as - demonstrated in the following example. - - URI: <TheProject.ps>; vary="encoding,version"; - type={application/postscript}, - <TheProject.html>; vary="user-agent,charset,version"; - type={text/html}, - <TheProject.html3;v=25>; type={text/html; level=3}; qs=0.9 - - User agents may use this information to notify the user of - additional formats. - - The vary parameter has an important effect on cache management, - particularly for caching intermediaries which service a diverse set - of user agents. Since the response to one user agent may differ - from the response to a second user agent if the two agents have - differing request profiles, a caching intermediary must keep track - of the content metainformation for resources with varying - dimensions. Thus, the vary parameter tells the intermediary what - entity headers must be part of the key for caching that URI. When - the caching proxy gets a request for that URI, it must forward the - request toward the origin server if the request profile includes a - variant dimension that has not already been cached. - - If the origin server provides the characteristics of each - identified resource as part of the URI header, then the recipient - may improve its cached response behavior by attempting to duplicate - the content negotiation that would be provided by the server. This - is not required by the protocol, but may improve the accuracy or - timeliness of responses to the end-user. - - 8.29 User-Agent - The User-Agent field contains information about the user agent --- 2063,2066 ---- ! 8.16 User-Agent The User-Agent field contains information about the user agent *************** *** 3135,3139 **** always include this field with requests. The field can contain ! multiple product tokens (Section 3.10) identifying the agent and ! any subproducts which form a significant part of the user agent. ! By convention, the product tokens are listed in order of their significance for identifying the application. --- 2071,2075 ---- always include this field with requests. The field can contain ! multiple product tokens (Section 3.7) identifying the agent and any ! subproducts which form a significant part of the user agent. By ! convention, the product tokens are listed in order of their significance for identifying the application. *************** *** 3140,3142 **** ! User-Agent = "User-Agent" ":" 1*( product ) --- 2076,2078 ---- ! User-Agent = "User-Agent" ":" 1*( product | comment ) *************** *** 3150,3157 **** Note: Some current proxy applications append their product ! information to the list in the User-Agent field. This is no ! longer recommended, since it makes machine interpretation of ! these fields ambiguous. Instead, proxies should use the ! Forwarded header described in Section 8.14. ! 8.30 WWW-Authenticate --- 2086,2092 ---- Note: Some current proxy applications append their product ! information to the list in the User-Agent field. This is not ! recommended, since it makes machine interpretation of these ! fields ambiguous. ! 8.17 WWW-Authenticate *************** *** 3158,3336 **** The WWW-Authenticate header field must be included in 401 ! (unauthorized) and 411 (authorization refused) response messages. ! The field value consists of a challenge that indicates the ! authentication scheme and parameters applicable to the Request-URI. ! WWW-Authenticate = "WWW-Authenticate" ":" challenge ! The HTTP access authentication process is described in Section 10. ! 9. Content Negotiation ! Content negotiation is an optional feature of the HTTP protocol. It ! is designed to allow for selection of a preferred content ! representation, within a single request-response round-trip, and ! without intervention from the user. However, this may not always be ! desirable for the user and is sometimes unnecessary for the content ! provider. Implementors are encouraged to provide mechanisms whereby ! the amount of preemptive content negotiation, and the parameters of ! that negotiation, are configurable by the user and server ! maintainer. ! ! The first step in the negotiation algorithm is for the server to ! determine whether or not there are any content variants for the ! requested resource. Content variants may be in the form of multiple ! preexisting entities or a set of dynamic conversion filters. These ! variants make up the set of entities which may be sent in response ! to a request for the given Request-URI. In most cases, there will ! only be one available form of the resource, and thus a single ! "variant". ! ! For each variant form of the resource, the server identifies a set ! of quality values (Section 3.9) which act as weights for measuring ! the desirability of that resource as a response to the current ! request. The calculated weights are all real numbers in the range ! 0 through 1, where 0 is the minimum and 1 the maximum value. The ! maximum acceptable bytes for each media range and the size of the ! resource variant are also factors in the equation. ! ! The following parameters are included in the calculation: ! ! qs Source quality is measured by the content provider as ! representing the amount of degradation from the original ! source. For example, a picture originally in JPEG form ! would have a lower qs when translated to the XBM format, ! and much lower qs when translated to an ASCII-art ! representation. Note, however, that this is a function of ! the source -- an original piece of ASCII-art may degrade in ! quality if it is captured in JPEG form. The qs value should ! be assigned to each variant by the content provider; if no ! qs value has been assigned, the default is generally ! "qs=1". A server may define its own default qs value based ! on the resource characteristics, but only if individual ! resources can override those defaults. ! ! qe Encoding quality is measured by comparing the variant's ! applied encoding-mechanisms (Section 3.6) to those listed ! in the request message's Accept-Encoding field. If the ! variant has no assigned Content-Encoding, or if no Accept- ! Encoding field is present, the value assigned is "qe=1". If ! all of the variant's content encodings are listed in the ! Accept-Encoding field, then the value assigned is "qe=1". ! If any of the variant's content encodings are not listed in ! the provided Accept-Encoding field, then the value assigned ! is "qe=0.001". ! ! qc Charset quality is measured by comparing the variant media- ! type's charset parameter value (if any) to those character ! set encodings (Section 3.5) listed in the request message's ! Accept-Charset field. If the variant's media-type has no ! charset parameter, or the variant's charset is US-ASCII or ! ISO-8859-1, or if no Accept-Charset field is present, then ! the value assigned is "qc=1". If the variant's charset is ! listed in the Accept-Charset field, then the value assigned ! is "qc=1". Otherwise, if the variant's charset is not ! listed in the provided Accept-Encoding field, then the ! value assigned is "qc=0.001". ! ! ql Language quality is measured by comparing the variant's ! assigned language tag(s) (Section 3.8) to those listed in ! the request message's Accept-Language field. If no variant ! has an assigned Content-Language, or if no Accept-Language ! field is present, the value assigned is "ql=1". If at least ! one variant has an assigned content language, but the one ! currently under consideration does not, then it should be ! assigned the value "ql=0.5". If any of the variant's ! content languages are listed in the Accept-Language field, ! then the value assigned is the maximum of the "ql" ! parameter values for those language tags (Section 8.4); if ! there was no exact match and at least one of the Accept- ! Language field values is a complete subtag prefix of the ! content language tag(s), then the "ql" parameter value of ! the largest matching prefix is used. If none of the ! variant's content language tags or tag prefixes are listed ! in the provided Accept-Language field, then the value ! assigned is "ql=0.001". ! ! q Media type quality is measured by comparing the variant's ! assigned media type (Section 3.4) to those listed in the ! request message's Accept field. If no Accept field is ! given, then the value assigned is "q=1". If at least one ! listed media range (Section 8.1) matches the variant's ! media type, then the "q" parameter value assigned to the ! most specific of those matched is used (e.g., ! "text/html;version=3.0" is more specific than "text/html", ! which is more specific than "text/*", which in turn is more ! specific than "*/*"). If no media range in the provided ! Accept field matches the variant's media type, then the ! value assigned is "q=0". ! ! mxb The maximum number of bytes in an Entity-Body that the ! client will accept is also obtained from the matching of ! the variant's assigned media type to those listed in the ! request message's Accept field. If no Accept field is ! given, or if no media range in the provided Accept field ! matches the variant's media type, then the value assigned ! is "mxb=undefined" (i.e., infinity). Otherwise, the value ! used is that given to the "mxb" parameter in the media ! range chosen above for the q value. ! ! bs The actual number of bytes in the Entity-Body for the ! variant when it is included in a response message. This ! should equal the value of Content-Length. ! ! The mapping function is defined as: ! ! Q(qs,qe,qc,ql, { if mxb=undefined, then (qs*qe*qc*ql*q) } ! q,mxb,bs) = { if mxb >= bs, then (qs*qe*qc*ql*q) } ! { if mxb < bs, then 0 } ! ! The variants with a maximal value for the Q function represent the ! preferred representation(s) of the entity; those with a Q values ! less than the maximal value are therefore excluded from further ! consideration. If multiple representations exist that only vary by ! Content-Encoding, then the smallest representation (lowest bs) is ! preferred. ! ! If no variants remain with a value of Q greater than zero (0), the ! server should respond with a 406 (none acceptable) response ! message. If multiple variants remain with an equally high Q value, ! the server may either choose one from those available and respond ! with 200 (ok) or respond with 300 (multiple choices) and include an ! entity describing the choices. In the latter case, the entity ! should either be of type "text/html', such that the user can choose ! from among the choices by following an exact link, or of some type ! that would allow the user agent to perform the selection ! automatically. ! ! The 300 (multiple choices) response can be given even if the server ! does not perform any winnowing of the representation choices via ! the content negotiation algorithm described above. Furthermore, it ! may include choices that were not considered as part of the ! negotiation algorithm and resources that may be located at other ! servers. ! ! Servers that make use of content negotiated resources are strongly ! encouraged to include URI response headers which accurately ! describe the available variants and include the relevant parameters ! necessary for the client (user agent or proxy) to evaluate those ! variants. ! ! The algorithm presented above assumes that the user agent has ! correctly implemented the protocol and is accurately communicating ! its intentions in the form of Accept-related header fields. The ! server may alter its response if it knows that the particular ! version of user agent software making the request has incorrectly ! or inadequately implemented these fields. ! ! 10. Access Authentication ! ! HTTP provides a simple challenge-response authorization style which ! may be used by a server to challenge a client request and by a ! client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication ! scheme, followed by a semicolon-separated list of attribute-value ! pairs which carry the parameters necessary for achieving ! authentication via that scheme. ! auth-scheme = "basic" | token --- 2093,2118 ---- The WWW-Authenticate header field must be included in 401 ! (unauthorized) response messages. The field value consists of at ! least one challenge that indicates the authentication scheme(s) and ! parameters applicable to the Request-URI. ! WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge ! The HTTP access authentication process is described in Section 9. ! User agents must take special care in parsing the WWW-Authenticate ! field value if it contains more than one challenge, or if more than ! one WWW-Authenticate header field is provided, since the contents ! of a challenge may itself contain a comma-separated list of ! authentication parameters. ! 9. Access Authentication ! HTTP provides a simple challenge-response authentication mechanism ! which may be used by a server to challenge a client request and by ! a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication ! scheme, followed by a comma-separated list of attribute-value pairs ! which carry the parameters necessary for achieving authentication ! via that scheme. ! auth-scheme = token *************** *** 3340,3347 **** to challenge the authorization of a user agent. This response must ! include a WWW-Authenticate header field containing a challenge ! applicable to the requested resource. ! challenge = auth-scheme 1*SP realm *( ";" auth-param ) ! realm = "realm" "=" quoted-string --- 2122,2130 ---- to challenge the authorization of a user agent. This response must ! include a WWW-Authenticate header field containing at least one ! challenge applicable to the requested resource. ! challenge = auth-scheme 1*SP realm *( "," auth-param ) ! realm = "realm" "=" realm-value ! realm-value = quoted-string *************** *** 3349,3357 **** authentication schemes which issue a challenge. The realm value ! (case-sensitive), in combination with the root URL of the server ! being accessed, defines the protection space. These realms allow ! the protected resources on a server to be partitioned into a set of ! protection spaces, each with its own authentication scheme and/or ! authorization database. The realm value is a string, generally ! assigned by the origin server, which may have additional semantics ! specific to the authentication scheme. --- 2132,2140 ---- authentication schemes which issue a challenge. The realm value ! (case-sensitive), in combination with the canonical root URL of the ! server being accessed, defines the protection space. These realms ! allow the protected resources on a server to be partitioned into a ! set of protection spaces, each with its own authentication scheme ! and/or authorization database. The realm value is a string, ! generally assigned by the origin server, which may have additional ! semantics specific to the authentication scheme. *************** *** 3358,3377 **** A user agent that wishes to authenticate itself with a server-- ! usually, but not necessarily, after receiving a 401 or 411 response-- ! may do so by including an Authorization header field with the ! request. The Authorization field value consists of credentials ! containing the authentication information of the user agent for the ! realm of the resource being requested. ! credentials = auth-scheme [ 1*LWS encoded-cookie ] ! *(";" auth-param ) - encoded-cookie = <any valid base64 [6] encoded string, - except not limited to 76 char/line> - The domain over which credentials can be automatically applied by a ! user agent is determined by the authorization space. If a request ! is authenticated, the credentials can be reused for all other ! requests within that authorization space for a period of time ! determined by the authentication scheme, parameters, and/or user ! preference. --- 2141,2159 ---- A user agent that wishes to authenticate itself with a server-- ! usually, but not necessarily, after receiving a 401 response--may do ! so by including an Authorization header field with the request. The ! Authorization field value consists of credentials containing the ! authentication information of the user agent for the realm of the ! resource being requested. ! credentials = basic-credentials ! | ( auth-scheme #auth-param ) The domain over which credentials can be automatically applied by a ! user agent is determined by the protection space. If a prior ! request has been authorized, the same credentials may be reused for ! all other requests within that protection space for a period of ! time determined by the authentication scheme, parameters, and/or ! user preference. Unless otherwise defined by the authentication ! scheme, a single protection space cannot extend outside the scope ! of its server. *************** *** 3378,3384 **** If the server does not wish to accept the credentials sent with a ! request, it should return either a 403 (forbidden) or 411 ! (authorization refused) response. In the latter case, the response ! must include a WWW-Authenticate header field containing the ! (possibly new) challenge applicable to the requested resource and ! an entity explaining the refusal. --- 2160,2162 ---- If the server does not wish to accept the credentials sent with a ! request, it should return a 403 (forbidden) response. *************** *** 3393,3426 **** authentication. That is, they must forward the WWW-Authenticate and ! Authorization headers untouched. HTTP/1.0 does not provide a means ! for a client to be authenticated with a proxy. ! Note: The names Proxy-Authenticate and Proxy-Authorization ! have been suggested as headers, analogous to ! WWW-Authenticate and Authorization, but applying only to the ! immediate connection with a proxy. ! 10.1 Basic Authentication Scheme ! The basic authentication scheme is based on the model that the ! client must authenticate itself with a user-ID and a password for ! each realm. The realm value should be considered an opaque string ! which can only be compared for equality with other realms. The ! server will service the request only if it can validate the user-ID ! and password for the domain of the Request-URI. ! basic-challenge= "Basic" SP realm ! The client sends the user-ID and password, separated by a single ! colon ":" character, within a base64 [6] encoded-cookie in the ! credentials. ! basic-credentials="Basic" SP basic-cookie ! basic-cookie = <base64 encoding of userid-password> ! userid-password= [ token ] ":" *text ! There are no optional authentication parameters for the basic ! scheme. For example, if the user agent wishes to send the user-ID ! "Aladdin" and password "open sesame", it would use the following ! header field: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== --- 2171,2209 ---- authentication. That is, they must forward the WWW-Authenticate and ! Authorization headers untouched, and must not cache the response to ! a request containing Authorization. HTTP/1.0 does not provide a ! means for a client to be authenticated with a proxy. ! 9.1 Basic Authentication Scheme ! The "basic" authentication scheme is based on the model that the ! user agent must authenticate itself with a user-ID and a password ! for each realm. The realm value should be considered an opaque ! string which can only be compared for equality with other realms on ! that server. The server will authorize the request only if it can ! validate the user-ID and password for the protection space of the ! Request-URI. There are no optional authentication parameters. ! Upon receipt of an unauthorized request for a URI within the ! protection space, the server should respond with a challenge like ! the following: ! WWW-Authenticate: Basic realm="WallyWorld" ! where "WallyWorld" is the string assigned by the server to identify ! the protection space of the Request-URI. ! To receive authorization, the client sends the user-ID and ! password, separated by a single colon (":") character, within a ! base64 [5] encoded string in the credentials. ! basic-credentials = "Basic" SP basic-cookie + basic-cookie = <base64 [5] encoding of userid-password, + except not limited to 76 char/line> + + userid-password = [ token ] ":" *text + + If the user agent wishes to send the user-ID "Aladdin" and password + "open sesame", it would use the following header field: + Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== *************** *** 3436,3438 **** ! 11. Security Considerations --- 2219,2221 ---- ! 10. Security Considerations *************** *** 3444,3449 **** ! 11.1 Authentication of Clients ! As mentioned in Section 10.1, the Basic authentication scheme is ! not a secure method of user authentication, nor does it prevent the Entity-Body from being transmitted in clear text across the --- 2227,2232 ---- ! 10.1 Authentication of Clients ! As mentioned in Section 9.1, the Basic authentication scheme is not ! a secure method of user authentication, nor does it prevent the Entity-Body from being transmitted in clear text across the *************** *** 3450,3455 **** physical network used as the carrier. HTTP/1.0 does not prevent ! additional authentication schemes and encryption mechanisms to be ! employed to increase security. ! 11.2 Idempotent Methods --- 2233,2238 ---- physical network used as the carrier. HTTP/1.0 does not prevent ! additional authentication schemes and encryption mechanisms from ! being employed to increase security. ! 10.2 Idempotent Methods *************** *** 3456,3460 **** The writers of client software should be aware that the software ! represents the user in their interactions over the net, and should ! be careful to allow the user to be aware of any actions they may ! take which may have an unexpected significance to themselves or others. --- 2239,2243 ---- The writers of client software should be aware that the software ! represents the user in their interactions over the Internet, and ! should be careful to allow the user to be aware of any actions they ! may take which may have an unexpected significance to themselves or others. *************** *** 3465,3469 **** should not have side effects. This allows the client software to ! represent other methods, such as POST, PUT and DELETE, in a special ! way, so that the user is aware of the fact that an non-idempotent ! action is being requested. --- 2248,2252 ---- should not have side effects. This allows the client software to ! represent other methods, such as POST, in a special way so that the ! user is made aware of the fact that an non-idempotent action is ! being requested. *************** *** 3475,3477 **** ! 11.3 Abuse of Server Log Information --- 2258,2260 ---- ! 10.3 Abuse of Server Log Information *************** *** 3486,3488 **** ! 11.4 Transfer of Sensitive Information --- 2269,2271 ---- ! 10.4 Transfer of Sensitive Information *************** *** 3489,3491 **** Like any generic data transfer protocol, HTTP cannot regulate the ! content of the data that is transferred, nor is there any apriori method of determining the sensitivity of any particular piece of --- 2272,2274 ---- Like any generic data transfer protocol, HTTP cannot regulate the ! content of the data that is transferred, nor is there any a priori method of determining the sensitivity of any particular piece of *************** *** 3493,3497 **** applications are encouraged to supply as much control over this ! information as possible to the provider of that information. Four header fields are worth special mention in this context: Server, ! Forwarded, Referer and From. --- 2276,2280 ---- applications are encouraged to supply as much control over this ! information as possible to the provider of that information. Three header fields are worth special mention in this context: Server, ! Referer and From. *************** *** 3502,3509 **** - Proxies which serve as a gateway through a network firewall should - take special precautions regarding the transfer of header - information that identifies the hosts behind the firewall. In - particular, they should remove, or replace with sanitized versions, - any Forwarded fields generated behind the firewall. - The Referer field allows reading patterns to be studied and reverse --- 2285,2286 ---- *************** *** 3526,3528 **** ! 12. Acknowledgments --- 2303,2305 ---- ! 11. Acknowledgments *************** *** 3529,3533 **** This specification makes heavy use of the augmented BNF and generic ! constructs defined by David H. Crocker for RFC 822 [8]. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein ! and Ned Freed for MIME [6]. We hope that their inclusion in this specification will help reduce past confusion over the relationship --- 2306,2310 ---- This specification makes heavy use of the augmented BNF and generic ! constructs defined by David H. Crocker for RFC 822 [7]. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein ! and Ned Freed for MIME [5]. We hope that their inclusion in this specification will help reduce past confusion over the relationship *************** *** 3541,3543 **** Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, ! Jean Francois-Groff, Phillip M. Hallam-Baker, Haringkon W. Lie, Ari Luotonen, Rob McCool, Dave Raggett, Tony Sanders, and --- 2318,2320 ---- Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, ! Jean Francois-Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Dave Raggett, Tony Sanders, and *************** *** 3557,3578 **** Michael A. Dolan John Franks ! Marc Hedlund Koen Holtman ! Alex Hopmann Bob Jernigan ! Shel Kaphan Martijn Koster ! Dave Kristol Daniel LaLiberte ! Albert Lunde John C. Mallery ! Larry Masinter Mitra ! Gavin Nicol Bill Perry ! Jeffrey Perry Owen Rees ! David Robinson Marc Salomon ! Rich Salz Jim Seidman ! Chuck Shotton Eric W. Sink ! Simon E. Spero Robert S. Thau ! Francois Yergeau Mary Ellen Zurko ! 13. References ! [1] H. Alvestrand. "Tags for the identification of languages." ! RFC 1766, UNINETT, March 1995. ! ! [2] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, and B. Alberti. "The Internet Gopher Protocol: A distributed --- 2334,2353 ---- Michael A. Dolan John Franks ! Jim Gettys Marc Hedlund ! Koen Holtman Alex Hopmann ! Bob Jernigan Shel Kaphan ! Martijn Koster Dave Kristol ! Daniel LaLiberte Albert Lunde ! John C. Mallery Larry Masinter ! Mitra Gavin Nicol ! Bill Perry Jeffrey Perry ! Owen Rees David Robinson ! Marc Salomon Rich Salz ! Jim Seidman Chuck Shotton ! Eric W. Sink Simon E. Spero ! Robert S. Thau Francois Yergeau ! Mary Ellen Zurko ! 12. References ! [1] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, and B. Alberti. "The Internet Gopher Protocol: A distributed *************** *** 3581,3584 **** ! [3] T. Berners-Lee. "Universal Resource Identifiers in WWW: A ! Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web." --- 2356,2359 ---- ! [2] T. Berners-Lee. "Universal Resource Identifiers in WWW: ! A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web." *************** *** 3586,3592 **** ! [4] T. Berners-Lee and D. Connolly. "HyperText Markup Language Specification - 2.0." Work in Progress ! (draft-ietf-html-spec-04.txt), MIT/W3C, June 1995. ! [5] T. Berners-Lee, L. Masinter, and M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, University of --- 2361,2367 ---- ! [3] T. Berners-Lee and D. Connolly. "HyperText Markup Language Specification - 2.0." Work in Progress ! (draft-ietf-html-spec-05.txt), MIT/W3C, August 1995. ! [4] T. Berners-Lee, L. Masinter, and M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, University of *************** *** 3594,3596 **** ! [6] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing --- 2369,2371 ---- ! [5] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing *************** *** 3599,3601 **** ! [7] R. Braden. "Requirements for Internet hosts - application and support." STD 3, RFC 1123, IETF, October 1989. --- 2374,2376 ---- ! [6] R. Braden. "Requirements for Internet hosts - application and support." STD 3, RFC 1123, IETF, October 1989. *************** *** 3602,3604 **** ! [8] D. H. Crocker. "Standard for the Format of ARPA Internet Text Messages." STD 11, RFC 822, UDEL, August 1982. --- 2377,2379 ---- ! [7] D. H. Crocker. "Standard for the Format of ARPA Internet Text Messages." STD 11, RFC 822, UDEL, August 1982. *************** *** 3605,3607 **** ! [9] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype --- 2380,2382 ---- ! [8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype *************** *** 3610,3612 **** ! [10] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, UC Irvine, June 1995. --- 2385,2387 ---- ! [9] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, UC Irvine, June 1995. *************** *** 3613,3615 **** ! [11] M. Horton and R. Adams. "Standard for interchange of USENET messages." RFC 1036 (Obsoletes RFC 850), AT&T Bell --- 2388,2390 ---- ! [10] M. Horton and R. Adams. "Standard for interchange of USENET messages." RFC 1036 (Obsoletes RFC 850), AT&T Bell *************** *** 3617,3620 **** ! [12] B. Kantor and P. Lapsley. "Network News Transfer Protocol: A ! Proposed Standard for the Stream-Based Transmission of News." RFC 977, UC San Diego, UC Berkeley, February 1986. --- 2392,2395 ---- ! [11] B. Kantor and P. Lapsley. "Network News Transfer Protocol: ! A Proposed Standard for the Stream-Based Transmission of News." RFC 977, UC San Diego, UC Berkeley, February 1986. *************** *** 3621,3627 **** ! [13] K. Moore. "MIME (Multipurpose Internet Mail Extensions) Part ! Two: Message Header Extensions for Non-ASCII Text." RFC 1522, ! University of Tennessee, September 1993. ! ! [14] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821, USC/ISI, August 1982. --- 2396,2398 ---- ! [12] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821, USC/ISI, August 1982. *************** *** 3628,3630 **** ! [15] J. Postel. "Media Type Registration Procedure." RFC 1590, USC/ISI, March 1994. --- 2399,2401 ---- ! [13] J. Postel. "Media Type Registration Procedure." RFC 1590, USC/ISI, March 1994. *************** *** 3631,3633 **** ! [16] J. Postel and J. K. Reynolds. "File Transfer Protocol (FTP)." STD 9, RFC 959, USC/ISI, October 1985. --- 2402,2404 ---- ! [14] J. Postel and J. K. Reynolds. "File Transfer Protocol (FTP)." STD 9, RFC 959, USC/ISI, October 1985. *************** *** 3634,3636 **** ! [17] J. Reynolds and J. Postel. "Assigned Numbers." STD 2, RFC 1700, USC/ISI, October 1994. --- 2405,2407 ---- ! [15] J. Reynolds and J. Postel. "Assigned Numbers." STD 2, RFC 1700, USC/ISI, October 1994. *************** *** 3637,3639 **** ! [18] K. Sollins and L. Masinter. "Functional Requirements for Uniform Resource Names." RFC 1737, MIT/LCS, Xerox Corporation, --- 2408,2410 ---- ! [16] K. Sollins and L. Masinter. "Functional Requirements for Uniform Resource Names." RFC 1737, MIT/LCS, Xerox Corporation, *************** *** 3641,3643 **** ! [19] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, --- 2412,2414 ---- ! [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, *************** *** 3645,3654 **** ! [20] ISO-8859. International Standard -- Information Processing -- ! 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin ! Alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet No. 2, ! ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, ! 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: ! Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic ! alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO ! 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. --- 2416,2427 ---- ! [18] ISO-8859. International Standard -- Information Processing -- ! 8-bit Single-Byte Coded Graphic Character Sets -- ! Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. ! Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. ! Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. ! Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. ! Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. ! Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. ! Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. ! Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. *************** *** 3655,3657 **** ! 14. Authors' Addresses --- 2428,2430 ---- ! 13. Authors' Addresses *************** *** 3692,3694 **** as the specification for the Internet media type "message/http". ! The following is to be registered with IANA [15]. --- 2465,2467 ---- as the specification for the Internet media type "message/http". ! The following is to be registered with IANA [13]. *************** *** 3730,3733 **** However, we recommend that applications, when parsing such headers, ! recognize a single LF as a line terminator and ignore the leading ! CR. --- 2503,2505 ---- However, we recommend that applications, when parsing such headers, ! recognize a single LF as a line terminator and ignore the leading CR. *************** *** 3736,3739 **** HTTP/1.0 reuses many of the constructs defined for Internet Mail ! (RFC 822 [8]) and the Multipurpose Internet Mail Extensions ! (MIME [6]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, HTTP is --- 2508,2511 ---- HTTP/1.0 reuses many of the constructs defined for Internet Mail ! (RFC 822 [7]) and the Multipurpose Internet Mail Extensions ! (MIME [5]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, HTTP is *************** *** 3747,3751 **** MIME. Gateways to MIME-compliant protocols must be aware of these ! differences and provide the appropriate conversions where ! necessary. No conversion should be necessary for a MIME-conforming ! entity to be transferred using HTTP. --- 2519,2521 ---- MIME. Gateways to MIME-compliant protocols must be aware of these ! differences and provide the appropriate conversions where necessary. *************** *** 3754,3756 **** MIME requires that an entity be converted to canonical form prior ! to being transferred, as described in Appendix G of RFC 1521 [6]. Although HTTP does require media types to be transferred in --- 2524,2526 ---- MIME requires that an entity be converted to canonical form prior ! to being transferred, as described in Appendix G of RFC 1521 [5]. Although HTTP does require media types to be transferred in *************** *** 3757,3759 **** canonical form, it changes the definition of "canonical form" for ! text-based media types as described in Section 3.4.1. --- 2527,2529 ---- canonical form, it changes the definition of "canonical form" for ! text-based media types as described in Section 3.6.1. *************** *** 3763,3767 **** line breaks as CRLF and forbids the use of CR or LF outside of line ! break sequences. Since HTTP allows CRLF, bare CR, and bare LF ! (or the octet sequence(s) to which they would be translated for the ! given character set encoding) to indicate a line break within text content, recipients of an HTTP message cannot rely upon receiving --- 2533,2537 ---- line breaks as CRLF and forbids the use of CR or LF outside of line ! break sequences. Since HTTP allows CRLF, bare CR, and bare LF (or ! the octet sequence(s) to which they would be translated for the ! given coded character set) to indicate a line break within text content, recipients of an HTTP message cannot rely upon receiving *************** *** 3773,3779 **** complicated by the presence of a Content-Encoding and by the fact ! that HTTP allows the use of some character set encodings which do ! not use octets 13 and 10 to represent CR and LF, as is the case for ! some multi-byte character set encodings. ! C.1.2 Default Character Set Encoding --- 2543,2551 ---- complicated by the presence of a Content-Encoding and by the fact ! that HTTP allows the use of some coded character sets which do not ! use octets 13 and 10 to represent CR and LF, as is the case for ! some multi-byte coded character sets. If canonicalization is ! performed, the Content-Length header field value must be updated to ! reflect the new body length. ! C.1.2 Default Coded Character Set *************** *** 3780,3786 **** MIME requires that all subtypes of the top-level Content-Type ! "text" have a default character set encoding of US-ASCII [19]. ! In contrast, HTTP defines the default character set encoding for ! "text" to be ISO-8859-1 [20] (a superset of US-ASCII). Therefore, ! if a text/* media type given in the Content-Type header field does ! not already include an explicit charset parameter, the parameter --- 2552,2558 ---- MIME requires that all subtypes of the top-level Content-Type ! "text" have a default coded character set of US-ASCII [17]. In ! contrast, HTTP defines the default coded character set for "text" ! to be ISO-8859-1 [18] (a superset of US-ASCII). Therefore, if a ! text/* media type given in the Content-Type header field does not ! already include an explicit charset parameter, the parameter *************** *** 3791,3807 **** ! C.2 Default Content-Transfer-Encoding ! The default Content-Transfer-Encoding (CTE) for all MIME messages ! is "7bit". In contrast, HTTP defines the default CTE to be ! "binary". Therefore, if an entity does not include an explicit CTE ! header field, the gateway should apply either the ! "quoted-printable" or "base64" transfer encodings and add the ! appropriate Content-Transfer-Encoding field. At a minimum, the ! explicit CTE field of - Content-Transfer-Encoding: binary - - should be added by the gateway if it is unwilling to apply a - mail-safe transfer encoding. - C.3 Introduction of Content-Encoding --- 2563,2571 ---- ! C.2 Conversion of Date Formats ! HTTP/1.0 uses a restricted subset of date formats to simplify the ! process of date comparison. Gateways from other protocols should ! ensure that any Date header field present in a message conforms to ! one of the HTTP/1.0 formats and rewrite the date if necessary. C.3 Introduction of Content-Encoding *************** *** 3810,3812 **** Content-Encoding header field. Since this acts as a modifier on the ! media type, gateways to MIME-conformant protocols should either change the value of the Content-Type header field or decode the --- 2574,2576 ---- Content-Encoding header field. Since this acts as a modifier on the ! media type, gateways to MIME-conformant protocols must either change the value of the Content-Type header field or decode the *************** *** 3820,3821 **** --- 2584,2606 ---- of this writing. + + C.4 No Content-Transfer-Encoding + + HTTP does not use the Content-Transfer-Encoding (CTE) field of + MIME. Gateways from MIME-compliant protocols must remove any non- + identity CTE ("quoted-printable" or "base64") encoding prior to + delivering the response message to an HTTP client. Gateways to MIME- + compliant protocols are responsible for ensuring that the message + is in the correct format and encoding for safe transport on that + protocol, where "safe transport" is defined by the limitations of + the protocol being used. At a minimum, the CTE field of + + Content-Transfer-Encoding: binary + + should be added by the gateway if it is unwilling to apply a + transfer encoding. + + An HTTP client may include a Content-Transfer-Encoding as an + extension Entity-Header in a POST request when it knows the + destination of that request is a gateway to a MIME-compliant + protocol.