*** altered-draft-03.txt Sun Oct 15 17:19:27 1995 --- draft-ietf-http-v10-spec-04.txt Sun Oct 15 01:08:20 1995 *************** *** 2,5 **** INTERNET-DRAFT R. Fielding, UC Irvine ! H. Frystyk, MIT/LCS ! Expires March 4, 1996 September 4, 1995 --- 2,5 ---- INTERNET-DRAFT R. Fielding, UC Irvine ! H. Frystyk, MIT/LCS ! Expires April 14, 1996 October 14, 1995 *************** *** 43,47 **** systems, through extension of its request methods (commands). A ! feature of HTTP is the typing and negotiation of data ! representation, allowing systems to be built independently of the ! data being transferred. --- 43,46 ---- systems, through extension of its request methods (commands). A ! feature of HTTP is the typing of data representation, allowing ! systems to be built independently of the data being transferred. *************** *** 55,58 **** 1.1 Purpose ! 1.2 Overall Operation ! 1.3 Terminology --- 54,57 ---- 1.1 Purpose ! 1.2 Terminology ! 1.3 Overall Operation *************** *** 78,80 **** 4.2 Message Headers ! 4.3 General Message Header Fields --- 77,79 ---- 4.2 Message Headers ! 4.3 General Header Fields *************** *** 82,89 **** 5.1 Request-Line ! 5.2 Method ! 5.2.1 GET ! 5.2.2 HEAD ! 5.2.3 POST ! 5.3 Request-URI ! 5.4 Request Header Fields --- 81,85 ---- 5.1 Request-Line ! 5.1.1 Method ! 5.1.2 Request-URI ! 5.2 Request Header Fields *************** *** 91,99 **** 6.1 Status-Line ! 6.2 Status Codes and Reason Phrases ! 6.2.1 Informational 1xx ! 6.2.2 Successful 2xx ! 6.2.3 Redirection 3xx ! 6.2.4 Client Error 4xx ! 6.2.5 Server Errors 5xx ! 6.3 Response Header Fields --- 87,90 ---- 6.1 Status-Line ! 6.1.1 Status Code and Reason Phrase ! 6.2 Response Header Fields *************** *** 105,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 Safe 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 --- 96,143 ---- ! 8. Method Definitions ! 8.1 GET ! 8.2 HEAD ! 8.3 POST ! 9. Status Code Definitions ! 9.1 Informational 1xx ! 9.2 Successful 2xx ! 9.3 Redirection 3xx ! 9.4 Client Error 4xx ! 9.5 Server Error 5xx ! 10. Header Field Definitions ! 10.1 Allow ! 10.2 Authorization ! 10.3 Content-Encoding ! 10.4 Content-Length ! 10.5 Content-Type ! 10.6 Date ! 10.7 Expires ! 10.8 From ! 10.9 If-Modified-Since ! 10.10 Last-Modified ! 10.11 Location ! 10.12 MIME-Version ! 10.13 Pragma ! 10.14 Referer ! 10.15 Server ! 10.16 User-Agent ! 10.17 WWW-Authenticate ! 11. Access Authentication ! 11.1 Basic Authentication Scheme ! 12. Security Considerations ! 12.1 Authentication of Clients ! 12.2 Safe Methods ! 12.3 Abuse of Server Log Information ! 12.4 Transfer of Sensitive Information ! 13. Acknowledgments + 14. References + + 15. Authors' Addresses + Appendix A. Internet Media Type message/http *************** *** 169,174 **** simple retrieval, including search, front-end update, and ! annotation. HTTP/1.0 allows an open-ended set of methods to be used ! 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 --- 172,177 ---- simple retrieval, including search, front-end update, and ! annotation. HTTP allows an open-ended set of methods to be used 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 *************** *** 177,221 **** ! HTTP/1.0 is also used for communication between user agents and ! 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 ! protocols. ! 1.2 Overall Operation - The HTTP protocol is based on a request/response paradigm. A - requesting program (termed a client) establishes a connection with - a receiving program (termed a server) and sends a request to the - server in the form of a request method, URI, and protocol version, - followed by a MIME-like message containing request modifiers, - client information, and possible body content. The server responds - with a status line, including its protocol version and a success or - error code, followed by a MIME-like message containing server - information, entity metainformation, and possible body content. It - should be noted that a given program may be capable of being both a - client and a server; our use of those terms refers only to the role - being performed by the program during a particular connection, - rather than to the program's purpose in general. - - 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 - 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. - - 1.3 Terminology - This specification uses a number of terms to refer to the roles --- 180,190 ---- ! HTTP is also used as a generic protocol for communication between ! user agents and proxies/gateways to other Internet protocols, such ! as SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], ! allowing basic hypermedia access to resources available from ! diverse applications and simplifying the implementation of user ! agents. ! 1.2 Terminology This specification uses a number of terms to refer to the roles *************** *** 225,228 **** ! A virtual circuit established between two parties for the ! purpose of communication. --- 194,197 ---- ! A transport layer virtual circuit established between two ! application programs for the purpose of communication. *************** *** 230,233 **** ! A structured sequence of octets transmitted via the connection ! as the basic component of communication. --- 199,203 ---- ! The basic unit of HTTP communication, consisting of a structured ! sequence of octets matching the syntax defined in Section 4 and ! transmitted via the connection. *************** *** 248,253 **** ! A particular representation or rendition of a resource that may ! be enclosed within a request or response message. An entity ! consists of metainformation in the form of entity headers and ! content in the form of an entity body. --- 218,224 ---- ! A particular representation or rendition of a data resource, or ! reply from a service resource, that may be enclosed within a ! request or response message. An entity consists of ! metainformation in the form of entity headers and content in the ! form of an entity body. *************** *** 255,258 **** ! A program that establishes connections for the purpose of ! sending requests. --- 226,229 ---- ! An application program that establishes connections for the ! purpose of sending requests. *************** *** 260,263 **** ! 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 --- 231,233 ---- ! The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user *************** *** 267,270 **** ! A program that accepts connections in order to service requests ! by sending back responses. --- 237,240 ---- ! An application program that accepts connections in order to ! service requests by sending back responses. *************** *** 277,286 **** An intermediary program which acts as both a server and a client ! for the purpose of forwarding requests. Proxies are often used ! to act as a portal through a network firewall. A proxy server ! accepts requests from other clients and services them either ! internally or by passing them, with possible translation, on to ! other servers. A caching proxy is a proxy server with a local ! cache of server responses -- some requested resources can be ! serviced from the cache rather than from the origin server. Some ! proxy servers also act as origin servers. --- 247,256 ---- An intermediary program which acts as both a server and a client ! for the purpose of making requests on behalf of other clients. ! Requests are serviced internally or by passing them, with ! possible translation, on to other servers. A proxy must ! interpret and, if necessary, rewrite a request message before ! forwarding it. Proxies are often used as client-side portals ! through network firewalls and as helper applications for ! handling requests via protocols not implemented by the user ! agent. *************** *** 288,294 **** ! A proxy which services HTTP requests by translation into ! protocols other than HTTP. The reply sent from the remote server ! to the gateway is likewise translated into HTTP before being ! forwarded to the user agent. 2. Notational Conventions and Generic Grammar --- 258,379 ---- ! A server which acts as an intermediary for some other server. ! Unlike a proxy, a gateway receives requests as if it were the ! origin server for the requested resource; the requesting client ! may not be aware that it is communicating with a gateway. ! Gateways are often used as server-side portals through network ! firewalls and as protocol translators for access to resources ! stored on non-HTTP systems. + tunnel + + A tunnel is an intermediary program which is acting as a blind + relay between two connections. Once active, a tunnel is not + considered a party to the HTTP communication, though the tunnel + may have been initiated by an HTTP request. A tunnel is closed + when both ends of the relayed connections are closed. Tunnels + are used when a portal is necessary and the intermediary cannot, + or should not, interpret the relayed communication. + + cache + + A program's local store of response messages and the subsystem + that controls its message storage, retrieval, and deletion. A + cache stores cachable responses in order to reduce the response + time and network bandwidth consumption on future, equivalent + requests. Any client or server may include a cache, though a + cache cannot be used by a server while it is acting as a tunnel. + + Any given program may be capable of being both a client and a + server; our use of these terms refers only to the role being + performed by the program for a particular connection, rather than + to the program's capabilities in general. Likewise, any server may + act as an origin server, proxy, gateway, or tunnel, switching + behavior based on the nature of each request. + + 1.3 Overall Operation + + The HTTP protocol is based on a request/response paradigm. A client + establishes a connection with a server and sends a request to the + server in the form of a request method, URI, and protocol version, + followed by a MIME-like message containing request modifiers, + client information, and possible body content. The server responds + with a status line, including the message's protocol version and a + success or error code, followed by a MIME-like message containing + server information, entity metainformation, and possible body + content. + + Most HTTP communication is initiated by a user agent and consists + of a request to be applied to a resource on some origin server. In + the simplest case, this may be accomplished via a single connection + (v) between the user agent (UA) and the origin server (O). + + request chain ------------------------> + UA -------------------v------------------- O + <----------------------- response chain + + A more complicated situation occurs when one or more intermediaries + are present in the request/response chain. There are three common + forms of intermediary: proxy, gateway, and tunnel. A proxy is a + forwarding agent, receiving requests for a URI in its absolute + form, rewriting all or parts of the message, and forwarding the + reformatted request toward the server identified by the URI. A + gateway is a receiving agent, acting as a layer above some other + server(s) and, if necessary, translating the requests to the + underlying server's protocol. A tunnel acts as a relay point + between two connections without changing the messages; tunnels are + used when the communication needs to pass through an intermediary + (such as a firewall) even when the intermediary cannot understand + the contents of the messages. + + request chain --------------------------------------> + UA -----v----- A -----v----- B -----v----- C -----v----- O + <------------------------------------- response chain + + The figure above shows three intermediaries (A, B, and C) between + the user agent and origin server. A request or response message + that travels the whole chain must pass through four separate + connections. This distinction is important because some HTTP + communication options may apply only to the connection with the + nearest, non-tunnel neighbor, only to the end-points of the chain, + or to all connections along the chain. Although the diagram is + linear, each participant may be engaged in multiple, simultaneous + communications. For example, B may be receiving requests from many + clients other than A, and/or forwarding requests to servers other + than C, at the same time that it is handling A's request. + + Any party to the communication which is not acting as a tunnel may + employ an internal cache for handling requests. The effect of a + cache is that the request/response chain is shortened if one of the + participants along the chain has a cached response applicable to + that request. The following illustrates the resulting chain if B + has a cached copy of an earlier response from O (via C) for a + request which has not been cached by UA or A. + + request chain ----------> + UA -----v----- A -----v----- B - - - - - - C - - - - - - O + <--------- response chain + + Not all responses are cachable, and some requests may contain + modifiers which place special requirements on cache behavior. + Historically, HTTP/1.0 applications have not adequately defined + what is or is not a "cachable" response. + + On the Internet, HTTP communication generally takes place over + TCP/IP connections. The default port is TCP 80 [15], but other + ports can be used. This does not preclude HTTP from 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. + 2. Notational Conventions and Generic Grammar *************** *** 378,381 **** The grammar described by this specification is word-based. ! Except where noted otherwise, zero or more linear whitespace ! (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent tokens and delimiters --- 463,466 ---- The grammar described by this specification is word-based. ! Except where noted otherwise, linear whitespace (LWS) can be ! included between any two adjacent words (token or quoted-string), and between adjacent tokens and delimiters *************** *** 415,419 **** ! HTTP/1.0 headers may be folded onto multiple lines if the ! continuation lines begin with linear whitespace characters. All ! linear whitespace, including folding, has the same semantics as SP. --- 500,504 ---- ! HTTP/1.0 headers may be folded onto multiple lines if each ! continuation line begins with a space or horizontal tab. All linear ! whitespace, including folding, has the same semantics as SP. *************** *** 424,425 **** --- 509,522 ---- + The TEXT rule is only used for descriptive field contents and + values that are not intended to be interpreted by the message + parser. Words of *TEXT may contain octets from character sets other + than US-ASCII. + + TEXT = + + Recipients of header field TEXT containing octets outside the + US-ASCII character set may assume that they represent ISO-8859-1 + characters. + Many HTTP/1.0 header field values consist of words separated by LWS *************** *** 442,444 **** comment = "(" *( ctext | comment ) ")" ! ctext = --- 539,541 ---- comment = "(" *( ctext | comment ) ")" ! ctext = *************** *** 455,468 **** - The text rule is only used for descriptive field contents and - values that are not intended to be interpreted by the message - parser. Words of *text may contain octets from character sets other - than US-ASCII. - - text = - - Recipients of header field text containing octets outside the - US-ASCII character set may assume that they represent ISO-8859-1 - characters. - 3. Protocol Parameters --- 552,553 ---- *************** *** 521,532 **** ! Proxies must be careful in forwarding requests that are received in ! a format different than that of the proxy's native version. Since ! the protocol version indicates the protocol capability of the ! sender, a proxy must never send a message with a version indicator ! which is greater than its native version; if a higher version ! request is received, the proxy must either downgrade the request ! version or respond with an error. Requests with a version lower ! than that of the proxy's native format may be upgraded by the proxy ! before being forwarded; the proxy's response to that request must ! follow the normal server requirements. --- 606,618 ---- ! Proxy and gateway applications must be careful in forwarding ! requests that are received in a format different than that of the ! application's native HTTP version. Since the protocol version ! indicates the protocol capability of the sender, a proxy/gateway ! must never send a message with a version indicator which is greater ! than its native version; if a higher version request is received, ! the proxy/gateway must either downgrade the request version or ! respond with an error. Requests with a version lower than that of ! the application's native format may be upgraded before being ! forwarded; the proxy/gateway's response to that request must follow ! the normal server requirements. *************** *** 584,587 **** ! 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, --- 670,673 ---- ! 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, *************** *** 599,601 **** ! host = port = *DIGIT --- 685,690 ---- ! host = ! port = *DIGIT *************** *** 609,610 **** --- 698,704 ---- + Note: Although the HTTP protocol is independent of the + transport layer protocol, the http URL only identifies + resources by their TCP location, and thus non-TCP resources + must be identified by some other URI scheme. + The canonical form for "http" URLs is obtained by converting any *************** *** 634,636 **** non-HTTP applications, as is sometimes the case when ! retrieving or posting messages via gateways to SMTP or NNTP. --- 728,731 ---- non-HTTP applications, as is sometimes the case when ! retrieving or posting messages via proxies/gateways to SMTP ! or NNTP. *************** *** 716,720 **** Character Set registry [15] must represent the character set ! defined by that registry. Applications are encouraged, but not ! required, to limit their use of character sets to those defined by ! the IANA registry. --- 811,814 ---- Character Set registry [15] must represent the character set ! defined by that registry. Applications should limit their use of ! character sets to those defined by the IANA registry. *************** *** 728,734 **** Content coding values are used to indicate an encoding ! transformation that has been or can be applied to a resource. ! Content codings 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. --- 822,828 ---- Content coding values are used to indicate an encoding ! transformation that has been applied to a resource. Content codings ! 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. *************** *** 741,743 **** All content-coding values are case-insensitive. HTTP/1.0 uses ! content-coding values in the Content-Encoding (Section 8.3) header field. Although the value describes the content-coding, what is --- 835,837 ---- All content-coding values are case-insensitive. HTTP/1.0 uses ! content-coding values in the Content-Encoding (Section 10.3) header field. Although the value describes the content-coding, what is *************** *** 767,778 **** ! 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 ! no type negotiation between sender and receiver, it is reasonable ! 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. --- 861,871 ---- ! HTTP uses Internet Media Types [13] in the Content-Type header ! field (Section 10.5) in order to provide open and extensible data ! typing. For mail applications, where there is no type negotiation ! between sender and recipient, it is reasonable 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. *************** *** 809,815 **** All media-type's registered by IANA must be preferred over ! extension tokens. However, HTTP does not limit conforming ! applications to the use of officially registered media types, nor ! does it encourage the use of an "x-" prefix for unofficial types ! outside of explicitly short experimental use between consenting ! applications. --- 902,907 ---- All media-type's registered by IANA must be preferred over ! extension tokens. However, HTTP does not limit applications to the ! use of officially registered media types, nor does it encourage the ! use of an "x-" prefix for unofficial types outside of explicitly ! short experimental use between consenting applications. *************** *** 923,927 **** 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). --- 1015,1019 ---- RFC 822 [7] for transferring entities. Both messages may include ! optional header fields (also known as "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). *************** *** 929,931 **** *( General-Header ; Section 4.3 ! | Request-Header ; Section 5.4 | Entity-Header ) ; Section 7.1 --- 1021,1023 ---- *( General-Header ; Section 4.3 ! | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 *************** *** 936,938 **** *( General-Header ; Section 4.3 ! | Response-Header ; Section 6.3 | Entity-Header ) ; Section 7.1 --- 1028,1030 ---- *( General-Header ; Section 4.3 ! | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 *************** *** 954,956 **** HTTP header fields, which include General-Header (Section 4.3), ! Request-Header (Section 5.4), Response-Header (Section 6.3), and Entity-Header (Section 7.1) fields, follow the same generic format --- 1046,1048 ---- HTTP header fields, which include General-Header (Section 4.3), ! Request-Header (Section 5.2), Response-Header (Section 6.2), and Entity-Header (Section 7.1) fields, follow the same generic format *************** *** 960,963 **** 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. --- 1052,1055 ---- case-insensitive. Header fields can be extended over multiple lines ! by preceding each extra line with at least one SP or HT, though ! this is not recommended. *************** *** 965,967 **** ! field-name = 1* field-value = *( field-content | LWS ) --- 1057,1059 ---- ! field-name = token field-value = *( field-content | LWS ) *************** *** 969,971 **** field-content = --- 1061,1063 ---- field-content = *************** *** 985,987 **** ! 4.3 General Message Header Fields --- 1077,1079 ---- ! 4.3 General Header Fields *************** *** 989,999 **** 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. ! General-Header = Date ; Section 8.6 ! | MIME-Version ; Section 8.12 ! | Pragma ; Section 8.13 ! General header field names can be extended only via a change in the ! protocol version. Unknown header fields are treated as Entity-Header fields. --- 1081,1094 ---- both request and response messages, but which do not apply to the ! entity being transferred. These headers apply only to the message ! being transmitted. ! General-Header = Date ; Section 10.6 ! | MIME-Version ; Section 10.12 ! | Pragma ; Section 10.13 ! General header field names can be extended reliably only in ! combination with a change in the protocol version. However, new or ! experimental header fields may be given the semantics of general ! header fields if all parties in the communication recognize them to ! be general header fields. Unknown header fields are treated as Entity-Header fields. *************** *** 1004,1009 **** first line of that message, the method to be applied to the ! resource requested, the identifier of the resource, and the ! protocol version in use. For backwards compatibility with the more ! limited HTTP/0.9 protocol, there are two valid formats for an HTTP ! request: --- 1099,1103 ---- first line of that message, the method to be applied to the ! resource, the identifier of the resource, and the protocol version ! in use. For backwards compatibility with the more limited HTTP/0.9 ! protocol, there are two valid formats for an HTTP request: *************** *** 1015,1017 **** *( General-Header ; Section 4.3 ! | Request-Header ; Section 5.4 | Entity-Header ) ; Section 7.1 --- 1109,1111 ---- *( General-Header ; Section 4.3 ! | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 *************** *** 1037,1039 **** ! 5.2 Method --- 1131,1133 ---- ! 5.1.1 Method *************** *** 1043,1045 **** ! Method = "GET" | "HEAD" | "POST" | extension-method --- 1137,1141 ---- ! Method = "GET" ; Section 8.1 ! | "HEAD" ; Section 8.2 ! | "POST" ; Section 8.3 | extension-method *************** *** 1054,1057 **** ! 5.3 Request-URI The Request-URI is a Uniform Resource Identifier (Section 3.2) and --- 1150,1156 ---- ! The methods commonly used by HTTP/1.0 applications are fully ! defined in Section 8. + 5.1.2 Request-URI + The Request-URI is a Uniform Resource Identifier (Section 3.2) and *************** *** 1065,1068 **** The absoluteURI form is only allowed when the request is being made ! to a proxy server. The proxy is requested to forward the request ! and return the response. If the request is GET or HEAD and a response is cached, the proxy may use the cached message if it --- 1164,1167 ---- The absoluteURI form is only allowed when the request is being made ! to a proxy. The proxy is requested to forward the request and ! return the response. If the request is GET or HEAD and a prior response is cached, the proxy may use the cached message if it *************** *** 1070,1074 **** 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: --- 1169,1173 ---- proxy may forward the request on to another proxy or directly to ! the 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: *************** *** 1078,1084 **** The most common form of Request-URI is that used to identify a ! 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: --- 1177,1183 ---- The most common form of Request-URI is that used to identify a ! resource on an origin server or gateway. 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: *************** *** 1090,1093 **** ! 5.4 Request Header Fields The request header fields allow the client to pass additional --- 1189,1197 ---- ! The Request-URI is transmitted as an encoded string, where some ! characters may be escaped using the "% hex hex" encoding defined by ! RFC 1738 [4]. The origin server must decode the Request-URI in ! order to properly interpret the request. + 5.2 Request Header Fields + The request header fields allow the client to pass additional *************** *** 1097,1106 **** ! 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 ! Request-Header field names can be extended only via a change in the ! protocol version. Unknown header fields are treated as Entity-Header fields. --- 1201,1213 ---- ! Request-Header = Authorization ; Section 10.2 ! | From ; Section 10.8 ! | If-Modified-Since ; Section 10.9 ! | Referer ; Section 10.14 ! | User-Agent ; Section 10.16 ! Request-Header field names can be extended reliably only in ! combination with a change in the protocol version. However, new or ! experimental header fields may be given the semantics of request ! header fields if all parties in the communication recognize them to ! be request header fields. Unknown header fields are treated as Entity-Header fields. *************** *** 1114,1116 **** ! Simple-Response= [ Entity-Body ] --- 1221,1223 ---- ! Simple-Response = [ Entity-Body ] *************** *** 1118,1120 **** *( General-Header ; Section 4.3 ! | Response-Header ; Section 6.3 | Entity-Header ) ; Section 7.1 --- 1225,1227 ---- *( General-Header ; Section 4.3 ! | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 *************** *** 1154,1156 **** ! 6.2 Status Codes and Reason Phrases --- 1261,1263 ---- ! 6.1.1 Status Code and Reason Phrase *************** *** 1185,1187 **** recommended -- they may be replaced by local equivalents without ! affecting the protocol. --- 1292,1294 ---- recommended -- they may be replaced by local equivalents without ! affecting the protocol. These codes are fully defined in Section 9. *************** *** 1206,1208 **** ! Reason-Phrase = * --- 1313,1315 ---- ! Reason-Phrase = * *************** *** 1218,1225 **** 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. ! 6.3 Response Header Fields --- 1325,1331 ---- treat the response as if it had received a 400 status code. In such ! cases, user agents should present to the user the entity returned ! with the response, since that entity is likely to include ! human-readable information which will explain the unusual status. ! 6.2 Response Header Fields *************** *** 1231,1238 **** ! Response-Header = Location ; Section 8.11 ! | Server ; Section 8.15 ! | WWW-Authenticate ; Section 8.17 ! Response-Header field names can be extended only via a change in ! the protocol version. Unknown header fields are treated as Entity-Header fields. --- 1337,1347 ---- ! Response-Header = Location ; Section 10.11 ! | Server ; Section 10.15 ! | WWW-Authenticate ; Section 10.17 ! Response-Header field names can be extended reliably only in ! combination with a change in the protocol version. However, new or ! experimental header fields may be given the semantics of response ! header fields if all parties in the communication recognize them to ! be response header fields. Unknown header fields are treated as Entity-Header fields. *************** *** 1253,1260 **** ! 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 --- 1362,1369 ---- ! Entity-Header = Allow ; Section 10.1 ! | Content-Encoding ; Section 10.3 ! | Content-Length ; Section 10.4 ! | Content-Type ; Section 10.5 ! | Expires ; Section 10.7 ! | Last-Modified ; Section 10.10 | extension-header *************** *** 1261,1268 **** ! extension-header=HTTP-header ! The extension-header mechanism allows additional Entity-Header to ! be defined without changing the protocol, but these fields cannot ! be assumed to be recognizable by the recipient. Unknown header ! fields should be ignored by the recipient and forwarded by proxies. --- 1370,1378 ---- ! extension-header = HTTP-header ! The extension-header mechanism allows additional Entity-Header ! fields to be defined without changing the protocol, but these ! fields cannot be assumed to be recognizable by the recipient. ! Unknown header fields should be ignored by the recipient and ! forwarded by proxies. *************** *** 1270,1272 **** ! The entity-body (if any) sent with an HTTP/1.0 request or response is in a format and encoding defined by the Entity-Header fields. --- 1380,1382 ---- ! The entity body (if any) sent with an HTTP/1.0 request or response is in a format and encoding defined by the Entity-Header fields. *************** *** 1275,1285 **** ! 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. ! For response messages, whether or not an entity-body is included with a message is dependent on both the request method and the --- 1385,1393 ---- ! An entity body is included with a request message only when the ! request method calls for one. 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 ! an entity body must include a valid Content-Length header field. ! For response messages, whether or not an entity body is included with a message is dependent on both the request method and the *************** *** 1286,1290 **** response code. All responses to the HEAD request method must not ! include a body, even though the presence of content header fields ! may lead one to believe they do. The responses 204 (no content) and ! 304 (not modified) must not include a message body. --- 1394,1400 ---- response code. All responses to the HEAD request method must not ! include a body, even though the presence of entity header fields ! may lead one to believe they do. All 1xx (informational), 204 (no ! content), and 304 (not modified) responses must not include a body. ! All other responses must include an entity body or a Content-Length ! header field defined with a value of zero (0). *************** *** 1305,1313 **** ! The Content-Type header field has no default value. If and only if ! the media type is not given by a Content-Type header, as is always ! the case for Simple-Response messages, the receiver may attempt to ! guess the media type via inspection of its content and/or the name ! extension(s) of the URL used to specify the resource. If the media ! type remains unknown, the receiver should treat it as type ! "application/octet-stream". --- 1415,1424 ---- ! Any HTTP/1.0 message containing an entity body should include a ! Content-Type header field defining the media type of that body. If ! and only if the media type is not given by a Content-Type header, ! as is the case for Simple-Response messages, the recipient may ! attempt to guess the media type via inspection of its content ! and/or the name extension(s) of the URL used to identify the ! resource. If the media type remains unknown, the recipient should ! treat it as type "application/octet-stream". *************** *** 1316,1318 **** When an Entity-Body is included with a message, the length of that ! body may be determined in one of several ways. If a Content-Length header field is present, its value in bytes represents the length --- 1427,1429 ---- When an Entity-Body is included with a message, the length of that ! body may be determined in one of two ways. If a Content-Length header field is present, its value in bytes represents the length *************** *** 1323,1326 **** 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 --- 1434,1437 ---- request body, since it leaves no possibility for the server to send ! back a response. Therefore, HTTP/1.0 requests containing an entity ! body must include a valid Content-Length header field. If a request contains an entity body and Content-Length is not specified, and *************** *** 1338,1347 **** ! ===moved for diff=== ! The set of common methods for HTTP/1.0 is described below. Although ! this set can be easily expanded, additional methods cannot be ! assumed to share the same semantics for separately extended clients ! and servers. ! 5.2.1 GET --- 1449,1458 ---- ! 8. Method Definitions ! The set of common methods for HTTP/1.0 is defined below. Although ! this set can be expanded, additional methods cannot be assumed to ! share the same semantics for separately extended clients and ! servers. ! 8.1 GET *************** *** 1358,1360 **** 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 --- 1469,1471 ---- transferred only if it has been modified since the date given by ! the If-Modified-Since header, as described in Section 10.9. The conditional GET method is intended to reduce network usage by *************** *** 1363,1365 **** ! 5.2.2 HEAD --- 1474,1476 ---- ! 8.2 HEAD *************** *** 1378,1380 **** ! 5.2.3 POST --- 1489,1491 ---- ! 8.3 POST *************** *** 1420,1424 **** ! Caching intermediaries must not cache responses to a POST request. ! ===moved for diff=== --- 1531,1535 ---- ! Applications must not cache responses to a POST request. ! 9. Status Code Definitions *************** *** 1428,1430 **** ! 6.2.1 Informational 1xx --- 1539,1541 ---- ! 9.1 Informational 1xx *************** *** 1437,1439 **** ! 6.2.2 Successful 2xx --- 1548,1550 ---- ! 9.2 Successful 2xx *************** *** 1447,1450 **** ! GET an entity corresponding to the requested resource is being ! sent in the response; --- 1558,1561 ---- ! GET an entity corresponding to the requested resource is sent ! in the response; *************** *** 1459,1465 **** 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. --- 1570,1576 ---- created. The newly created resource can be referenced by the URI(s) ! returned in the entity of the response. The origin server should ! create the resource before using this Status-Code. If the action ! cannot be carried out immediately, the server must include in the ! response body a description of when the resource will be available; ! otherwise, the server should respond with 202 (accepted). *************** *** 1496,1498 **** ! 6.2.3 Redirection 3xx --- 1607,1609 ---- ! 9.3 Redirection 3xx *************** *** 1517,1519 **** 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. --- 1628,1630 ---- If the server has a preferred choice, it should include the URL in ! a Location field; user agents may use this field value for automatic redirection. *************** *** 1524,1528 **** 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. --- 1635,1639 ---- any future references to this resource should be done using that ! URL. Clients with link editing capabilities should automatically ! relink references to the Request-URI to the new reference returned ! by the server, where possible. *************** *** 1556,1558 **** allowed, but the document has not been modified since the date and ! time specified in the If-Modified-Since field, the server shall respond with this status code and not send an Entity-Body to the --- 1667,1669 ---- allowed, but the document has not been modified since the date and ! time specified in the If-Modified-Since field, the server must respond with this status code and not send an Entity-Body to the *************** *** 1559,1565 **** client. Header fields contained in the response should only include ! information which is relevant to cache managers and which may have changed independently of the entity's Last-Modified date. Examples ! of relevant header fields include: Date, Server, and Expires. ! 6.2.4 Client Error 4xx --- 1670,1678 ---- client. Header fields contained in the response should only include ! information which is relevant to cache managers or which may have changed independently of the entity's Last-Modified date. Examples ! of relevant header fields include: Date, Server, and Expires. A ! cache should update its cached entity to reflect any new field ! values given in the 304 response. ! 9.4 Client Error 4xx *************** *** 1569,1574 **** sending data to the server. Except when responding to a HEAD ! request, the server is encouraged to include an entity containing ! an explanation of the error situation, and whether it is a ! temporary or permanent condition. These status codes are applicable ! to any request method. --- 1682,1687 ---- sending data to the server. Except when responding to a HEAD ! request, the server should include an entity containing an ! explanation of the error situation, and whether it is a temporary ! or permanent condition. These status codes are applicable to any ! request method. *************** *** 1587,1590 **** The request could not be understood by the server due to malformed ! syntax. The client is discouraged from repeating the request ! without modifications. --- 1700,1703 ---- The request could not be understood by the server due to malformed ! syntax. The client should not repeat the request without ! modifications. *************** *** 1593,1605 **** 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 ! repeat the request with a suitable Authorization header field. If ! the request already included Authorization credentials, then the ! 401 response indicates that authorization has been refused for ! those credentials. If the 401 response contains the same challenge ! as the prior response, and the user agent has already attempted ! authentication at least once, then the user should be presented the ! entity that was given in the response, since that entity may ! include relevent diagnostic information. HTTP access authentication ! is explained in Section 9. --- 1706,1718 ---- The request requires user authentication. The response must include ! a WWW-Authenticate header field (Section 10.17) containing a challenge applicable to the requested resource. The client may ! repeat the request with a suitable Authorization header field ! (Section 10.2). If the request already included Authorization ! credentials, then the 401 response indicates that authorization has ! been refused for those credentials. If the 401 response contains ! the same challenge as the prior response, and the user agent has ! already attempted authentication at least once, then the user ! should be presented the entity that was given in the response, ! since that entity may include relevent diagnostic information. HTTP ! access authentication is explained in Section 11. *************** *** 1607,1613 **** ! 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. --- 1720,1729 ---- ! The server understood the request, but is refusing to fulfill it. ! Authorization will not help and the request should not be repeated. ! If the request method was not HEAD and the server wishes to make ! public why the request has not been fulfilled, it should describe ! the reason for the refusal in the entity body. This status code is ! commonly used when the server does not wish to reveal exactly why ! the request has been refused, or when no other response is ! applicable. *************** *** 1621,1623 **** ! 6.2.5 Server Errors 5xx --- 1737,1739 ---- ! 9.5 Server Error 5xx *************** *** 1628,1631 **** data to the server. Except when responding to a HEAD request, the ! server is encouraged to include an entity containing an explanation ! of the error situation, and whether it is a temporary or permanent condition. These response codes are applicable to any request --- 1744,1747 ---- data to the server. Except when responding to a HEAD request, the ! server should include an entity containing an explanation of the ! error situation, and whether it is a temporary or permanent condition. These response codes are applicable to any request *************** *** 1647,1650 **** ! The server received an invalid response from the gateway or ! upstream server it accessed in attempting to fulfill the request. --- 1763,1767 ---- ! The server, while acting as a gateway or proxy, received an invalid ! response from the upstream server it accessed in attempting to ! fulfill the request. *************** *** 1661,1677 **** ! 8. Header Field Definitions ! This section defines the syntax and semantics of all standard ! HTTP/1.0 header fields. For Entity-Header fields, both sender and ! recipient refer to either the client or the server, depending on ! who sends and who receives the entity. ! 8.1 Allow ! The Allow header field lists the set of methods supported by the ! resource identified by the Request-URI. The purpose of this field ! 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. --- 1778,1794 ---- ! 10. Header Field Definitions ! This section defines the syntax and semantics of all commonly used ! HTTP/1.0 header fields. For general and entity header fields, both ! sender and recipient refer to either the client or the server, ! depending on who sends and who receives the message. ! 10.1 Allow ! The Allow entity-header field lists the set of methods supported by ! the resource identified by the Request-URI. The purpose of this ! field 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. *************** *** 1684,1691 **** This field cannot prevent a client from trying other methods. ! However, the indications given by the Allow field value should be ! followed. This field has no default value; if left undefined, the ! set of allowed methods is defined by the origin server at the time ! of each request. ! A proxy must not modify the allow header even if it does not understand all the methods specified, since the user agent may have --- 1801,1807 ---- This field cannot prevent a client from trying other methods. ! However, the indications given by the Allow header field value ! should be followed. The actual set of allowed methods is defined by ! the origin server at the time of each request. ! A proxy must not modify the Allow header field even if it does not understand all the methods specified, since the user agent may have *************** *** 1696,1698 **** ! 8.2 Authorization --- 1812,1814 ---- ! 10.2 Authorization *************** *** 1700,1705 **** 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. --- 1816,1821 ---- server--usually, but not necessarily, after receiving a 401 ! response--may do so by including an Authorization request-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. *************** *** 1707,1709 **** ! HTTP access authentication is described in Section 9. If a request is authenticated and a realm specified, the same credentials should --- 1823,1825 ---- ! HTTP access authentication is described in Section 11. If a request is authenticated and a realm specified, the same credentials should *************** *** 1711,1719 **** ! 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 ! media-type. When present, its value indicates what additional content coding has been applied to the resource, and thus what --- 1827,1835 ---- ! Responses to requests containing an Authorization field are not ! cachable. ! 10.3 Content-Encoding ! The Content-Encoding entity-header field is used as a modifier to ! the media-type. When present, its value indicates what additional content coding has been applied to the resource, and thus what *************** *** 1734,1738 **** ! 8.4 Content-Length ! The Content-Length header field indicates the size of the Entity-Body, in decimal number of octets, sent to the recipient or, --- 1850,1854 ---- ! 10.4 Content-Length ! The Content-Length entity-header field indicates the size of the Entity-Body, in decimal number of octets, sent to the recipient or, *************** *** 1747,1751 **** ! Although it is not required, applications are strongly encouraged ! to use this field to indicate the size of the Entity-Body to be ! transferred, regardless of the media type of the entity. --- 1863,1868 ---- ! Applications should use this field to indicate the size of the ! Entity-Body to be transferred, regardless of the media type of the ! entity. A valid Content-Length field value is required on all ! HTTP/1.0 request messages containing an entity body. *************** *** 1752,1755 **** Any Content-Length greater than or equal to zero is a valid value. ! Section 7.2.2 describes how to determine the length of an ! Entity-Body if a Content-Length is not given. --- 1869,1872 ---- Any Content-Length greater than or equal to zero is a valid value. ! Section 7.2.2 describes how to determine the length of a response ! entity body if a Content-Length is not given. *************** *** 1761,1766 **** ! 8.5 Content-Type ! The Content-Type header field indicates the media type of the ! Entity-Body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request --- 1878,1883 ---- ! 10.5 Content-Type ! The Content-Type entity-header field indicates the media type of ! the Entity-Body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request *************** *** 1774,1784 **** ! The Content-Type header field has no default value. Further ! discussion of methods for identifying the media type of an entity ! is provided in Section 7.2.1. ! 8.6 Date ! 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. --- 1891,1901 ---- ! Further discussion of methods for identifying the media type of an ! entity is provided in Section 7.2.1. ! 10.6 Date ! The Date general-header field 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. *************** *** 1792,1808 **** (in the case of requests) or the origin server (in the case of ! responses), then the default date can be assumed to be the current ! date at the receiving end. However, since the date--as it is ! believed by the origin--is important for evaluating cached ! responses, origin servers should always include a Date header. ! 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. ! Only one Date header field is allowed per message. In theory, the ! date should represent the moment just before the entity is ! generated. In practice, the date can be generated at any time ! during the message origination without affecting its semantic value. --- 1909,1924 ---- (in the case of requests) or the origin server (in the case of ! responses), then the date can be assumed to be the current date at ! the receiving end. However, since the date--as it is believed by the ! origin--is important for evaluating cached responses, origin servers ! should always include a Date header. 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 recipient if the message will be cached by that ! recipient or gatewayed via a protocol which requires a Date. ! In theory, the date should represent the moment just before the ! entity is generated. In practice, the date can be generated at any ! time during the message origination without affecting its semantic ! value. *************** *** 1813,1827 **** ! 8.7 Expires ! The Expires field gives the date/time after which the entity should ! be considered stale. This allows information providers to suggest ! the volatility of the resource. Caching clients, including proxies, ! must not cache this copy of the resource beyond the date given, ! unless its status has been updated by a later check of the origin ! server. The presence of an Expires field does not imply that the ! original resource will change or cease to exist at, before, or ! after that time. However, information providers that know or even ! suspect that a resource will change by a certain date are strongly ! encouraged to include an Expires header with that date. The format ! is an absolute date and time as defined by HTTP-date in Section 3.3. --- 1929,1943 ---- ! 10.7 Expires ! The Expires entity-header field gives the date/time after which the ! entity should be considered stale. This allows information ! providers to suggest the volatility of the resource, or a date ! after which the information may no longer be valid. Applications ! must not cache this entity beyond the date given. The presence of ! an Expires field does not imply that the original resource will ! change or cease to exist at, before, or after that time. However, ! information providers that know or even suspect that a resource ! will change by a certain date should include an Expires header with ! that date. The format is an absolute date and time as defined by ! HTTP-date in Section 3.3. *************** *** 1833,1840 **** ! The Expires field has no default value. If the date given is equal ! to or earlier than the value of the Date header, the recipient must ! not cache the enclosed entity. If a resource is dynamic by nature, ! as is the case with many data-producing processes, copies of that ! resource should be given an appropriate Expires value which ! reflects that dynamism. --- 1949,1955 ---- ! If the date given is equal to or earlier than the value of the Date ! header, the recipient must not cache the enclosed entity. If a ! resource is dynamic by nature, as is the case with many ! data-producing processes, entities from that resource should be ! given an appropriate Expires value which reflects that dynamism. *************** *** 1861,1868 **** ! 8.8 From ! The From header field, if given, should contain an Internet e-mail ! 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]): --- 1976,1983 ---- ! 10.8 From ! The From request-header field, if given, should contain an Internet ! e-mail 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]): *************** *** 1895,1901 **** ! 8.9 If-Modified-Since ! The If-Modified-Since header field is used with the GET method to ! make it conditional: if the requested resource has not been ! modified since the time specified in this field, a copy of the resource will not be returned from the server; instead, a 304 (not --- 2010,2016 ---- ! 10.9 If-Modified-Since ! The If-Modified-Since request-header field is used with the GET ! method to make it conditional: if the requested resource has not ! been modified since the time specified in this field, a copy of the resource will not be returned from the server; instead, a 304 (not *************** *** 1931,1940 **** ! 8.10 Last-Modified ! The Last-Modified header field indicates the date and time at which ! the sender believes the resource was last modified. The exact ! semantics of this field are defined in terms of how the receiver ! should interpret it: if the receiver has a copy of this resource ! which is older than the date given by the Last-Modified field, that ! copy should be considered stale. --- 2046,2055 ---- ! 10.10 Last-Modified ! The Last-Modified entity-header field indicates the date and time ! at which the sender believes the resource was last modified. The ! exact semantics of this field are defined in terms of how the ! recipient should interpret it: if the recipient has a copy of this ! resource which is older than the date given by the Last-Modified ! field, that copy should be considered stale. *************** *** 1961,1965 **** ! 8.11 Location ! The Location response header field defines the exact location of the resource that was identified by the Request-URI. For 3xx --- 2076,2080 ---- ! 10.11 Location ! The Location response-header field defines the exact location of the resource that was identified by the Request-URI. For 3xx *************** *** 1975,1990 **** ! 8.12 MIME-Version ! HTTP is not a MIME-conformant protocol (see Appendix C). However, ! HTTP/1.0 messages may include a single MIME-Version header field to ! indicate what version of the MIME protocol was used to construct ! the message. Use of the MIME-Version header field should indicate ! 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 ! receivers must not take it for granted that the message is indeed ! in full compliance with MIME. Gateways are responsible for ensuring ! this compliance (where possible) when exporting HTTP messages to ! strict MIME environments. Future HTTP/1.0 applications must only ! use MIME-Version when the message is intended to be MIME-conformant. --- 2090,2106 ---- ! 10.12 MIME-Version ! HTTP is not a MIME-compliant protocol (see Appendix C). However, ! HTTP/1.0 messages may include a single MIME-Version general-header ! field to indicate what version of the MIME protocol was used to ! construct the message. Use of the MIME-Version header field should ! indicate that the message is in full compliance with the MIME ! protocol (as defined in [5]). Unfortunately, some older versions of ! HTTP/1.0 clients and servers use this field indiscriminately, and ! thus recipients must not take it for granted that the message is ! indeed in full compliance with MIME. Proxies and gateways are ! responsible for ensuring this compliance (where possible) when ! exporting HTTP messages to strict MIME environments. Future ! HTTP/1.0 applications must only use MIME-Version when the message ! is fully MIME-compliant. *************** *** 1996,2008 **** ! 8.13 Pragma ! The Pragma message header field is used to include implementation-specific directives that may apply to any recipient ! along the request/response chain. The directives typically specify ! behavior intended to prevent intermediate proxies or caches from ! adversely interfering with the request or response. All pragma ! directives specify optional behavior from the viewpoint of the ! protocol; however, some systems may require that behavior be ! consistent with the directives. HTTP/1.0 only defines semantics for ! the "no-cache" directive on request messages. --- 2112,2120 ---- ! 10.13 Pragma ! The Pragma general-header field is used to include implementation-specific directives that may apply to any recipient ! along the request/response chain. All pragma directives specify ! optional behavior from the viewpoint of the protocol; however, some ! systems may require that behavior be consistent with the directives. *************** *** 2013,2031 **** ! 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. ! This allows a client to insist upon receiving an authoritative ! response to its request. It also allows a client to refresh a ! cached copy which is known to be corrupted or stale. ! Pragma directives must be passed through by a proxy, regardless of ! their significance to that proxy, since the directives may be ! applicable to all recipients along the request/response chain. It ! is not possible to specify a pragma for a specific recipient; ! however, any pragma directive not relevant to a recipient should be ! ignored by that recipient. ! 8.14 Referer ! The Referer request header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which --- 2125,2143 ---- ! When the "no-cache" directive is present in a request message, an ! application should forward the request toward the origin server ! even if it has a cached copy of what is being requested. This ! allows a client to insist upon receiving an authoritative response ! to its request. It also allows a client to refresh a cached copy ! which is known to be corrupted or stale. ! Pragma directives must be passed through by a proxy or gateway ! application, regardless of their significance to that application, ! since the directives may be applicable to all recipients along the ! request/response chain. It is not possible to specify a pragma for ! a specific recipient; however, any pragma directive not relevant to ! a recipient should be ignored by that recipient. ! 10.14 Referer ! The Referer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which *************** *** 2055,2059 **** ! 8.15 Server ! The Server response header field contains information about the software used by the origin server to handle the request. The field --- 2167,2171 ---- ! 10.15 Server ! The Server response-header field contains information about the software used by the origin server to handle the request. The field *************** *** 2071,2073 **** If the response is being forwarded through a proxy, the proxy ! application should not add its data to the product list. --- 2183,2185 ---- If the response is being forwarded through a proxy, the proxy ! application must not add its data to the product list. *************** *** 2079,2092 **** ! 8.16 User-Agent ! The User-Agent field contains information about the user agent ! originating the request. This is for statistical purposes, the ! tracing of protocol violations, and automated recognition of user ! agents for the sake of tailoring responses to avoid particular user ! agent limitations. Although it is not required, user agents should ! always include this field with requests. The field can contain ! multiple product tokens (Section 3.7) and comments 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. --- 2191,2205 ---- ! 10.16 User-Agent ! The User-Agent request-header field contains information about the ! user agent originating the request. This is for statistical ! purposes, the tracing of protocol violations, and automated ! recognition of user agents for the sake of tailoring responses to ! avoid particular user agent limitations. Although it is not ! required, user agents should include this field with requests. The ! field can contain multiple product tokens (Section 3.7) and ! comments 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. *************** *** 2098,2102 **** - The User-Agent field may include additional information within - comments. - Note: Some current proxy applications append their product --- 2211,2212 ---- *************** *** 2106,2110 **** ! 8.17 WWW-Authenticate ! The WWW-Authenticate header field must be included in 401 (unauthorized) response messages. The field value consists of at --- 2216,2220 ---- ! 10.17 WWW-Authenticate ! The WWW-Authenticate response-header field must be included in 401 (unauthorized) response messages. The field value consists of at *************** *** 2115,2117 **** ! The HTTP access authentication process is described in Section 9. User agents must take special care in parsing the WWW-Authenticate --- 2225,2227 ---- ! The HTTP access authentication process is described in Section 11. User agents must take special care in parsing the WWW-Authenticate *************** *** 2122,2124 **** ! 9. Access Authentication --- 2232,2234 ---- ! 11. Access Authentication *************** *** 2180,2185 **** challenge-response mechanism for access authentication. Additional ! mechanisms may be used at the transport level, via message ! encapsulation, and/or with additional header fields specifying ! authentication information. However, these additional mechanisms ! are not defined by this specification. --- 2290,2295 ---- challenge-response mechanism for access authentication. Additional ! mechanisms may be used, such as encryption at the transport level ! or via message encapsulation, and with additional header fields ! specifying authentication information. However, these additional ! mechanisms are not defined by this specification. *************** *** 2191,2193 **** ! 9.1 Basic Authentication Scheme --- 2301,2303 ---- ! 11.1 Basic Authentication Scheme *************** *** 2219,2221 **** ! userid-password = [ token ] ":" *text --- 2329,2331 ---- ! userid-password = [ token ] ":" *TEXT *************** *** 2231,2237 **** generally true on an open network, the basic authentication scheme ! should be used accordingly. In spite of this, clients are ! encouraged to implement the scheme in order to communicate with ! servers that use it. ! 10. Security Considerations --- 2341,2347 ---- generally true on an open network, the basic authentication scheme ! should be used accordingly. In spite of this, clients should ! implement the scheme in order to communicate with servers that use ! it. ! 12. Security Considerations *************** *** 2243,2248 **** ! 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 --- 2353,2358 ---- ! 12.1 Authentication of Clients ! As mentioned in Section 11.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 *************** *** 2252,2254 **** ! 10.2 Safe Methods --- 2362,2364 ---- ! 12.2 Safe Methods *************** *** 2273,2275 **** ! 10.3 Abuse of Server Log Information --- 2383,2385 ---- ! 12.3 Abuse of Server Log Information *************** *** 2284,2286 **** ! 10.4 Transfer of Sensitive Information --- 2394,2396 ---- ! 12.4 Transfer of Sensitive Information *************** *** 2290,2295 **** information within the context of any given request. Therefore, ! 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. --- 2400,2404 ---- information within the context of any given request. Therefore, ! applications should 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. *************** *** 2297,2300 **** server machine to become more vulnerable to attacks against ! software that is known to contain security holes. Implementors are ! encouraged to make the Server header field a configurable option. --- 2406,2409 ---- server machine to become more vulnerable to attacks against ! software that is known to contain security holes. Implementors ! should make the Server header field a configurable option. *************** *** 2318,2320 **** ! 11. Acknowledgments --- 2427,2429 ---- ! 13. Acknowledgments *************** *** 2327,2329 **** ! The HTTP protocol has evolved considerably over the past three years. It has benefited from a large and active developer --- 2436,2438 ---- ! The HTTP protocol has evolved considerably over the past four years. It has benefited from a large and active developer *************** *** 2333,2335 **** general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, ! Bob Denny, Jean Francois-Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, --- 2442,2444 ---- general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, ! Bob Denny, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, *************** *** 2363,2366 **** Francois Yergeau Mary Ellen Zurko ! 12. References --- 2472,2476 ---- Francois Yergeau Mary Ellen Zurko + Jean-Philippe Martin-Flatin ! 14. References *************** *** 2371,2376 **** ! [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." ! RFC 1630, CERN, June 1994. --- 2481,2486 ---- ! [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." RFC ! 1630, CERN, June 1994. *************** *** 2433,2435 **** 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. --- 2543,2545 ---- 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. *************** *** 2443,2445 **** ! 13. Authors' Addresses --- 2553,2555 ---- ! 15. Authors' Addresses *************** *** 2511,2514 **** ! Clients should be tolerant in parsing the StatusLine and servers ! tolerant when parsing the RequestLine. In particular, they should accept any amount of SP or HT characters between fields, even --- 2621,2624 ---- ! Clients should be tolerant in parsing the Status-Line and servers ! tolerant when parsing the Request-Line. In particular, they should accept any amount of SP or HT characters between fields, even *************** *** 2518,2520 **** However, we recommend that applications, when parsing such headers, ! recognize a single LF as a line terminator and ignore the leading CR. --- 2628,2631 ---- However, we recommend that applications, when parsing such headers, ! recognize a single LF as a line terminator and ignore the leading ! CR. *************** *** 2526,2530 **** of representations and with extensible mechanisms. However, HTTP is ! not a MIME-conforming application. HTTP's performance requirements differ substantially from those of Internet mail. Since it is not ! limited by the restrictions of existing mail protocols and gateways, HTTP does not obey some of the constraints imposed by --- 2637,2641 ---- of representations and with extensible mechanisms. However, HTTP is ! not a MIME-compliant application. HTTP's performance requirements differ substantially from those of Internet mail. Since it is not ! limited by the restrictions of existing mail protocols and SMTP gateways, HTTP does not obey some of the constraints imposed by *************** *** 2533,2536 **** This appendix describes specific areas where HTTP differs from ! MIME. Gateways to MIME-compliant protocols must be aware of these ! differences and provide the appropriate conversions where necessary. --- 2644,2648 ---- This appendix describes specific areas where HTTP differs from ! MIME. Proxies/gateways to MIME-compliant protocols must be aware of ! these differences and provide the appropriate conversions where ! necessary. *************** *** 2554,2564 **** ! Where it is possible, a gateway from HTTP to a MIME-conformant ! protocol should translate all line breaks within text/* media types ! to the MIME canonical form of CRLF. However, this may be ! complicated by the presence of a Content-Encoding and by the fact ! that HTTP allows the use of some character sets which do not use ! octets 13 and 10 to represent CR and LF, as is the case for some ! multi-byte character sets. If canonicalization is performed, the ! Content-Length header field value must be updated to reflect the ! new body length. --- 2666,2676 ---- ! Where it is possible, a proxy or gateway from HTTP to a ! MIME-compliant protocol should translate all line breaks within ! text/* media types to the MIME canonical form of CRLF. However, ! this may be complicated by the presence of a Content-Encoding and ! by the fact that HTTP allows the use of some character sets which ! do not use octets 13 and 10 to represent CR and LF, as is the case ! for some multi-byte character sets. If canonicalization is ! performed, the Content-Length header field value must be updated to ! reflect the new body length. *************** *** 2575,2578 **** ! should be added by the gateway if the entity contains any octets ! greater than 127. --- 2687,2690 ---- ! should be added by the proxy/gateway if the entity contains any ! octets greater than 127. *************** *** 2581,2585 **** 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. --- 2693,2698 ---- HTTP/1.0 uses a restricted subset of date formats to simplify the ! process of date comparison. Proxies/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. *************** *** 2589,2593 **** 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 ! Entity-Body before forwarding the message. --- 2702,2706 ---- Content-Encoding header field. Since this acts as a modifier on the ! media type, proxies/gateways to MIME-compliant protocols must ! either change the value of the Content-Type header field or decode ! the Entity-Body before forwarding the message. *************** *** 2602,2610 **** 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 --- 2715,2724 ---- HTTP does not use the Content-Transfer-Encoding (CTE) field of ! MIME. Proxies/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. ! Proxies/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 *************** *** 2612,2614 **** ! should be added by the gateway if it is unwilling to apply a content transfer encoding. --- 2726,2728 ---- ! should be added by the proxy/gateway if it is unwilling to apply a content transfer encoding. *************** *** 2617,2620 **** extension Entity-Header in a POST request when it knows the ! destination of that request is a gateway to a MIME-compliant protocol. - --- 2731,2733 ---- extension Entity-Header in a POST request when it knows the ! destination of that request is a proxy/gateway to a MIME-compliant protocol.