*** ../draft02/draft-ietf-http-v10-spec-02.txt Mon Aug 14 11:20:44 1995 --- draft-ietf-http-v10-spec-03.txt Mon Sep 4 21:09:12 1995 *************** *** 1,7 **** ! HTTP Working Group T. Berners-Lee, MIT/W3C INTERNET-DRAFT R. Fielding, UC Irvine ! H. Frystyk, MIT/W3C ! Expires February 13, 1996 August 13, 1995 Hypertext Transfer Protocol -- HTTP/1.0 --- 1,7 ---- ! HTTP Working Group T. Berners-Lee, MIT/LCS INTERNET-DRAFT R. Fielding, UC Irvine ! H. Frystyk, MIT/LCS ! Expires March 4, 1996 September 4, 1995 Hypertext Transfer Protocol -- HTTP/1.0 *************** *** 66,73 **** 3.2.1 General Syntax 3.2.2 http URL 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 --- 66,73 ---- 3.2.1 General Syntax 3.2.2 http URL 3.3 Date/Time Formats ! 3.4 Character Sets ! 3.5 Content Codings 3.6 Media Types 3.6.1 Canonicalization and Text Defaults 3.6.2 Multipart Types *************** *** 127,133 **** 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 --- 127,133 ---- 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 *************** *** 144,150 **** Appendix C. Relationship to MIME C.1 Conversion to Canonical Form 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 --- 144,150 ---- Appendix C. Relationship to MIME C.1 Conversion to Canonical Form C.1.1 Representation of Line Breaks ! C.1.2 Default Character Set C.2 Conversion of Date Formats C.3 Introduction of Content-Encoding C.4 No Content-Transfer-Encoding *************** *** 455,469 **** 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 coded character sets ! other than US-ASCII. text = Recipients of header field text containing octets outside the ! US-ASCII coded character set may assume that they represent ! ISO-8859-1 characters. 3. Protocol Parameters --- 455,469 ---- 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 *************** *** 624,638 **** 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. Note: Recipients of date values are encouraged to be robust ! in accepting date values that may have been generated by non- ! HTTP applications, as is sometimes the case when retrieving ! or posting messages via gateways to SMTP or NNTP. All HTTP/1.0 date/time stamps must be represented in Universal Time (UT), also known as Greenwich Mean Time (GMT), without exception. --- 624,638 ---- 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. Note: Recipients of date values are encouraged to be robust ! in accepting date values that may have been generated by ! non-HTTP applications, as is sometimes the case when ! retrieving or posting messages via gateways to SMTP or NNTP. All HTTP/1.0 date/time stamps must be represented in Universal Time (UT), also known as Greenwich Mean Time (GMT), without exception. *************** *** 671,677 **** Clients and servers are not required to use these formats for user presentation, request logging, etc. ! 3.4 Coded Character Sets HTTP uses the same definition of the term "character set" as that described for MIME: --- 671,677 ---- Clients and servers are not required to use these formats for user presentation, request logging, etc. ! 3.4 Character Sets HTTP uses the same definition of the term "character set" as that described for MIME: *************** *** 693,709 **** 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" --- 693,707 ---- use of external profiling information to determine the exact mapping is not permitted. ! HTTP 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 character set, we define here the ! preferred names for those character sets most likely to be used ! with HTTP entities. These character sets include those registered ! by RFC 1521 [5] -- the US-ASCII [17] and ISO-8859 [18] 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" *************** *** 715,747 **** 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 --- 713,750 ---- 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 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. ! Note: This use of the term "character set" is more commonly ! referred to as a "character encoding." However, since HTTP ! and MIME share the same registry, it is important that the ! terminology also be shared. ! 3.5 Content Codings ! ! 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. ! content-coding = "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 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 ! 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 content-coding formats. Two values are ! defined by this specification: x-gzip An encoding format produced by the file compression program *************** *** 784,794 **** attribute = token value = token | quoted-string ! 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 ! and its value. Many current applications do not recognize media type parameters. Since parameters are a fundamental aspect of media types, this must --- 787,797 ---- attribute = token value = token | quoted-string ! 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 and its value. Many current applications do not recognize media type parameters. Since parameters are a fundamental aspect of media types, this must *************** *** 824,843 **** octet sequences to indicate a text line break. In addition to the preferred form of CRLF, HTTP applications must accept a bare CR or 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. Note: This interpretation of line breaks applies only to the ! 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. A recipient of an HTTP text entity should translate the received entity line breaks to the local line break conventions before --- 827,846 ---- octet sequences to indicate a text line break. In addition to the preferred form of CRLF, HTTP applications must accept a bare CR or LF alone as representing a single line break in text media. ! Furthermore, if the text media is represented in a character set ! which does not use octets 13 and 10 for CR and LF respectively, as ! is the case for some multi-byte character sets, HTTP allows the use ! of whatever octet sequence(s) is defined by that character set to ! represent the equivalent of CRLF, bare CR, and bare LF. It is ! assumed that any recipient capable of using such a character set ! will know the appropriate octet sequence for representing line ! breaks within that character set. Note: This interpretation of line breaks applies only to the ! 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. Content ! codings define their own line break requirements. A recipient of an HTTP text entity should translate the received entity line breaks to the local line break conventions before *************** *** 846,862 **** the entity, or only when prompted by the user, is entirely up to the individual application. ! 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 ! octets within the US-ASCII set (0 - 127). The presence of a charset ! parameter value in a Content-Type header field overrides the ! default. ! 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. --- 849,864 ---- the entity, or only when prompted by the user, is entirely up to the individual application. ! HTTP also redefines the default 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] character set ! is a superset of US-ASCII [17], this has no effect upon the ! interpretation of entity bodies which only contain octets within ! the US-ASCII set (0 - 127). The presence of a charset parameter ! value in a Content-Type header field overrides the default. ! It is recommended that the 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. *************** *** 867,875 **** 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 ! each type in order to correctly interpret the purpose of each body- ! part. Ideally, an HTTP user agent should follow the same or similar ! behavior as a MIME user agent does upon receipt of a multipart type. 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 --- 869,878 ---- 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 ! each type in order to correctly interpret the purpose of each ! body-part. Ideally, an HTTP user agent should follow the same or ! similar behavior as a MIME user agent does upon receipt of a ! multipart type. 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 *************** *** 919,926 **** 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). Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 --- 922,929 ---- 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). Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 *************** *** 953,962 **** 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. HTTP-header = field-name ":" [ field-value ] CRLF --- 956,965 ---- 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. HTTP-header = field-name ":" [ field-value ] CRLF *************** *** 1041,1047 **** Method = "GET" | "HEAD" | "POST" | extension-method ! 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 --- 1044,1050 ---- Method = "GET" | "HEAD" | "POST" | extension-method ! 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 *************** *** 1129,1134 **** --- 1132,1139 ---- 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. + Caching intermediaries must not cache responses to a POST request. + 5.3 Request-URI The Request-URI is a Uniform Resource Identifier (Section 3.2) and *************** *** 1141,1148 **** 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 idempotent and a ! 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 --- 1146,1153 ---- 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 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 *************** *** 1376,1385 **** taken by the user agent in order to fulfill the request. The action required can sometimes be carried out by the user agent without interaction with the user, but it is strongly recommended that this ! only take place if the method used in the request is idempotent ! (GET or HEAD). A user agent should never automatically redirect a ! request more than 5 times, since such redirections usually indicate ! an infinite loop. 300 Multiple Choices --- 1381,1389 ---- taken by the user agent in order to fulfill the request. The action required can sometimes be carried out by the user agent without interaction with the user, but it is strongly recommended that this ! only take place if the method used in the request is GET or HEAD. A ! user agent should never automatically redirect a request more than ! 5 times, since such redirections usually indicate an infinite loop. 300 Multiple Choices *************** *** 1404,1411 **** 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. If the 301 status code is received in response to a request using the POST method, the user agent must not automatically redirect the --- 1408,1415 ---- reference returned by the server, where possible. The new URL must be given by the Location field in the response. ! Unless it was a HEAD request, the Entity-Body of the response ! should contain a short note with a hyperlink to the new URL. If the 301 status code is received in response to a request using the POST method, the user agent must not automatically redirect the *************** *** 1418,1426 **** Since the redirection may be altered on occasion, the client should continue to use the Request-URI for future requests. ! 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). If the 302 status code is received in response to a request using the POST method, the user agent must not automatically redirect the --- 1422,1430 ---- Since the redirection may be altered on occasion, the client should continue to use the Request-URI for future requests. ! The URL must be given by the Location field in the response. Unless ! it was a HEAD request, the Entity-Body of the response should ! contain a short note with a hyperlink to the new URI(s). If the 302 status code is received in response to a request using the POST method, the user agent must not automatically redirect the *************** *** 1470,1477 **** 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. HTTP ! access authentication is explained in Section 9. 403 Forbidden --- 1474,1488 ---- 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. 403 Forbidden *************** *** 1537,1543 **** information about an Entity-Body returned in the response, but about the server itself. ! Response-Header= Location ; Section 8.11 | Server ; Section 8.15 | WWW-Authenticate ; Section 8.17 --- 1548,1554 ---- information about an Entity-Body returned in the response, but about the server itself. ! Response-Header = Location ; Section 8.11 | Server ; Section 8.15 | WWW-Authenticate ; Section 8.17 *************** *** 1567,1573 **** | Last-Modified ; Section 8.10 | extension-header ! extension-header = HTTP-header The extension-header mechanism allows additional Entity-Header to be defined without changing the protocol, but these fields cannot --- 1578,1584 ---- | Last-Modified ; Section 8.10 | extension-header ! extension-header=HTTP-header The extension-header mechanism allows additional Entity-Header to be defined without changing the protocol, but these fields cannot *************** *** 1605,1612 **** 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). --- 1616,1623 ---- 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 content ! coding 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). *************** *** 1681,1692 **** 8.2 Authorization ! 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 --- 1692,1703 ---- 8.2 Authorization ! 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 *************** *** 1701,1716 **** The Content-Encoding header field is used as a modifier to the 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 Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type. ! Content-Encoding = "Content-Encoding" ":" encoding-mechanism ! Encoding mechanisms are defined in Section 3.5. An example of its ! use is Content-Encoding: x-gzip --- 1712,1726 ---- 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 decoding mechanism must be applied in order to obtain the media-type referenced by the Content-Type header field. The Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type. ! Content-Encoding = "Content-Encoding" ":" content-coding ! Content codings are defined in Section 3.5. An example of its use is Content-Encoding: x-gzip *************** *** 1832,1840 **** User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity ! retrieved earlier in a session. The Expires field does not apply to ! history mechanisms. If the entity is still in storage, a history ! mechanism should display it even if the entity has expired. Note: Applications are encouraged to be tolerant of bad or misinformed implementations of the Expires header. A value --- 1842,1852 ---- User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity ! retrieved earlier in a session. By default, the Expires field does ! not apply to history mechanisms. If the entity is still in storage, ! a history mechanism should display it even if the entity has ! expired, unless the user has specifically configured the agent to ! refresh expired history documents. Note: Applications are encouraged to be tolerant of bad or misinformed implementations of the Expires header. A value *************** *** 1882,1889 **** 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 modified) response will be returned without any Entity-Body. If-Modified-Since = "If-Modified-Since" ":" HTTP-date --- 1894,1901 ---- 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 ! modified) response will be returned without any Entity-Body. If-Modified-Since = "If-Modified-Since" ":" HTTP-date *************** *** 1899,1913 **** 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 ! normal GET. ! b) If the resource has been modified since the If-Modified- ! Since date, the response is exactly the same as for a ! normal GET. ! c) If the resource has not been modified since the ! If-Modified-Since date, the server shall return a 304 ! (not modified) response. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. --- 1911,1926 ---- 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 ! normal GET. A date which is later than the server's current ! time is invalid. ! b) If the resource has been modified since the ! If-Modified-Since date, the response is exactly the same as ! for a normal GET. ! c) If the resource has not been modified since a valid ! If-Modified-Since date, the server shall return a 304 (not ! modified) response. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. *************** *** 1936,1941 **** --- 1949,1960 ---- of the record. For virtual objects, it may be the last time the internal state changed. + An origin server must not send a Last-Modified date which is later + than the server's time of message origination. In such cases, where + the resource's last modification would indicate some time in the + future, the server must replace that date with the message + origination date. + 8.11 Location The Location response header field defines the exact location of *************** *** 1973,1995 **** 8.13 Pragma ! The Pragma message header field is used to specify directives that ! should be applied to all intermediaries 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 defines semantics for the "no-cache" directive. ! Pragma = "Pragma" ":" #pragma-directive ! pragma-directive = "no-cache" ! | extension-pragma extension-pragma = token [ "=" word ] 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. This allows a client to insist upon receiving an authoritative response to its request. It also allows a client to refresh a --- 1992,2014 ---- 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. ! Pragma = "Pragma" ":" 1#pragma-directive ! pragma-directive = "no-cache" | extension-pragma extension-pragma = token [ "=" word ] 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 *************** *** 1997,2014 **** Pragma directives must be passed through by a proxy, regardless of their significance to that proxy, since the directives may be ! applicable to all intermediaries along the request/response chain. ! It is not possible to specify a pragma for a specific proxy; ! however, any pragma directive not relevant to a proxy should be ! ignored. - 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 --- 2016,2026 ---- 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 *************** *** 2069,2078 **** 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) 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. User-Agent = "User-Agent" ":" 1*( product | comment ) --- 2081,2090 ---- 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. User-Agent = "User-Agent" ":" 1*( product | comment ) *************** *** 2138,2149 **** generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. ! 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 ) --- 2150,2161 ---- generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. ! 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 ) *************** *** 2234,2240 **** additional authentication schemes and encryption mechanisms from being employed to increase security. ! 10.2 Idempotent Methods The writers of client software should be aware that the software represents the user in their interactions over the Internet, and --- 2246,2252 ---- additional authentication schemes and encryption mechanisms from being employed to increase security. ! 10.2 Safe Methods The writers of client software should be aware that the software represents the user in their interactions over the Internet, and *************** *** 2244,2254 **** In particular, the convention has been established that the GET and HEAD methods should never have the significance of taking an action ! other than retrieval. These methods should be considered "safe" and ! 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. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in --- 2256,2265 ---- In particular, the convention has been established that the GET and HEAD methods should never have the significance of taking an action ! other than retrieval. These methods should be considered "safe." ! This allows user agents to represent other methods, such as POST, ! in a special way, so that the user is made aware of the fact that a ! possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in *************** *** 2311,2326 **** between HTTP/1.0 and Internet mail message formats. The HTTP protocol has evolved considerably over the past three ! years. It has benefited from a large and active developer community-- ! the many people who have participated on the www-talk mailing list-- ! and it is that community which has been most responsible for the ! success of HTTP and of the World-Wide Web in general. ! 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 ! Marc VanHeyningen deserve special recognition for their efforts in ! defining aspects of the protocol for early versions of this ! specification. This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already --- 2322,2337 ---- between HTTP/1.0 and Internet mail message formats. The HTTP protocol has evolved considerably over the past three ! years. It has benefited from a large and active developer ! community--the many people who have participated on the www-talk ! mailing list--and it is that community which has been most ! responsible for the success of HTTP and of the World-Wide Web in ! 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, ! Tony Sanders, and Marc VanHeyningen deserve special recognition for ! their efforts in defining aspects of the protocol for early versions ! of this specification. This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already *************** *** 2336,2351 **** 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 --- 2347,2362 ---- Koen Holtman Alex Hopmann Bob Jernigan Shel Kaphan Martijn Koster Dave Kristol ! Daniel LaLiberte Paul Leach ! 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 *************** *** 2365,2371 **** [4] T. Berners-Lee, L. Masinter, and M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, University of ! Minnesota, October 1994. [5] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing --- 2376,2382 ---- [4] T. Berners-Lee, L. Masinter, and M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, University of ! Minnesota, December 1994. [5] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing *************** *** 2533,2540 **** 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 MIME-canonical line breaks in text. Where it is possible, a gateway from HTTP to a MIME-conformant --- 2544,2551 ---- 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) to indicate a line break within text content, ! recipients of an HTTP message cannot rely upon receiving MIME-canonical line breaks in text. Where it is possible, a gateway from HTTP to a MIME-conformant *************** *** 2541,2560 **** 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 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 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 ;charset="iso-8859-1" --- 2552,2571 ---- 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. ! C.1.2 Default Character Set MIME requires that all subtypes of the top-level Content-Type ! "text" have a default character set of US-ASCII [17]. In contrast, ! HTTP defines the default 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 ;charset="iso-8859-1" *************** *** 2578,2603 **** Note: Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ! ";conversions=" to perform an ! equivalent function as Content-Encoding. However, this ! parameter is not part of the MIME specification at the time ! 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 --- 2589,2613 ---- Note: Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ! ";conversions=" to perform an equivalent ! function as Content-Encoding. However, this parameter is not ! part of the MIME specification at the time 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 ! content transfer encoding. An HTTP client may include a Content-Transfer-Encoding as an extension Entity-Header in a POST request when it knows the