Changeset 1740 for draft-ietf-httpbis/latest
- Timestamp:
- 08/07/12 18:15:03 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1737 r1740 961 961 <p id="rfc.section.2.5.p.4">Unless noted otherwise, recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 962 962 except when they have a direct impact on security, since different applications of the protocol require different error handling 963 strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field964 doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recoveryto be dangerous.963 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 964 to be dangerous. 965 965 </p> 966 966 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="http.version" href="#http.version">Protocol Versioning</a></h2> … … 1001 1001 </p> 1002 1002 <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after 1003 the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server) 1004 that the server improperly handles higher request versions. 1003 the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions. 1005 1004 </p> 1006 1005 <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than … … 1011 1010 specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version 1012 1011 number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the 1013 given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., 1014 User-Agent) uniquely match the values sent by a client known to be in error. 1012 given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error. 1015 1013 </p> 1016 1014 <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax … … 1209 1207 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1210 1208 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1211 the Dateheader field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1209 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1212 1210 </p> 1213 1211 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1220 1218 </p> 1221 1219 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1222 to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations 1223 can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include 1220 to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include 1224 1221 conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. 1225 1222 </p> … … 1402 1399 <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1403 1400 </p> 1404 <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding(<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1401 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1405 1402 </p> 1406 1403 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer … … 1950 1947 </li> 1951 1948 </ul> 1952 <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field -value identical to that of the Dateheader field in that response.1949 <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in that response. 1953 1950 </p> 1954 1951 <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: 1955 1952 </p> 1956 1953 <ul> 1957 <li>Content-Encoding</li> 1958 <li>Content-Range</li> 1959 <li>Content-Type</li> 1954 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1955 </li> 1956 <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) 1957 </li> 1958 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) 1959 </li> 1960 1960 </ul> 1961 1961 <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). … … 1966 1966 </p> 1967 1967 </div> 1968 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>).1968 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1969 1969 </p> 1970 1970 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 1971 1971 <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1972 1972 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1973 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.1973 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request. 1974 1974 </p> 1975 1975 <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. … … 2042 2042 <p id="rfc.section.6.2.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 2043 2043 </p> 2044 <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header 2045 fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 2044 <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 2046 2045 </p> 2047 2046 <p id="rfc.section.6.2.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses … … 2119 2118 <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2120 2119 </p> 2121 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2120 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2122 2121 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2123 2122 </p> … … 2149 2148 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2150 2149 <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2151 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding2150 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2152 2151 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2153 2152 </p> … … 2162 2161 </p> 2163 2162 <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2164 <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2. 19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2163 <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2165 2164 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2166 2165 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2169 2168 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2170 2169 <ul> 2171 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.2172 </li> 2173 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)with the "100-continue" expectation if it does not intend to send a request body.2170 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation. 2171 </li> 2172 <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body. 2174 2173 </li> 2175 2174 </ul> … … 2180 2179 <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p> 2181 2180 <ul> 2182 <li>Upon receiving a request which includes an Expectheader field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.2183 </li> 2184 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an Expectheader field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility2181 <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code. 2182 </li> 2183 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility 2185 2184 with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue" 2186 2185 expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared … … 2192 2191 prematurely. 2193 2192 </li> 2194 <li>If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the 2195 request includes a request body, and the server responds with a final status code before reading the entire request body from 2196 the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, 2193 <li>If an origin server receives a request that does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final 2194 status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, 2197 2195 the client might not reliably receive the response message. However, this requirement ought not be construed as preventing 2198 2196 a server from defending itself against denial-of-service attacks, or from badly broken client implementations. … … 2201 2199 <p id="rfc.section.6.4.3.p.5">Requirements for HTTP/1.1 proxies: </p> 2202 2200 <ul> 2203 <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either 2204 knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server, 2205 it <em class="bcp14">MUST</em> forward the request, including the Expect header field. 2201 <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 2202 or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field. 2206 2203 </li> 2207 2204 <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code. … … 2209 2206 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers. 2210 2207 </li> 2211 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect header field 2212 with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2208 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2213 2209 </li> 2214 2210 </ul> … … 2247 2243 </p> 2248 2244 <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2249 is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.2 3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2245 is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2250 2246 </p> 2251 2247 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching … … 2511 2507 <li>Pointer to specification text</li> 2512 2508 </ul> 2513 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.2 4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2509 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2514 2510 </p> 2515 2511 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 2671 2667 that most implementations will choose substantially higher limits. 2672 2668 </p> 2673 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.2 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).2669 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). 2674 2670 </p> 2675 2671 <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. … … 2716 2712 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 2717 2713 </h2> 2718 <table> 2714 <table> 2719 2715 <tr> 2720 2716 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> … … 2729 2725 <td class="reference"><b id="Part4">[Part4]</b></td> 2730 2726 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), July 2012. 2727 </td> 2728 </tr> 2729 <tr> 2730 <td class="reference"><b id="Part5">[Part5]</b></td> 2731 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), July 2012. 2731 2732 </td> 2732 2733 </tr> … … 3733 3734 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3734 3735 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3735 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5. 7</a>, <a href="#rfc.xref.Part2.17">6.3.2.2</a>, <a href="#rfc.xref.Part2.18">6.3.4</a>, <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3736 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.4.3</a>, <a href="#rfc.xref.Part2.24">6.5</a>, <a href="#rfc.xref.Part2.25">7.4</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3736 3737 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1</a></li> 3737 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.1 7">6.3.2.2</a>, <a href="#rfc.xref.Part2.18">6.3.4</a></li>3738 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a></li> 3738 3739 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3739 3740 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3740 3741 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3741 3742 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.3</a></li> 3742 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.1 6">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li>3743 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2. 19">6.4.3</a></li>3743 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.23">6.4.3</a></li> 3744 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.21">6.4.3</a></li> 3744 3745 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.2">2.3</a></li> 3745 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.2 3">6.5</a></li>3746 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.2 6">8.6</a></li>3747 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.2 5">8.6</a></li>3748 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.2 4">7.4</a></li>3746 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.24">6.5</a></li> 3747 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.27">8.6</a></li> 3748 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.26">8.6</a></li> 3749 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.25">7.4</a></li> 3749 3750 <li><em>Section 8</em> <a href="#rfc.xref.Part2.11">4.3.1</a></li> 3751 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.15">5.6.2</a></li> 3752 <li><em>Section 9.9</em> <a href="#rfc.xref.Part2.16">5.6.2</a></li> 3750 3753 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3751 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.2 0">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>3754 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.22">6.4.3</a></li> 3752 3755 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.1">1</a></li> 3753 3756 </ul> … … 3755 3758 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul> 3756 3759 <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li> 3760 </ul> 3761 </li> 3762 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">5.6.2</a>, <a href="#Part5"><b>10.1</b></a><ul> 3763 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.1">5.6.2</a></li> 3757 3764 </ul> 3758 3765 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1737 r1740 27 27 <!ENTITY representation "<xref target='Part2' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 28 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 <!ENTITY header-content-encoding "<xref target='Part2' x:rel='#header.content-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 <!ENTITY header-content-range "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 <!ENTITY header-content-type "<xref target='Part2' x:rel='#header.content-type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 32 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 33 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 609 612 on security, since different applications of the protocol require 610 613 different error handling strategies. For example, a Web browser might 611 wish to transparently recover from a response where the Location header612 field doesn't parse according to the ABNF, whereas a systems control614 wish to transparently recover from a response where the <x:ref>Location</x:ref> 615 header field doesn't parse according to the ABNF, whereas a systems control 613 616 client might consider any form of error recovery to be dangerous. 614 617 </t> … … 699 702 the server incorrectly implements the HTTP specification, but only 700 703 after the client has attempted at least one normal request and determined 701 from the response status or header fields (e.g., Server) that the702 server improperly handles higher request versions.704 from the response status or header fields (e.g., <x:ref>Server</x:ref>) that 705 the server improperly handles higher request versions. 703 706 </t> 704 707 <t> … … 720 723 version of the protocol. Such protocol downgrades &SHOULD-NOT; be 721 724 performed unless triggered by specific client attributes, such as when 722 one or more of the request header fields (e.g., User-Agent) uniquely723 match the values sent by a client known to be in error.725 one or more of the request header fields (e.g., <x:ref>User-Agent</x:ref>) 726 uniquely match the values sent by a client known to be in error. 724 727 </t> 725 728 <t> … … 1141 1144 <t> 1142 1145 The field-name token labels the corresponding field-value as having the 1143 semantics defined by that header field. For example, the Date header field1144 is defined in &header-date; as containing the origination1146 semantics defined by that header field. For example, the <x:ref>Date</x:ref> 1147 header field is defined in &header-date; as containing the origination 1145 1148 timestamp for the message in which it appears. 1146 1149 </t> … … 1167 1170 The order in which header fields with differing field names are 1168 1171 received is not significant. However, it is "good practice" to send 1169 header fields that contain control data first, such as Host on1170 requests and Date on responses, so that implementations can decide1171 when not to handle a message as early as possible. A server &MUST;1172 wait until the entire header section is received before interpreting1172 header fields that contain control data first, such as <x:ref>Host</x:ref> 1173 on requests and <x:ref>Date</x:ref> on responses, so that implementations 1174 can decide when not to handle a message as early as possible. A server 1175 &MUST; wait until the entire header section is received before interpreting 1173 1176 a request message, since later header fields might include conditionals, 1174 1177 authentication credentials, or deliberately misleading duplicate … … 1545 1548 </t> 1546 1549 <t> 1547 Unlike Content-Encoding (&content-codings;), Transfer-Encoding is a1548 property of the message, not of the payload, and thus &MAY; be added or1549 removed by any implementation along the request/response chain.1550 Additional information about the encoding parameters &MAY; be provided1551 by other header fields not defined by this specification.1550 Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;), 1551 Transfer-Encoding is a property of the message, not of the payload, and thus 1552 &MAY; be added or removed by any implementation along the request/response 1553 chain. Additional information about the encoding parameters &MAY; be 1554 provided by other header fields not defined by this specification. 1552 1555 </t> 1553 1556 <t> … … 2621 2624 but it &MAY; add any of these fields if not already present. If an 2622 2625 <x:ref>Expires</x:ref> header field is added, it &MUST; be given a 2623 field-value identical to that of the Date header field in that response. 2626 field value identical to that of the <x:ref>Date</x:ref> header field in 2627 that response. 2624 2628 </t> 2625 2629 <t> … … 2628 2632 any request: 2629 2633 <list style="symbols"> 2630 <t> Content-Encoding</t>2631 <t> Content-Range</t>2632 <t> Content-Type</t>2634 <t><x:ref>Content-Encoding</x:ref> (&header-content-encoding;)</t> 2635 <t><x:ref>Content-Range</x:ref> (&header-content-range;)</t> 2636 <t><x:ref>Content-Type</x:ref> (&header-content-type;)</t> 2633 2637 </list> 2634 2638 </t> … … 2816 2820 <t> 2817 2821 Comments &MAY; be used in the Via header field to identify the software 2818 of each recipient, analogous to the User-Agent and Server header fields. 2819 However, all comments in the Via field are optional and &MAY; be removed 2820 by any recipient prior to forwarding the message. 2822 of each recipient, analogous to the <x:ref>User-Agent</x:ref> and 2823 <x:ref>Server</x:ref> header fields. However, all comments in the Via field 2824 are optional and &MAY; be removed by any recipient prior to forwarding the 2825 message. 2821 2826 </t> 2822 2827 <t> … … 3107 3112 <t> 3108 3113 If a client will wait for a <x:ref>100 (Continue)</x:ref> response before 3109 sending the request body, it &MUST; send an Expectheader3114 sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header 3110 3115 field (&header-expect;) with the "100-continue" expectation. 3111 3116 </t> 3112 3117 <t> 3113 A client &MUST-NOT; send an Expect header field (&header-expect;)3114 with the "100-continue" expectation if it does not intend3115 to send a requestbody.3118 A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with 3119 the "100-continue" expectation if it does not intend to send a request 3120 body. 3116 3121 </t> 3117 3122 </list> … … 3129 3134 Requirements for HTTP/1.1 origin servers: 3130 3135 <list style="symbols"> 3131 <t> Upon receiving a request which includes an Expectheader3136 <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header 3132 3137 field with the "100-continue" expectation, an origin server &MUST; 3133 3138 either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read … … 3140 3145 </t> 3141 3146 <t> An origin server &SHOULD-NOT; send a <x:ref>100 (Continue)</x:ref> response if 3142 the request message does not include an Expectheader3147 the request message does not include an <x:ref>Expect</x:ref> header 3143 3148 field with the "100-continue" expectation, and &MUST-NOT; send a 3144 3149 <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0 … … 3163 3168 </t> 3164 3169 <t> If an origin server receives a request that does not include an 3165 Expectheader field with the "100-continue" expectation,3170 <x:ref>Expect</x:ref> header field with the "100-continue" expectation, 3166 3171 the request includes a request body, and the server responds 3167 3172 with a final status code before reading the entire request body … … 3179 3184 Requirements for HTTP/1.1 proxies: 3180 3185 <list style="symbols"> 3181 <t> If a proxy receives a request that includes an Expect header3182 field with the "100-continue" expectation, and the proxy3186 <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref> 3187 header field with the "100-continue" expectation, and the proxy 3183 3188 either knows that the next-hop server complies with HTTP/1.1 or 3184 3189 higher, or does not know the HTTP version of the next-hop … … 3195 3200 <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the 3196 3201 request message was received from an HTTP/1.0 (or earlier) 3197 client and did not include an Expectheader field with3202 client and did not include an <x:ref>Expect</x:ref> header field with 3198 3203 the "100-continue" expectation. This requirement overrides the 3199 3204 general rule for forwarding of <x:ref>1xx</x:ref> responses (see &status-1xx;). … … 4134 4139 <x:defines>502 (Bad Gateway)</x:defines> 4135 4140 <x:defines>505 (HTTP Version Not Supported)</x:defines> 4141 <x:defines>Content-Encoding</x:defines> 4142 <x:defines>Content-Type</x:defines> 4143 <x:defines>Date</x:defines> 4144 <x:defines>Expect</x:defines> 4145 <x:defines>Location</x:defines> 4146 <x:defines>Server</x:defines> 4147 <x:defines>User-Agent</x:defines> 4136 4148 </x:source> 4137 4149 </reference> … … 4157 4169 <x:source basename="p4-conditional" href="p4-conditional.xml"> 4158 4170 <x:defines>304 (Not Modified)</x:defines> 4171 </x:source> 4172 </reference> 4173 4174 <reference anchor="Part5"> 4175 <front> 4176 <title>HTTP/1.1, part 5: Range Requests and Partial Responses</title> 4177 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4178 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> 4179 <address><email>fielding@gbiv.com</email></address> 4180 </author> 4181 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> 4182 <organization abbrev="W3C">World Wide Web Consortium</organization> 4183 <address><email>ylafon@w3.org</email></address> 4184 </author> 4185 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> 4186 <organization abbrev="greenbytes">greenbytes GmbH</organization> 4187 <address><email>julian.reschke@greenbytes.de</email></address> 4188 </author> 4189 <date month="&ID-MONTH;" year="&ID-YEAR;"/> 4190 </front> 4191 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/> 4192 <x:source href="p5-range.xml" basename="p5-range"> 4193 <x:defines>Content-Range</x:defines> 4159 4194 </x:source> 4160 4195 </reference> -
draft-ietf-httpbis/latest/p2-semantics.html
r1739 r1740 859 859 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 860 860 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 861 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type862 of error recoverycould lead to dangerous consequences.861 the <a href="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 862 could lead to dangerous consequences. 863 863 </p> 864 864 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 890 890 </p> 891 891 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#methods" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> 892 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 893 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 2.3</a>. 892 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 893 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not 894 Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 2.3</a>. 894 895 </p> 895 896 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> … … 954 955 </p> 955 956 <p id="rfc.section.2.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p> 956 <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then 957 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions 958 to HTTP might use the OPTIONS body to make more detailed queries on the server. 957 <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS 958 body to make more detailed queries on the server. 959 959 </p> 960 960 <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. … … 966 966 with that resource. 967 967 </p> 968 <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., 969 Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 968 <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 970 969 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 971 970 </p> 972 <p id="rfc.section.2.3.1.p.7">The Max-Forwardsheader field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.971 <p id="rfc.section.2.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 973 972 </p> 974 973 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="GET" href="#GET">GET</a></h3> … … 1023 1022 the result. 1024 1023 </p> 1025 <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a Location header 1026 field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.13</a>). 1027 </p> 1028 <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1024 <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.13</a>). 1025 </p> 1026 <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1029 1027 </p> 1030 1028 <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource. … … 1049 1047 related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent 1050 1048 with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an 1051 appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on Content-Type values. 1052 </p> 1053 <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being 1054 PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format 1055 consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response 1056 indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would 1057 be a suitable target for the new representation. 1058 </p> 1049 appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values. 1050 </p> 1051 <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: 1052 </p> 1053 <ol class="la"> 1054 <li>reconfigure the target resource to reflect the new media type;</li> 1055 <li>transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state; 1056 or, 1057 </li> 1058 <li>reject the request with a <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> response indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that 1059 would be a suitable target for the new representation. 1060 </li> 1061 </ol> 1059 1062 <p id="rfc.section.2.3.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent 1060 1063 of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in … … 1108 1111 <div id="rfc.iref.t.1"></div> 1109 1112 <div id="rfc.iref.m.7"></div> 1110 <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a Max-Forwards value of zero (0) in 1111 the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1113 <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1112 1114 </p> 1113 1115 <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1114 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1115 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1116 infinite loop. 1117 </p> 1118 <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1116 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1117 messages in an infinite loop. 1118 </p> 1119 <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1119 1120 </p> 1120 1121 <div id="rfc.iref.c.2"></div> … … 1183 1184 double quotes will likely cause unnecessary confusion. 1184 1185 </p> 1185 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 9.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing1186 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 9.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 1186 1187 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 1187 1188 it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section 5.5</a>). … … 1400 1401 </li> 1401 1402 </ul> 1402 <p id="rfc.section.4.p.4">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's 1403 media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 9.9</a>). 1403 <p id="rfc.section.4.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 9.9</a>). 1404 1404 </p> 1405 1405 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> … … 1705 1705 <p id="rfc.section.4.4.2.p.1">The request has been fulfilled and has resulted in one or more new resources being created.</p> 1706 1706 <p id="rfc.section.4.4.2.p.2">Newly created resources are typically linked to from the response payload, with the most relevant URI also being carried in 1707 the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information1708 can be omitted(e.g., in the case of a response to a PUT request).1707 the <a href="#header.location" class="smpl">Location</a> header field. If the newly created resource's URI is the same as the Effective Request URI, this information can be omitted 1708 (e.g., in the case of a response to a PUT request). 1709 1709 </p> 1710 1710 <p id="rfc.section.4.4.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead. 1711 1711 </p> 1712 1712 <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by 1713 the Locationheader field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).1713 the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1714 1714 </p> 1715 1715 <div id="rfc.iref.27"></div> … … 1775 1775 <ol> 1776 1776 <li> 1777 <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the Location header1778 field. In this specification, the status codes <a href="#status.301" class="smpl">301(Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> fall under this category.1777 <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the <a href="#header.location" class="smpl">Location</a> header field. In this specification, the status codes <a href="#status.301" class="smpl">301 1778 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> fall under this category. 1779 1779 </p> 1780 1780 </li> … … 1801 1801 </p> 1802 1802 </div> 1803 <p id="rfc.section.4.5.p.4">A Locationheader field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 9.13</a>.1803 <p id="rfc.section.4.5.p.4">A <a href="#header.location" class="smpl">Location</a> header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 9.13</a>. 1804 1804 </p> 1805 1805 <p id="rfc.section.4.5.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was … … 1823 1823 choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1824 1824 </p> 1825 <p id="rfc.section.4.5.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Locationfield; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.1825 <p id="rfc.section.4.5.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the <a href="#header.location" class="smpl">Location</a> field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. 1826 1826 </p> 1827 1827 <p id="rfc.section.4.5.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. … … 1835 1835 <p id="rfc.section.4.5.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1836 1836 </p> 1837 <p id="rfc.section.4.5.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to 1838 the new URI(s). 1837 <p id="rfc.section.4.5.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s). 1839 1838 </p> 1840 1839 <div class="note" id="rfc.section.4.5.2.p.4"> … … 1847 1846 <p id="rfc.section.4.5.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1848 1847 </p> 1849 <p id="rfc.section.4.5.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to 1850 the new URI(s). 1848 <p id="rfc.section.4.5.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s). 1851 1849 </p> 1852 1850 <div class="note" id="rfc.section.4.5.3.p.3"> … … 1858 1856 <h3 id="rfc.section.4.5.4"><a href="#rfc.section.4.5.4">4.5.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3> 1859 1857 <p id="rfc.section.4.5.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI 1860 in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy1861 the original request,a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further,1858 in the <a href="#header.location" class="smpl">Location</a> header field, that is intended to provide an indirect response to the original request. In order to satisfy the original request, 1859 a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, 1862 1860 and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is 1863 1861 not considered equivalent to the effective request URI. … … 1868 1866 </p> 1869 1867 <p id="rfc.section.4.5.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be 1870 transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such1871 t hat the follow-on representation might be useful to recipients without implying that it adequately represents the target1872 resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might1873 be a useful description are outside the scope of HTTPand thus entirely determined by the URI owner(s).1874 </p> 1875 <p id="rfc.section.4.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the LocationURI.1868 transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> URI indicates a resource that is descriptive of the target resource, such that the follow-on representation might be useful 1869 to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what 1870 can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP 1871 and thus entirely determined by the URI owner(s). 1872 </p> 1873 <p id="rfc.section.4.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the <a href="#header.location" class="smpl">Location</a> URI. 1876 1874 </p> 1877 1875 <div id="rfc.iref.36"></div> … … 1889 1887 <p id="rfc.section.4.5.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1890 1888 </p> 1891 <p id="rfc.section.4.5.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to 1892 the new URI(s). 1889 <p id="rfc.section.4.5.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s). 1893 1890 </p> 1894 1891 <div class="note" id="rfc.section.4.5.7.p.3"> … … 1934 1931 <div id="rfc.iref.s.26"></div> 1935 1932 <h3 id="rfc.section.4.6.5"><a href="#rfc.section.4.6.5">4.6.5</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 1936 <p id="rfc.section.4.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allowheader field containing a list of valid methods for the requested resource.1933 <p id="rfc.section.4.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an <a href="#header.allow" class="smpl">Allow</a> header field containing a list of valid methods for the requested resource. 1937 1934 </p> 1938 1935 <div id="rfc.iref.45"></div> … … 1940 1937 <h3 id="rfc.section.4.6.6"><a href="#rfc.section.4.6.6">4.6.6</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1941 1938 <p id="rfc.section.4.6.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics 1942 not acceptable according to the Acceptand Accept-* header fields sent in the request.1939 not acceptable according to the <a href="#header.accept" class="smpl">Accept</a> and Accept-* header fields sent in the request. 1943 1940 </p> 1944 1941 <p id="rfc.section.4.6.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user … … 1999 1996 to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. 2000 1997 </p> 2001 <p id="rfc.section.4.6.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-Afterheader field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.1998 <p id="rfc.section.4.6.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again. 2002 1999 </p> 2003 2000 <div id="rfc.iref.51"></div> … … 2019 2016 <div id="rfc.iref.s.35"></div> 2020 2017 <h3 id="rfc.section.4.6.14"><a href="#rfc.section.4.6.14">4.6.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 2021 <p id="rfc.section.4.6.14.p.1">The expectation given in an Expectheader field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 9.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could2018 <p id="rfc.section.4.6.14.p.1">The expectation given in an <a href="#header.expect" class="smpl">Expect</a> header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 9.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could 2022 2019 not be met by the next-hop server. 2023 2020 </p> … … 2066 2063 <p id="rfc.section.4.7.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p> 2067 2064 <p id="rfc.section.4.7.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the 2068 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 9.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 2065 delay <em class="bcp14">MAY</em> be indicated in a <a href="#header.retry-after" class="smpl">Retry-After</a> header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 9.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a <a href="#status.500" class="smpl">500 (Internal 2066 Server Error)</a> response. 2069 2067 </p> 2070 2068 <div class="note" id="rfc.section.4.7.4.p.3"> … … 2201 2199 Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry. 2202 2200 </p> 2203 <p id="rfc.section.5.3.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted 2204 token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter 2205 value of the charset parameter can be quoted. 2201 <p id="rfc.section.5.3.p.5">HTTP uses charset in two contexts: within an <a href="#header.accept-charset" class="smpl">Accept-Charset</a> request header field (in which the charset value is an unquoted token) and as the value of a parameter in a <a href="#header.content-type" class="smpl">Content-Type</a> header field (within a request or response), in which case the parameter value of the charset parameter can be quoted. 2206 2202 </p> 2207 2203 <p id="rfc.section.5.3.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>. … … 2214 2210 </p> 2215 2211 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#core.rules" class="smpl">token</a> 2216 </pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 9.3</a>) and Content-Encoding(<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 9.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding2212 </pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 9.3</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 9.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 2217 2213 mechanism will be required to remove the encoding. 2218 2214 </p> … … 2251 2247 </p> 2252 2248 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="media.types" href="#media.types">Media Types</a></h2> 2253 <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 9.9</a>) and Accept(<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 9.1</a>) header fields in order to provide open and extensible data typing and type negotiation.2249 <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 9.9</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 9.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 2254 2250 </p> 2255 2251 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) … … 2305 2301 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="language.tags" href="#language.tags">Language Tags</a></h2> 2306 2302 <p id="rfc.section.5.6.p.1">A language tag, as defined in <a href="#RFC5646" id="rfc.xref.RFC5646.1"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to 2307 other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language 2308 fields. 2303 other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the <a href="#header.accept-language" class="smpl">Accept-Language</a> and <a href="#header.content-language" class="smpl">Content-Language</a> fields. 2309 2304 </p> 2310 2305 <p id="rfc.section.5.6.p.2">In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series … … 2367 2362 (request or response), the request method, the response status code, and the representation metadata. For example, the above 2368 2363 semantic is true for the representation in any <a href="#status.200" class="smpl">200 (OK)</a> response to GET and for the representation in any PUT request. A 200 response to PUT, in contrast, contains either a representation 2369 that describes the successful action or a representation of the target resource, with the latter indicated by a Content-Location 2370 header field with the same value as the effective request URI. Likewise, response messages with an error status code usually 2364 that describes the successful action or a representation of the target resource, with the latter indicated by a <a href="#header.content-location" class="smpl">Content-Location</a> header field with the same value as the effective request URI. Likewise, response messages with an error status code usually 2371 2365 contain a representation that describes the error and what next steps are suggested for resolving it. 2372 2366 </p> … … 2390 2384 <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource. 2391 2385 </li> 2392 <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload2393 is a representation of the targetresource.2394 </li> 2395 <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response2396 asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion2397 cannot be trusted unless it can be verifiedby other means (not defined by HTTP).2386 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is the same as the effective request URI, the response payload is a representation of the target 2387 resource. 2388 </li> 2389 <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation 2390 of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified 2391 by other means (not defined by HTTP). 2398 2392 </li> 2399 2393 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> … … 2468 2462 the representation metadata header fields. 2469 2463 </p> 2470 <p id="rfc.section.7.3.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define 2471 a two-layer, ordered encoding model: 2464 <p id="rfc.section.7.3.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model: 2472 2465 </p> 2473 2466 <div id="rfc.figure.u.23"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) ) 2474 </pre><p id="rfc.section.7.3.p.4"> Content-Typespecifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload2467 </pre><p id="rfc.section.7.3.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload 2475 2468 body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown 2476 2469 to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type … … 2484 2477 such "content sniffing" when it is used. 2485 2478 </p> 2486 <p id="rfc.section.7.3.p.6"> Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,2487 that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond2488 that defined by the Content-Type.2479 <p id="rfc.section.7.3.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that 2480 are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that 2481 defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. 2489 2482 </p> 2490 2483 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> … … 2521 2514 to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response 2522 2515 (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to 2523 improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields ( Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.2516 improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response. 2524 2517 </p> 2525 2518 <p id="rfc.section.8.1.p.3">Server-driven negotiation has disadvantages: </p> … … 2543 2536 </p> 2544 2537 <p id="rfc.section.8.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 2545 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 9.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 9.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 9.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 9.4</a>), and User-Agent(<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 9.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information2538 and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 9.1</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 9.2</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 9.3</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 9.4</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 9.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 2546 2539 within extension header fields not defined by this specification. 2547 2540 </p> 2548 2541 <div class="note" id="rfc.section.8.1.p.7"> 2549 <p> <b>Note:</b> In practice, User-Agentbased negotiation is fragile, because new clients might not be recognized.2542 <p> <b>Note:</b> In practice, <a href="#header.user-agent" class="smpl">User-Agent</a> based negotiation is fragile, because new clients might not be recognized. 2550 2543 </p> 2551 2544 </div> … … 2791 2784 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 2792 2785 <p id="rfc.section.9.6.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent 2793 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the 2794 Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the 2795 identity of its underlying media type. 2786 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of 2787 its underlying media type. 2796 2788 </p> 2797 2789 <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.41"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> … … 2807 2799 would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin 2808 2800 server might choose to publish the same payload data as multiple representations that differ only in whether the coding is 2809 defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each2810 response (e.g., open a "Saveas ..." dialog instead of automatic decompression and rendering of content).2801 defined as part of <a href="#header.content-type" class="smpl">Content-Type</a> or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save 2802 as ..." dialog instead of automatic decompression and rendering of content). 2811 2803 </p> 2812 2804 <p id="rfc.section.9.6.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 9.6</a>) that lists the content-coding(s) applied. … … 2999 2991 </p> 3000 2992 <div class="note" id="rfc.section.9.13.p.9"> 3001 <p> <b>Note:</b> The Content-Locationheader field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.2993 <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 3002 2994 It is therefore possible for a response to contain header fields for both Location and Content-Location. 3003 2995 </p> … … 3591 3583 <tr> 3592 3584 <td class="left">identity</td> 3593 <td class="left">reserved (synonym for "no encoding" in Accept-Encoding header field)</td> 3585 <td class="left">reserved (synonym for "no encoding" in <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> header field) 3586 </td> 3594 3587 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section 9.3</a> 3595 3588 </td> … … 3607 3600 a priori method of determining the sensitivity of any particular piece of information within the context of any given request. 3608 3601 Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth 3609 special mention in this context: Server, Via, Referer and From.3602 special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>. 3610 3603 </p> 3611 3604 <p id="rfc.section.11.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 3612 against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Serverheader field a configurable option.3605 against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the <a href="#header.server" class="smpl">Server</a> header field a configurable option. 3613 3606 </p> 3614 3607 <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, 3615 3608 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. 3616 3609 </p> 3617 <p id="rfc.section.11.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its 3618 power can be abused if user details are not separated from the information contained in the Referer. Even when the personal 3619 information has been removed, the Referer header field might indicate a private document's URI whose publication would be 3620 inappropriate. 3621 </p> 3622 <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and 3623 hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration. 3610 <p id="rfc.section.11.1.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can 3611 be abused if user details are not separated from the information contained in the Referer. Even when the personal information 3612 has been removed, the Referer header field might indicate a private document's URI whose publication would be inappropriate. 3613 </p> 3614 <p id="rfc.section.11.1.p.5">The information sent in the <a href="#header.from" class="smpl">From</a> field might conflict with the user's privacy interests or their site's security policy, and hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration. 3624 3615 </p> 3625 3616 <p id="rfc.section.11.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending 3626 of From and Refererinformation.3627 </p> 3628 <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 9.18</a>) or Server(<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might3617 of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information. 3618 </p> 3619 <p id="rfc.section.11.1.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 9.18</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might 3629 3620 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 3630 3621 no better mechanism. 3631 3622 </p> 3632 <p id="rfc.section.11.1.p.8">Furthermore, the User-Agent header field might contain enough entropy to be used, possibly in conjunction with other material,3633 to uniquely identify theuser.3623 <p id="rfc.section.11.1.p.8">Furthermore, the <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the 3624 user. 3634 3625 </p> 3635 3626 <p id="rfc.section.11.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 2.3.7</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used … … 3638 3629 <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> 3639 3630 <p id="rfc.section.11.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly 3640 recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could 3641 have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From 3642 information. 3643 </p> 3644 <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 3631 recommended that the user be able to select whether or not the <a href="#header.referer" class="smpl">Referer</a> field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively 3632 enable/disable the sending of Referer and From information. 3633 </p> 3634 <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a <a href="#header.referer" class="smpl">Referer</a> header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 3645 3635 </p> 3646 3636 <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing … … 3649 3639 </p> 3650 3640 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2> 3651 <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations 3652 to make sure that they do not attempt to invalidate resources over which they have no authority. 3653 </p> 3654 <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak 3655 confidential information to the target server — although the fragment identifier is not transmitted in the final request, 3656 it might be visible to the user agent through other means, such as scripting. 3641 <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of <a href="#header.location" class="smpl">Location</a> and <a href="#header.content-location" class="smpl">Content-Location</a> header fields in responses that are generated under control of said organizations to make sure that they do not attempt to 3642 invalidate resources over which they have no authority. 3643 </p> 3644 <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a <a href="#header.location" class="smpl">Location</a> header field might leak confidential information to the target server — although the fragment identifier is not transmitted 3645 in the final request, it might be visible to the user agent through other means, such as scripting. 3657 3646 </p> 3658 3647 <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a> Security Considerations for CONNECT … … 3662 3651 </p> 3663 3652 <h2 id="rfc.section.11.5"><a href="#rfc.section.11.5">11.5</a> <a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2> 3664 <p id="rfc.section.11.5.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field 3665 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular 3666 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option 3667 to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged to let the 3668 configuration process include a message which makes the user aware of the loss of privacy involved. 3653 <p id="rfc.section.11.5.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding 3654 of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer 3655 the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged 3656 to let the configuration process include a message which makes the user aware of the loss of privacy involved. 3669 3657 </p> 3670 3658 <p id="rfc.section.11.5.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields … … 3912 3900 </p> 3913 3901 <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 5.5.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of 3914 a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 103915 to represent CR andLF, respectively, as is the case for some multi-byte character encodings.3902 a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10 to represent CR and 3903 LF, respectively, as is the case for some multi-byte character encodings. 3916 3904 </p> 3917 3905 <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in … … 3919 3907 </p> 3920 3908 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2> 3921 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section 5.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Dateheader field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.3909 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section 5.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any <a href="#header.date" class="smpl">Date</a> header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary. 3922 3910 </p> 3923 3911 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> 3924 <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on 3925 the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some 3926 experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" 3927 to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards). 3912 <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's <a href="#header.content-encoding" class="smpl">Content-Encoding</a> header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the <a href="#header.content-type" class="smpl">Content-Type</a> header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for 3913 Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform a function equivalent to Content-Encoding. 3914 However, this parameter is not part of the MIME standards). 3928 3915 </p> 3929 3916 <div id="rfc.iref.c.11"></div> … … 3971 3958 </p> 3972 3959 <p id="rfc.section.C.p.8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through 3973 the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient was expected to repeat3974 this single request via the proxy.(<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 4.5.5</a>)3960 the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The Location field gave the URI of the proxy. The recipient was expected to repeat this single request via the proxy. 3961 (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 4.5.5</a>) 3975 3962 </p> 3976 3963 <p id="rfc.section.C.p.9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 4.6.15</a>) … … 3978 3965 <p id="rfc.section.C.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 3979 3966 </p> 3980 <p id="rfc.section.C.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 3981 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.5</a>) 3982 </p> 3983 <p id="rfc.section.C.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified 3984 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.11</a>) 3985 </p> 3986 <p id="rfc.section.C.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3987 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 3988 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9.13</a>) 3989 </p> 3990 <p id="rfc.section.C.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.14</a>) 3991 </p> 3992 <p id="rfc.section.C.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.15</a>) 3993 </p> 3994 <p id="rfc.section.C.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3995 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.60"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.17</a>) 3967 <p id="rfc.section.C.p.11">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents 3968 of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.5</a>) 3969 </p> 3970 <p id="rfc.section.C.p.12">The ABNF for the <a href="#header.expect" class="smpl">Expect</a> header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing 3971 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.11</a>) 3972 </p> 3973 <p id="rfc.section.C.p.13">Correct syntax of <a href="#header.location" class="smpl">Location</a> header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't 3974 what was expected, and add some clarifications as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9.13</a>) 3975 </p> 3976 <p id="rfc.section.C.p.14">Restrict <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.14</a>) 3977 </p> 3978 <p id="rfc.section.C.p.15">Allow <a href="#header.referer" class="smpl">Referer</a> field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.15</a>) 3979 </p> 3980 <p id="rfc.section.C.p.16">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.60"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.17</a>) 3996 3981 </p> 3997 3982 <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 5.3</a>) … … 4007 3992 and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 4008 3993 </p> 4009 <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 9.2</a>) 4010 </p> 4011 <p id="rfc.section.C.p.23">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken 4012 servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking 4013 relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 9.8</a>) 3994 <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in <a href="#header.accept-charset" class="smpl">Accept-Charset</a>. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 9.2</a>) 3995 </p> 3996 <p id="rfc.section.C.p.23">Remove base URI setting semantics for <a href="#header.content-location" class="smpl">Content-Location</a> due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields, 3997 and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 9.8</a>) 4014 3998 </p> 4015 3999 <p id="rfc.section.C.p.24">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>) -
draft-ietf-httpbis/latest/p2-semantics.xml
r1739 r1740 305 305 impact on security. This is because different uses of the protocol require 306 306 different error handling strategies; for example, a Web browser might wish to 307 transparently recover from a response where the Location header field 308 doesn't parse according to the ABNF, whereby in a systems control protocol 309 using HTTP, this type of error recovery could lead to dangerous consequences. 307 transparently recover from a response where the <x:ref>Location</x:ref> 308 header field doesn't parse according to the ABNF, whereby in a systems 309 control protocol using HTTP, this type of error recovery could lead to 310 dangerous consequences. 310 311 </t> 311 312 </section> … … 388 389 <t> 389 390 The list of methods allowed by a resource can be specified in an 390 Allow header field (<xref target="header.allow"/>). The status code of the response391 always notifies the client whether a method is currently allowed on a392 resource, since the set of allowed methods can change dynamically. An393 origin server &SHOULD; respond with the status code <x:ref>405 (Method Not Allowed)</x:ref>394 if the method is known by the origin server but not allowed for the395 resource, and <x:ref>501 (Not Implemented)</x:ref> if the method is396 unrecognized or not implemented by the origin server. The methods GET397 and HEAD &MUST; be supported by all general-purpose servers. All other398 methods are &OPTIONAL;; however, if the above methods are implemented,399 they &MUST; be implemented with the same semantics as those specified400 in <xref target="method.definitions"/>.391 <x:ref>Allow</x:ref> header field (<xref target="header.allow"/>). The 392 status code of the response always notifies the client whether a method is 393 currently allowed on a resource, since the set of allowed methods can change 394 dynamically. An origin server &SHOULD; respond with the status code 395 <x:ref>405 (Method Not Allowed)</x:ref> if the method is known by the origin 396 server but not allowed for the resource, and <x:ref>501 (Not 397 Implemented)</x:ref> if the method is unrecognized or not implemented by the 398 origin server. The methods GET and HEAD &MUST; be supported by all 399 general-purpose servers. All other methods are &OPTIONAL;; however, if the 400 above methods are implemented, they &MUST; be implemented with the same 401 semantics as those specified in <xref target="method.definitions"/>. 401 402 </t> 402 403 … … 520 521 <t> 521 522 If the OPTIONS request includes a message body (as indicated by the 522 presence of Content-Length or Transfer-Encoding), then the media type523 &MUST; be indicated by a Content-Type field. Although this524 specification does not define any use for such a body, future525 extensions to HTTP might use the OPTIONS body to make more detailed523 presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>), 524 then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref> 525 field. Although this specification does not define any use for such a body, 526 future extensions to HTTP might use the OPTIONS body to make more detailed 526 527 queries on the server. 527 528 </t> … … 544 545 A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that 545 546 indicate optional features implemented by the server and applicable to that 546 resource (e.g., Allow), possibly including extensions not defined by547 this specification. The response body, if any, &SHOULD; also include548 in formation about the communication options. The format for such a547 resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not 548 defined by this specification. The response body, if any, &SHOULD; also 549 include information about the communication options. The format for such a 549 550 body is not defined by this specification, but might be defined by 550 551 future extensions to HTTP. Content negotiation &MAY; be used to select … … 554 555 </t> 555 556 <t> 556 The Max-Forwardsheader field &MAY; be used to target a557 The <x:ref>Max-Forwards</x:ref> header field &MAY; be used to target a 557 558 specific proxy in the request chain (see <xref target="header.max-forwards"/>). 558 559 If no Max-Forwards field is present in the request, then the forwarded … … 681 682 &SHOULD; be <x:ref>201 (Created)</x:ref> and contain a representation which 682 683 describes the status of the request and refers to the new resource, and a 683 Locationheader field (see <xref target="header.location"/>).684 <x:ref>Location</x:ref> header field (see <xref target="header.location"/>). 684 685 </t> 685 686 <t> 686 687 Responses to POST requests are only cacheable when they 687 688 include explicit freshness information (see &p6-explicit;). A 688 cached POST response with a Content-Locationheader field689 cached POST response with a <x:ref>Content-Location</x:ref> header field 689 690 (see &header-content-location;) whose value is the effective 690 691 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests. … … 740 741 representation or changing the resource configuration, or respond 741 742 with an appropriate error message containing sufficient information 742 to explain why the representation is unsuitable. The <x:ref>409 (Conflict)</x:ref> 743 or <x:ref>415 (Unsupported Media Type)</x:ref> status codes are suggested, with the 744 latter being specific to constraints on Content-Type values. 743 to explain why the representation is unsuitable. The 744 <x:ref>409 (Conflict)</x:ref> or <x:ref>415 (Unsupported Media Type)</x:ref> 745 status codes are suggested, with the latter being specific to constraints on 746 <x:ref>Content-Type</x:ref> values. 745 747 </t> 746 748 <t> 747 749 For example, if the target resource is configured to always have a 748 Content-Type of "text/html" and the representation being PUT has a 749 Content-Type of "image/jpeg", then the origin server &SHOULD; do one of: 750 (a) reconfigure the target resource to reflect the new media type; 751 (b) transform the PUT representation to a format consistent with that 752 of the resource before saving it as the new resource state; or, 753 (c) reject the request with a 415 response indicating that the target 754 resource is limited to "text/html", perhaps including a link to a 755 different resource that would be a suitable target for the new 756 representation. 750 <x:ref>Content-Type</x:ref> of "text/html" and the representation being PUT 751 has a Content-Type of "image/jpeg", then the origin server &SHOULD; do one of: 752 <list style="letters"> 753 <t>reconfigure the target resource to reflect the new media type;</t> 754 <t>transform the PUT representation to a format consistent with that 755 of the resource before saving it as the new resource state; or,</t> 756 <t>reject the request with a <x:ref>415 (Unsupported Media Type)</x:ref> 757 response indicating that the target resource is limited to "text/html", 758 perhaps including a link to a different resource that would be a 759 suitable target for the new representation.</t> 760 </list> 757 761 </t> 758 762 <t> … … 870 874 &SHOULD; reflect the message received back to the client as the message body 871 875 of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the 872 origin server or the first proxy to receive a Max-Forwards876 origin server or the first proxy to receive a <x:ref>Max-Forwards</x:ref> 873 877 value of zero (0) in the request (see <xref target="header.max-forwards"/>). 874 878 A TRACE request &MUST-NOT; include a message body. … … 879 883 information. The value of the Via header field (&header-via;) is of 880 884 particular interest, since it acts as a trace of the request chain. 881 Use of the Max-Forwards header field allows the client to limit the882 l ength of the request chain, which is useful for testing a chain of885 Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to 886 limit the length of the request chain, which is useful for testing a chain of 883 887 proxies forwarding messages in an infinite loop. 884 888 </t> 885 889 <t> 886 If the request is valid, the response &SHOULD; have a Content-Type of887 "message/http" (see &media-type-message-http;) and contain a message body888 that encloses a copy of the entire request message.890 If the request is valid, the response &SHOULD; have a 891 <x:ref>Content-Type</x:ref> of "message/http" (see &media-type-message-http;) 892 and contain a message body that encloses a copy of the entire request message. 889 893 Responses to the TRACE method are not cacheable. 890 894 </t> … … 1023 1027 <t> 1024 1028 Many header fields use a format including (case-insensitively) named 1025 parameters (for instance, Content-Type, defined in &header-content-type;). 1026 Allowing both unquoted (token) and quoted (quoted-string) syntax for the 1027 parameter value enables recipients to use existing parser components. When 1028 allowing both forms, the meaning of a parameter value ought to be 1029 independent of the syntax used for it (for an example, see the notes on 1030 parameter handling for media types in &media-types;). 1029 parameters (for instance, <x:ref>Content-Type</x:ref>, defined in 1030 &header-content-type;). Allowing both unquoted (token) and quoted 1031 (quoted-string) syntax for the parameter value enables recipients to use 1032 existing parser components. When allowing both forms, the meaning of a 1033 parameter value ought to be independent of the syntax used for it (for an 1034 example, see the notes on parameter handling for media types in 1035 &media-types;). 1031 1036 </t> 1032 1037 <t> … … 1173 1178 <t> 1174 1179 For most status codes the response can carry a payload, in which case a 1175 Content-Typeheader field indicates the payload's media type1180 <x:ref>Content-Type</x:ref> header field indicates the payload's media type 1176 1181 (&header-content-type;). 1177 1182 </t> … … 1408 1413 <t> 1409 1414 Newly created resources are typically linked to from the response payload, 1410 with the most relevant URI also being carried in the Location header field.1411 If the newly created resource's URI is the same as the Effective Request URI,1412 this information can be omitted (e.g., in the case of a response to a PUT1413 request).1415 with the most relevant URI also being carried in the <x:ref>Location</x:ref> 1416 header field. If the newly created resource's URI is the same as the 1417 Effective Request URI, this information can be omitted (e.g., in the case of 1418 a response to a PUT request). 1414 1419 </t> 1415 1420 <t> … … 1421 1426 A 201 response &MAY; contain an <x:ref>ETag</x:ref> response header field 1422 1427 indicating the current value of the entity-tag for the representation of the 1423 resource identified by the Location header field or, in case the Location 1424 header field was omitted, by the Effective Request URI (see &header-etag;). 1428 resource identified by the <x:ref>Location</x:ref> header field or, in case 1429 the Location header field was omitted, by the Effective Request URI (see 1430 &header-etag;). 1425 1431 </t> 1426 1432 </section> … … 1547 1553 <t> 1548 1554 Redirects of the request to another URI, either temporarily or 1549 permanently. The new URI is specified in the Location header field.1550 In this specification, the status codes <x:ref>301 (Moved Permanently)</x:ref>,1551 <x:ref>302 (Found)</x:ref>, and <x:ref>307 (Temporary Redirect)</x:ref>1552 fall under this category.1555 permanently. The new URI is specified in the <x:ref>Location</x:ref> 1556 header field. In this specification, the status codes <x:ref>301 1557 (Moved Permanently)</x:ref>, <x:ref>302 (Found)</x:ref>, and 1558 <x:ref>307 (Temporary Redirect)</x:ref> fall under this category. 1553 1559 </t> 1554 1560 </x:lt> … … 1595 1601 </x:note> 1596 1602 <t> 1597 A Location header field on a 3xx response indicates that a client &MAY; 1598 automatically redirect to the URI provided; see <xref target="header.location"/>. 1603 A <x:ref>Location</x:ref> header field on a 3xx response indicates that a 1604 client &MAY; automatically redirect to the URI provided; see 1605 <xref target="header.location"/>. 1599 1606 </t> 1600 1607 <t> … … 1638 1645 <t> 1639 1646 If the server has a preferred choice of representation, it &SHOULD; 1640 include the specific URI for that representation in the Location1647 include the specific URI for that representation in the <x:ref>Location</x:ref> 1641 1648 field; user agents &MAY; use the Location field value for automatic 1642 1649 redirection. … … 1666 1673 </t> 1667 1674 <t> 1668 The new permanent URI &SHOULD; be given by the Location field in the1669 response. A response payload can contain a short hypertext note with a1675 The new permanent URI &SHOULD; be given by the <x:ref>Location</x:ref> field 1676 in the response. A response payload can contain a short hypertext note with a 1670 1677 hyperlink to the new URI(s). 1671 1678 </t> … … 1691 1698 </t> 1692 1699 <t> 1693 The temporary URI &SHOULD; be given by the Location field in the1694 response. A response payload can contain a short hypertext note with a1700 The temporary URI &SHOULD; be given by the <x:ref>Location</x:ref> field in 1701 the response. A response payload can contain a short hypertext note with a 1695 1702 hyperlink to the new URI(s). 1696 1703 </t> … … 1712 1719 The 303 status code indicates that the server is redirecting the 1713 1720 user agent to a different resource, as indicated by a URI in the 1714 Locationheader field, that is intended to provide an indirect1721 <x:ref>Location</x:ref> header field, that is intended to provide an indirect 1715 1722 response to the original request. In order to satisfy the original 1716 1723 request, a user agent &SHOULD; perform a retrieval request using the … … 1732 1739 A 303 response to a GET request indicates that the requested 1733 1740 resource does not have a representation of its own that can be 1734 transferred by the server over HTTP. The Location URI indicates a1735 resource that is descriptive of the target resource, such that the1736 follow-on representation might be useful to recipients without1741 transferred by the server over HTTP. The <x:ref>Location</x:ref> URI 1742 indicates a resource that is descriptive of the target resource, such that 1743 the follow-on representation might be useful to recipients without 1737 1744 implying that it adequately represents the target resource. 1738 1745 Note that answers to the questions of what can be represented, what … … 1744 1751 Except for responses to a HEAD request, the representation of a 303 1745 1752 response &SHOULD; contain a short hypertext note with a hyperlink 1746 to the LocationURI.1753 to the <x:ref>Location</x:ref> URI. 1747 1754 </t> 1748 1755 </section> … … 1778 1785 </t> 1779 1786 <t> 1780 The temporary URI &SHOULD; be given by the Location field in the1781 response. A response payload can contain a short hypertext note with a1787 The temporary URI &SHOULD; be given by the <x:ref>Location</x:ref> field in 1788 the response. A response payload can contain a short hypertext note with a 1782 1789 hyperlink to the new URI(s). 1783 1790 </t> … … 1867 1874 <t> 1868 1875 The method specified in the request-line is not allowed for the target 1869 resource. The response &MUST; include an Allow header field containing a1870 list of valid methods for the requested resource.1876 resource. The response &MUST; include an <x:ref>Allow</x:ref> header field 1877 containing a list of valid methods for the requested resource. 1871 1878 </t> 1872 1879 </section> … … 1879 1886 The resource identified by the request is only capable of generating 1880 1887 response representations which have content characteristics not acceptable 1881 according to the Accept and Accept-* header fields sent in the request. 1888 according to the <x:ref>Accept</x:ref> and Accept-* header fields sent in 1889 the request. 1882 1890 </t> 1883 1891 <t> … … 1993 2001 </t> 1994 2002 <t> 1995 If the condition is temporary, the server &SHOULD; include a Retry-After1996 header field to indicate that it is temporary and after what1997 time the client &MAY; try again.2003 If the condition is temporary, the server &SHOULD; include a 2004 <x:ref>Retry-After</x:ref> header field to indicate that it is temporary and 2005 after what time the client &MAY; try again. 1998 2006 </t> 1999 2007 </section> … … 2032 2040 <x:anchor-alias value="417 (Expectation Failed)"/> 2033 2041 <t> 2034 The expectation given in an Expect header field (see <xref target="header.expect"/>)2035 could not be met by this server, or, if the server is a proxy,2036 the server has unambiguous evidence that the request could not be met2037 by the next-hop server.2042 The expectation given in an <x:ref>Expect</x:ref> header field (see 2043 <xref target="header.expect"/>) could not be met by this server, or, if the 2044 server is a proxy, the server has unambiguous evidence that the request 2045 could not be met by the next-hop server. 2038 2046 </t> 2039 2047 </section> … … 2126 2134 The implication is that this is a temporary condition which will be 2127 2135 alleviated after some delay. If known, the length of the delay &MAY; be 2128 indicated in a Retry-After header field (<xref target="header.retry-after"/>). 2129 If no Retry-After is given, the client &SHOULD; handle the response as it 2130 would for a 500 response. 2136 indicated in a <x:ref>Retry-After</x:ref> header field 2137 (<xref target="header.retry-after"/>). If no Retry-After is given, the 2138 client &SHOULD; handle the response as it would for a <x:ref>500 (Internal 2139 Server Error)</x:ref> response. 2131 2140 </t> 2132 2141 <x:note> … … 2375 2384 </t> 2376 2385 <t> 2377 HTTP uses charset in two contexts: within an Accept-Charset request2378 header field (in which the charset value is an unquoted token) and as the2379 value of a parameter in a Content-Type header field (within a request or2380 response), in which case the parameter value of the charset parameter2381 c an be quoted.2386 HTTP uses charset in two contexts: within an <x:ref>Accept-Charset</x:ref> 2387 request header field (in which the charset value is an unquoted token) and 2388 as the value of a parameter in a <x:ref>Content-Type</x:ref> header field 2389 (within a request or response), in which case the parameter value of the 2390 charset parameter can be quoted. 2382 2391 </t> 2383 2392 <t> … … 2402 2411 <t> 2403 2412 All content-coding values are case-insensitive. HTTP/1.1 uses 2404 content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and 2405 Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value 2413 content-coding values in the <x:ref>Accept-Encoding</x:ref> 2414 (<xref target="header.accept-encoding"/>) and <x:ref>Content-Encoding</x:ref> 2415 (<xref target="header.content-encoding"/>) header fields. Although the value 2406 2416 describes the content-coding, what is more important is that it 2407 2417 indicates what decoding mechanism will be required to remove the … … 2470 2480 <x:anchor-alias value="subtype"/> 2471 2481 <t> 2472 HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>) 2473 and Accept (<xref target="header.accept"/>) header fields in order to provide 2474 open and extensible data typing and type negotiation. 2482 HTTP uses Internet Media Types <xref target="RFC2046"/> in the 2483 <x:ref>Content-Type</x:ref> (<xref target="header.content-type"/>) 2484 and <x:ref>Accept</x:ref> (<xref target="header.accept"/>) header fields in 2485 order to provide open and extensible data typing and type negotiation. 2475 2486 </t> 2476 2487 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/> … … 2585 2596 natural language spoken, written, or otherwise conveyed by human beings for 2586 2597 communication of information to other human beings. Computer languages are 2587 explicitly excluded. HTTP uses language tags within the Accept-Language and2588 Content-Languagefields.2598 explicitly excluded. HTTP uses language tags within the 2599 <x:ref>Accept-Language</x:ref> and <x:ref>Content-Language</x:ref> fields. 2589 2600 </t> 2590 2601 <t> … … 2675 2686 A 200 response to PUT, in contrast, contains either a representation 2676 2687 that describes the successful action or a representation of the target 2677 resource, with the latter indicated by a Content-Location header field2678 with the same value as the effective request URI. Likewise, response2679 messages with an error status code usually contain a representation that2680 describes the error and what next steps are suggested for resolving it.2688 resource, with the latter indicated by a <x:ref>Content-Location</x:ref> 2689 header field with the same value as the effective request URI. Likewise, 2690 response messages with an error status code usually contain a representation 2691 that describes the error and what next steps are suggested for resolving it. 2681 2692 </t> 2682 2693 <t> … … 2717 2728 and the request method was GET or HEAD, the response payload is a partial 2718 2729 representation of the target resource.</t> 2719 <t>If the response has a Content-Location header field, and that URI is the same2720 as the effective request URI, the response payload is a representation of the2721 target resource.</t>2722 <t>If the response has a Content-Location header field, and that URI is not the2723 same as the effective request URI, then the response asserts that its2724 payload is a representation of the resource identified by the2725 Content-Location URI. However, such an assertion cannot be trusted unless2730 <t>If the response has a <x:ref>Content-Location</x:ref> header field, and 2731 that URI is the same as the effective request URI, the response payload is a 2732 representation of the target resource.</t> 2733 <t>If the response has a <x:ref>Content-Location</x:ref> header field, and 2734 that URI is not the same as the effective request URI, then the response 2735 asserts that its payload is a representation of the resource identified by 2736 the Content-Location URI. However, such an assertion cannot be trusted unless 2726 2737 it can be verified by other means (not defined by HTTP).</t> 2727 2738 <t>Otherwise, the response is a representation of an anonymous (i.e., … … 2782 2793 </t> 2783 2794 <t> 2784 The data type of the representation data 2785 is determined via the header fields Content-Type and Content-Encoding.2795 The data type of the representation data is determined via the header fields 2796 <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>. 2786 2797 These define a two-layer, ordered encoding model: 2787 2798 </t> … … 2790 2801 </artwork></figure> 2791 2802 <t> 2792 Content-Type specifies the media type of the underlying data, which2793 defines both the data format and how that data &SHOULD; be processed2803 <x:ref>Content-Type</x:ref> specifies the media type of the underlying data, 2804 which defines both the data format and how that data &SHOULD; be processed 2794 2805 by the recipient (within the scope of the request method semantics). 2795 2806 Any HTTP/1.1 message containing a payload body &SHOULD; include a … … 2815 2826 </t> 2816 2827 <t> 2817 Content-Encodingis used to indicate any additional content2828 <x:ref>Content-Encoding</x:ref> is used to indicate any additional content 2818 2829 codings applied to the data, usually for the purpose of data 2819 2830 compression, that are a property of the representation. If 2820 2831 Content-Encoding is not present, then there is no additional 2821 encoding beyond that defined by the Content-Type.2832 encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field. 2822 2833 </t> 2823 2834 </section> … … 2887 2898 avoid the round-trip delay of a subsequent request if the "best 2888 2899 guess" is good enough for the user). In order to improve the server's 2889 guess, the user agent &MAY; include request header fields ( Accept,2890 Accept-Language, Accept-Encoding, etc.) which describe its2900 guess, the user agent &MAY; include request header fields (<x:ref>Accept</x:ref>, 2901 <x:ref>Accept-Language</x:ref>, <x:ref>Accept-Encoding</x:ref>, etc.) which describe its 2891 2902 preferences for such a response. 2892 2903 </t> … … 2931 2942 HTTP/1.1 includes the following header fields for enabling 2932 2943 server-driven negotiation through description of user agent 2933 capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset 2934 (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language 2935 (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;). 2944 capabilities and user preferences: <x:ref>Accept</x:ref> 2945 (<xref target="header.accept"/>), <x:ref>Accept-Charset</x:ref> 2946 (<xref target="header.accept-charset"/>), <x:ref>Accept-Encoding</x:ref> 2947 (<xref target="header.accept-encoding"/>), <x:ref>Accept-Language</x:ref> 2948 (<xref target="header.accept-language"/>), and <x:ref>User-Agent</x:ref> 2949 (&header-user-agent;). 2936 2950 However, an origin server is not limited to these dimensions and &MAY; vary 2937 2951 the response based on any aspect of the request, including aspects … … 2941 2955 <x:note> 2942 2956 <t> 2943 &Note; In practice, User-Agentbased negotiation is fragile,2957 &Note; In practice, <x:ref>User-Agent</x:ref> based negotiation is fragile, 2944 2958 because new clients might not be recognized. 2945 2959 </t> … … 3349 3363 have been applied to the representation beyond those inherent in the media 3350 3364 type, and thus what decoding mechanisms have to be applied in order to obtain 3351 the media-type referenced by the Content-Typeheader field.3365 the media-type referenced by the <x:ref>Content-Type</x:ref> header field. 3352 3366 Content-Encoding is primarily used to allow a representation to be 3353 3367 compressed without losing the identity of its underlying media type. … … 3378 3392 representation. Likewise, an origin server might choose to publish the 3379 3393 same payload data as multiple representations that differ only in whether 3380 the coding is defined as part of Content-Type or Content-Encoding, since3381 some user agents will behave differently in their handling of each3382 response (e.g., open a "Save as ..." dialog instead of automatic3383 decompression and rendering of content).3394 the coding is defined as part of <x:ref>Content-Type</x:ref> or 3395 Content-Encoding, since some user agents will behave differently in their 3396 handling of each response (e.g., open a "Save as ..." dialog instead of 3397 automatic decompression and rendering of content). 3384 3398 </t> 3385 3399 <t> … … 3780 3794 <x:note> 3781 3795 <t> 3782 &Note; The Content-Location header field (&header-content-location;) differs3783 from Location in that the Content-Location identifies the most specific3784 resource corresponding to the enclosed representation.3785 It is therefore possible for a response to contain header fields for3786 both Location and Content-Location.3796 &Note; The <x:ref>Content-Location</x:ref> header field 3797 (&header-content-location;) differs from Location in that the 3798 Content-Location identifies the most specific resource corresponding to the 3799 enclosed representation. It is therefore possible for a response to contain 3800 header fields for both Location and Content-Location. 3787 3801 </t> 3788 3802 </x:note> … … 4424 4438 </c> 4425 4439 <c>identity</c> 4426 <c>reserved (synonym for "no encoding" in Accept-Encoding header field)</c> 4440 <c>reserved (synonym for "no encoding" in <x:ref>Accept-Encoding</x:ref> 4441 header field)</c> 4427 4442 <c> 4428 4443 <xref target="header.accept-encoding"/> … … 4450 4465 applications &SHOULD; supply as much control over this information as 4451 4466 possible to the provider of that information. Four header fields are 4452 worth special mention in this context: Server, Via, Referer and From. 4467 worth special mention in this context: <x:ref>Server</x:ref>, 4468 <x:ref>Via</x:ref>, <x:ref>Referer</x:ref> and <x:ref>From</x:ref>. 4453 4469 </t> 4454 4470 <t> … … 4456 4472 server machine to become more vulnerable to attacks against software 4457 4473 that is known to contain security holes. Implementors &SHOULD; make the 4458 Serverheader field a configurable option.4474 <x:ref>Server</x:ref> header field a configurable option. 4459 4475 </t> 4460 4476 <t> … … 4466 4482 </t> 4467 4483 <t> 4468 The Referer header field allows reading patterns to be studied and reverse4469 links drawn. Although it can be very useful, its power can be abused4470 if user details are not separated from the information contained in4471 the Referer. Even when the personal information has been removed, the4472 Referer header field might indicate a private document's URI whose4473 publication would be inappropriate.4474 </t> 4475 <t> 4476 The information sent in the From field might conflict with the user's4477 privacy interests or their site's security policy, and hence it4484 The <x:ref>Referer</x:ref> header field allows reading patterns to be 4485 studied and reverse links drawn. Although it can be very useful, its power 4486 can be abused if user details are not separated from the information 4487 contained in the Referer. Even when the personal information has been 4488 removed, the Referer header field might indicate a private document's URI 4489 whose publication would be inappropriate. 4490 </t> 4491 <t> 4492 The information sent in the <x:ref>From</x:ref> field might conflict with 4493 the user's privacy interests or their site's security policy, and hence it 4478 4494 &SHOULD-NOT; be transmitted without the user being able to disable, 4479 4495 enable, and modify the contents of the field. The user &MUST; be able … … 4483 4499 <t> 4484 4500 We suggest, though do not require, that a convenient toggle interface 4485 be provided for the user to enable or disable the sending of From and 4486 Referer information. 4487 </t> 4488 <t> 4489 The User-Agent (<xref target="header.user-agent"/>) or Server (<xref 4490 target="header.server"/>) header fields can sometimes be used to determine 4491 that a specific client or server has a particular security hole which might 4492 be exploited. Unfortunately, this same information is often used for other 4493 valuable purposes for which HTTP currently has no better mechanism. 4494 </t> 4495 <t> 4496 Furthermore, the User-Agent header field might contain enough entropy to be 4497 used, possibly in conjunction with other material, to uniquely identify the 4498 user. 4501 be provided for the user to enable or disable the sending of 4502 <x:ref>From</x:ref> and <x:ref>Referer</x:ref> information. 4503 </t> 4504 <t> 4505 The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or 4506 <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields can 4507 sometimes be used to determine that a specific client or server has a 4508 particular security hole which might be exploited. Unfortunately, this same 4509 information is often used for other valuable purposes for which HTTP 4510 currently has no better mechanism. 4511 </t> 4512 <t> 4513 Furthermore, the <x:ref>User-Agent</x:ref> header field might contain enough 4514 entropy to be used, possibly in conjunction with other material, to uniquely 4515 identify the user. 4499 4516 </t> 4500 4517 <t> … … 4512 4529 reveal an otherwise private information source, it is strongly 4513 4530 recommended that the user be able to select whether or not the 4514 Referer field is sent. For example, a browser client could have a4515 toggle switch for browsing openly/anonymously, which would4531 <x:ref>Referer</x:ref> field is sent. For example, a browser client could 4532 have a toggle switch for browsing openly/anonymously, which would 4516 4533 respectively enable/disable the sending of Referer and From 4517 4534 information. 4518 4535 </t> 4519 4536 <t> 4520 Clients &SHOULD-NOT; include a Referer header field in a (non-secure)4521 HTTP request if the referring page was transferred with a secure4537 Clients &SHOULD-NOT; include a <x:ref>Referer</x:ref> header field in a 4538 (non-secure) HTTP request if the referring page was transferred with a secure 4522 4539 protocol. 4523 4540 </t> … … 4534 4551 <t> 4535 4552 If a single server supports multiple organizations that do not trust 4536 one another, then it &MUST; check the values of Location and Content-Location4537 header fields in responses that are generated under control of4538 said organizations to make sure that they do not attempt to4539 invalidate resources over which they have no authority.4553 one another, then it &MUST; check the values of <x:ref>Location</x:ref> and 4554 <x:ref>Content-Location</x:ref> header fields in responses that are 4555 generated under control of said organizations to make sure that they do not 4556 attempt to invalidate resources over which they have no authority. 4540 4557 </t> 4541 4558 <t> 4542 4559 Furthermore, appending the fragment identifier from one URI to another 4543 one obtained from a Location header field might leak confidential4544 information to the target server — although the fragment identifier is4545 not transmitted in the final request, it might be visible to the user agent4546 th rough other means, such as scripting.4560 one obtained from a <x:ref>Location</x:ref> header field might leak 4561 confidential information to the target server — although the fragment 4562 identifier is not transmitted in the final request, it might be visible to 4563 the user agent through other means, such as scripting. 4547 4564 </t> 4548 4565 </section> … … 4561 4578 <t> 4562 4579 Accept header fields can reveal information about the user to all 4563 servers which are accessed. The Accept-Language header field in particular4564 can reveal information the user would consider to be of a private4565 nature, because the understanding of particular languages is often4580 servers which are accessed. The <x:ref>Accept-Language</x:ref> header field 4581 in particular can reveal information the user would consider to be of a 4582 private nature, because the understanding of particular languages is often 4566 4583 strongly correlated to the membership of a particular ethnic group. 4567 4584 User agents which offer the option to configure the contents of an … … 4627 4644 </front> 4628 4645 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> 4629 <x:source href="p1-messaging.xml" basename="p1-messaging"/> 4646 <x:source href="p1-messaging.xml" basename="p1-messaging"> 4647 <x:defines>Content-Length</x:defines> 4648 <x:defines>Transfer-Encoding</x:defines> 4649 <x:defines>Via</x:defines> 4650 </x:source> 4630 4651 </reference> 4631 4652 … … 5361 5382 environment &SHOULD; translate all line breaks within the text media 5362 5383 types described in <xref target="canonicalization.and.text.defaults"/> 5363 of this document to the RFC 2049 5364 canonical form of CRLF. Note, however, that this might be complicated 5365 by the presence of a Content-Encoding and by the fact that HTTP 5366 allows the use of some character encodings which do not use octets 13 and 5367 10 to represent CR and LF, respectively, as is the case for some multi-byte 5368 character encodings. 5384 of this document to the RFC 2049 canonical form of CRLF. Note, however, that 5385 this might be complicated by the presence of a <x:ref>Content-Encoding</x:ref> 5386 and by the fact that HTTP allows the use of some character encodings which do 5387 not use octets 13 and 10 to represent CR and LF, respectively, as is the case 5388 for some multi-byte character encodings. 5369 5389 </t> 5370 5390 <t> … … 5381 5401 HTTP/1.1 uses a restricted set of date formats (&http-date;) to 5382 5402 simplify the process of date comparison. Proxies and gateways from 5383 other protocols &SHOULD; ensure that any Date header field present in a5384 message conforms to one of the HTTP/1.1 formats and rewrite the date5385 if necessary.5403 other protocols &SHOULD; ensure that any <x:ref>Date</x:ref> header field 5404 present in a message conforms to one of the HTTP/1.1 formats and rewrite 5405 the date if necessary. 5386 5406 </t> 5387 5407 </section> … … 5390 5410 <t> 5391 5411 MIME does not include any concept equivalent to HTTP/1.1's 5392 Content-Encoding header field. Since this acts as a modifier on the5393 media type, proxies and gateways from HTTP to MIME-compliant5394 protocols &MUST; either change the value of the Content-Type header5395 field or decode the representation before forwarding the message. (Some5396 experimental applications of Content-Type for Internet mail have used5412 <x:ref>Content-Encoding</x:ref> header field. Since this acts as a modifier 5413 on the media type, proxies and gateways from HTTP to MIME-compliant 5414 protocols &MUST; either change the value of the <x:ref>Content-Type</x:ref> 5415 header field or decode the representation before forwarding the message. 5416 (Some experimental applications of Content-Type for Internet mail have used 5397 5417 a media-type parameter of ";conversions=<content-coding>" to perform 5398 5418 a function equivalent to Content-Encoding. However, this parameter is … … 5503 5523 Deprecate <x:ref>305 (Use Proxy)</x:ref> status code, because user agents did 5504 5524 not implement it. It used to indicate that the target resource needs to be 5505 accessed through the proxy given by the Location field. The Location field5506 gave the URI of the proxy. The recipient was expected to repeat this single5507 re quest via the proxy.5525 accessed through the proxy given by the <x:ref>Location</x:ref> field. The 5526 Location field gave the URI of the proxy. The recipient was expected to 5527 repeat this single request via the proxy. 5508 5528 (<xref target="status.305"/>) 5509 5529 </t> … … 5518 5538 </t> 5519 5539 <t> 5520 Reclassify " Allow" as response header field, removing the option to5521 specify it in a PUT request.5540 Reclassify "<x:ref>Allow</x:ref>" as response header field, removing the 5541 option to specify it in a PUT request. 5522 5542 Relax the server requirement on the contents of the Allow header field and 5523 5543 remove requirement on clients to always trust the header field value. … … 5525 5545 </t> 5526 5546 <t> 5527 The ABNF for the Expect header field has been both fixed (allowing parameters 5528 for value-less expectations as well) and simplified (allowing trailing 5529 semicolons after "100-continue" when they were invalid before). 5547 The ABNF for the <x:ref>Expect</x:ref> header field has been both fixed 5548 (allowing parameters for value-less expectations as well) and simplified 5549 (allowing trailing semicolons after "100-continue" when they were invalid 5550 before). 5530 5551 (<xref target="header.expect"/>) 5531 5552 </t> 5532 5553 <t> 5533 Correct syntax of Location header field to allow URI references (including5534 re lative references and fragments), as referred symbol "absoluteURI" wasn't5535 what was expected, and add some clarifications as to when use of fragments5536 w ould not be appropriate.5554 Correct syntax of <x:ref>Location</x:ref> header field to allow URI 5555 references (including relative references and fragments), as referred symbol 5556 "absoluteURI" wasn't what was expected, and add some clarifications as to 5557 when use of fragments would not be appropriate. 5537 5558 (<xref target="header.location"/>) 5538 5559 </t> 5539 5560 <t> 5540 Restrict Max-Forwards header field to OPTIONS and TRACE (previously,5541 extension methods could have used it as well).5561 Restrict <x:ref>Max-Forwards</x:ref> header field to OPTIONS and TRACE 5562 (previously, extension methods could have used it as well). 5542 5563 (<xref target="header.max-forwards"/>) 5543 5564 </t> 5544 5565 <t> 5545 Allow Referer field value of "about:blank" as alternative to not specifying it. 5566 Allow <x:ref>Referer</x:ref> field value of "about:blank" as alternative to 5567 not specifying it. 5546 5568 (<xref target="header.referer"/>) 5547 5569 </t> 5548 5570 <t> 5549 In the description of the Server header field, the Via field 5550 was described as a SHOULD. The requirement was and is stated 5551 correctly in the description of the Via header field in &header-via;. 5571 In the description of the <x:ref>Server</x:ref> header field, the 5572 <x:ref>Via</x:ref> field was described as a SHOULD. The requirement was and 5573 is stated correctly in the description of the Via header field in 5574 &header-via;. 5552 5575 (<xref target="header.server"/>) 5553 5576 </t> … … 5576 5599 </t> 5577 5600 <t> 5578 Remove ISO-8859-1 special-casing in Accept-Charset.5601 Remove ISO-8859-1 special-casing in <x:ref>Accept-Charset</x:ref>. 5579 5602 (<xref target="header.accept-charset"/>) 5580 5603 </t> 5581 5604 <t> 5582 Remove base URI setting semantics for Content-Location due to poor5583 implementation support, which was caused by too many broken servers emitting5605 Remove base URI setting semantics for <x:ref>Content-Location</x:ref> due to 5606 poor implementation support, which was caused by too many broken servers emitting 5584 5607 bogus Content-Location header fields, and also the potentially undesirable effect 5585 5608 of potentially breaking relative links in content-negotiated resources. -
draft-ietf-httpbis/latest/p4-conditional.html
r1739 r1740 661 661 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 662 662 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 663 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type664 of error recoverycould lead to dangerous consequences.663 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 664 could lead to dangerous consequences. 665 665 </p> 666 666 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 691 691 </p> 692 692 <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such 693 that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., 694 Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate 695 the stored responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same 693 that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. 694 </p> 695 <p id="rfc.section.2.1.p.3">A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored 696 responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same 696 697 validator unless their payload body would be identical. 697 698 </p> 698 <p id="rfc.section.2.1.p. 3">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate699 <p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate 699 700 an entry using a validator that it obtained in the distant past. A strong validator <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource over time. However, there is no 700 701 implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for 701 702 representations of multiple resources at the same time and does not imply that those representations are equivalent). 702 703 </p> 703 <p id="rfc.section.2.1.p. 4">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change704 <p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change 704 705 to a representation always results in a unique node name and revision identifier being assigned before the representation 705 706 is made accessible to GET. A cryptographic hash function applied to the representation data is also sufficient if the data … … 708 709 occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior. 709 710 </p> 710 <p id="rfc.section.2.1.p. 5">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation711 <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation 711 712 data. This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to 712 713 ensure uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations … … 714 715 In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses. 715 716 </p> 716 <p id="rfc.section.2.1.p. 6">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might717 <p id="rfc.section.2.1.p.7">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might 717 718 be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in 718 719 order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server … … 721 722 those modifications. 722 723 </p> 723 <p id="rfc.section.2.1.p. 7">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when724 <p id="rfc.section.2.1.p.8">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when 724 725 a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of a representation's 725 726 payload body. Strong validators are usable and preferred for all conditional requests, including cache validation, partial … … 745 746 use its value to make conditional requests and test the validity of locally cached responses. 746 747 </p> 747 <p id="rfc.section.2.2.1.p.3">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date field-value 748 for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially 749 if the representation changes near the time that the response is generated. 750 </p> 751 <p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (Date). If the last modification time 752 is derived from implementation-specific metadata that evaluates to some time in the future, according to the origin server's 753 clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact 748 <p id="rfc.section.2.2.1.p.3">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the <a href="p2-semantics.html#header.date" class="smpl">Date</a> field value for its response. This allows a recipient to make an accurate assessment of the representation's modification 749 time, especially if the representation changes near the time that the response is generated. 750 </p> 751 <p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (<a href="p2-semantics.html#header.date" class="smpl">Date</a>). If the last modification time is derived from implementation-specific metadata that evaluates to some time in the future, 752 according to the origin server's clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact 754 753 on cache validation. 755 754 </p> … … 771 770 <li>The validator is about to be used by a client in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field, because the client has a cache entry, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> for the associated representation, and 772 771 </li> 773 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> 772 <li>That cache entry includes a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and 773 </li> 774 774 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> 775 775 </ul> … … 779 779 and 780 780 </li> 781 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> 781 <li>That cache entry includes a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and 782 </li> 782 783 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> 783 784 </ul> 784 785 <p id="rfc.section.2.2.2.p.4">This method relies on the fact that if two different responses were sent by the origin server during the same second, but 785 both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified 786 time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from 787 different clocks, or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short. 786 both had the same Last-Modified time, then at least one of those responses would have a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified 787 values are generated from different clocks, or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short. 788 788 </p> 789 789 <div id="rfc.iref.e.1"></div> … … 883 883 </div> 884 884 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 885 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encodingrequest header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>):885 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>): 886 886 </p> 887 887 <div id="rfc.figure.u.6"></div> … … 1091 1091 as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields. 1092 1092 </p> 1093 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, Content-Location, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 1093 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 1094 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 1094 1095 </p> 1095 1096 <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, -
draft-ietf-httpbis/latest/p4-conditional.xml
r1739 r1740 197 197 impact on security. This is because different uses of the protocol require 198 198 different error handling strategies; for example, a Web browser might wish to 199 transparently recover from a response where the Location header field 200 doesn't parse according to the ABNF, whereby in a systems control protocol 201 using HTTP, this type of error recovery could lead to dangerous consequences. 199 transparently recover from a response where the <x:ref>Location</x:ref> 200 header field doesn't parse according to the ABNF, whereby in a systems 201 control protocol using HTTP, this type of error recovery could lead to 202 dangerous consequences. 202 203 </t> 203 204 </section> … … 273 274 a change occurs to the representation data such that a change would be 274 275 observable in the payload body of a <x:ref>200 (OK)</x:ref> response to GET. 276 </t> 277 <t> 275 278 A strong validator &MAY; be changed for other reasons, such as when a semantically 276 279 significant part of the representation metadata is changed (e.g., 277 Content-Type), but it is in the best interests of the origin server to only278 change the value when it is necessary to invalidate the stored responses279 held by remote caches and authoring tools. A strong validator &MUST; be280 unique across all representations of a given resource, such that no two281 representations of that resource share the same validator unless282 their payload body would be identical.280 <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin 281 server to only change the value when it is necessary to invalidate the 282 stored responses held by remote caches and authoring tools. A strong 283 validator &MUST; be unique across all representations of a given resource, 284 such that no two representations of that resource share the same validator 285 unless their payload body would be identical. 283 286 </t> 284 287 <t> … … 384 387 <t> 385 388 An origin server &SHOULD; obtain the Last-Modified value of the 386 representation as close as possible to the time that it generates 387 the Date field-value for its response. This allows a recipient to389 representation as close as possible to the time that it generates the 390 <x:ref>Date</x:ref> field value for its response. This allows a recipient to 388 391 make an accurate assessment of the representation's modification time, 389 392 especially if the representation changes near the time that the … … 392 395 <t> 393 396 An origin server with a clock &MUST-NOT; send a Last-Modified date 394 that is later than the server's time of message origination ( Date).397 that is later than the server's time of message origination (<x:ref>Date</x:ref>). 395 398 If the last modification time is derived from implementation-specific 396 399 metadata that evaluates to some time in the future, according to the … … 426 429 a cache entry, or <x:ref>If-Range</x:ref> for the associated 427 430 representation, and</t> 428 <t>That cache entry includes a Date value, which gives the time429 when the origin server sent the original response, and</t>431 <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the 432 time when the origin server sent the original response, and</t> 430 433 <t>The presented Last-Modified time is at least 60 seconds before 431 434 the Date value.</t> … … 437 440 <t>The validator is being compared by an intermediate cache to the 438 441 validator stored in its cache entry for the representation, and</t> 439 <t>That cache entry includes a Date value, which gives the time440 when the origin server sent the original response, and</t>442 <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the 443 time when the origin server sent the original response, and</t> 441 444 <t>The presented Last-Modified time is at least 60 seconds before 442 445 the Date value.</t> … … 447 450 sent by the origin server during the same second, but both had the 448 451 same Last-Modified time, then at least one of those responses would 449 have a Date value equal to its Last-Modified time. The arbitrary 60-second450 limit guards against the possibility that the Date and Last-Modified451 values are generated from different clocks, or at somewhat452 have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The 453 arbitrary 60-second limit guards against the possibility that the Date and 454 Last-Modified values are generated from different clocks, or at somewhat 452 455 different times during the preparation of the response. An 453 456 implementation &MAY; use a value larger than 60 seconds, if it is … … 597 600 Consider a resource that is subject to content negotiation (&content-negotiation;), 598 601 and where the representations returned upon a GET request vary based on 599 the Accept-Encoding request header field (&header-accept-encoding;): 602 the <x:ref>Accept-Encoding</x:ref> request header field 603 (&header-accept-encoding;): 600 604 </t> 601 605 <figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 1015 1019 </t> 1016 1020 <t> 1017 A 304 response &MUST; include a Date header field (&header-date;)1018 unless the origin server does not have a clock that can provide a1019 reasonable approximation of the current time. If a <x:ref>200 (OK)</x:ref>1020 response to the same request would have included any of the header fields1021 <x:ref>Cache-Control</x:ref>, Content-Location, <x:ref>ETag</x:ref>,1022 <x:ref>E xpires</x:ref>, or <x:ref>Vary</x:ref>, then those same header1023 fields &MUST; be sent in a 304 response.1021 A 304 response &MUST; include a <x:ref>Date</x:ref> header field 1022 (&header-date;) unless the origin server does not have a clock that can 1023 provide a reasonable approximation of the current time. If a <x:ref>200 1024 (OK)</x:ref> response to the same request would have included any of the 1025 header fields <x:ref>Cache-Control</x:ref>, <x:ref>Content-Location</x:ref>, 1026 <x:ref>ETag</x:ref>, <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then 1027 those same header fields &MUST; be sent in a 304 response. 1024 1028 </t> 1025 1029 <t> … … 1208 1212 <x:defines>2xx (Successful)</x:defines> 1209 1213 <x:defines>200 (OK)</x:defines> 1214 <x:defines>Accept-Encoding</x:defines> 1215 <x:defines>Content-Location</x:defines> 1216 <x:defines>Content-Type</x:defines> 1217 <x:defines>Date</x:defines> 1218 <x:defines>Location</x:defines> 1210 1219 </x:source> 1211 1220 </reference> -
draft-ietf-httpbis/latest/p5-range.html
r1739 r1740 683 683 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 684 684 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 685 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type686 of error recoverycould lead to dangerous consequences.685 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 686 could lead to dangerous consequences. 687 687 </p> 688 688 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 738 738 </p> 739 739 <ul> 740 <li>Either a <a href="#header.content-range" class="smpl">Content-Range</a> header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section 5.2</a>) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields 741 for each part. If a Content-Length header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of octets transmitted in the message body. 740 <li>Either a <a href="#header.content-range" class="smpl">Content-Range</a> header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section 5.2</a>) indicating the range included with this response, or a multipart/byteranges <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> including Content-Range fields for each part. If a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of octets transmitted in the message body. 742 741 </li> 743 742 <li>Date</li> 744 <li> <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, Content-Locationand/or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request743 <li> <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> and/or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request 745 744 </li> 746 745 </ul> … … 1191 1190 </p> 1192 1191 </div> 1193 <p id="rfc.section.A.p.3">The multipart/byteranges media type includes one or more parts, each with its own Content-Typeand <a href="#header.content-range" class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body-part.1192 <p id="rfc.section.A.p.3">The multipart/byteranges media type includes one or more parts, each with its own <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-range" class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body-part. 1194 1193 </p> 1195 1194 <p id="rfc.section.A.p.4"> </p> -
draft-ietf-httpbis/latest/p5-range.xml
r1739 r1740 187 187 impact on security. This is because different uses of the protocol require 188 188 different error handling strategies; for example, a Web browser might wish to 189 transparently recover from a response where the Location header field 190 doesn't parse according to the ABNF, whereby in a systems control protocol 191 using HTTP, this type of error recovery could lead to dangerous consequences. 189 transparently recover from a response where the <x:ref>Location</x:ref> 190 header field doesn't parse according to the ABNF, whereby in a systems 191 control protocol using HTTP, this type of error recovery could lead to 192 dangerous consequences. 192 193 </t> 193 194 </section> … … 329 330 (<xref target="header.content-range"/>) indicating 330 331 the range included with this response, or a multipart/byteranges 331 Content-Type including Content-Range fields for each part. If a332 Content-Length header field is present in the response, its333 value &MUST; match the actual number of octets transmitted in the334 message body.332 <x:ref>Content-Type</x:ref> including Content-Range fields for each 333 part. If a <x:ref>Content-Length</x:ref> header field is present in the 334 response, its value &MUST; match the actual number of octets 335 transmitted in the message body. 335 336 </t> 336 337 <t> … … 339 340 <t> 340 341 <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>, 341 <x:ref>Expires</x:ref>, Content-Locationand/or342 <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref> and/or 342 343 <x:ref>Vary</x:ref>, if the header field would have been sent in a 343 344 <x:ref>200 (OK)</x:ref> response to the same request … … 1008 1009 </front> 1009 1010 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> 1010 <x:source href="p1-messaging.xml" basename="p1-messaging"/> 1011 <x:source href="p1-messaging.xml" basename="p1-messaging"> 1012 <x:defines>Content-Length</x:defines> 1013 </x:source> 1011 1014 </reference> 1012 1015 … … 1032 1035 <x:defines>200 (OK)</x:defines> 1033 1036 <x:defines>410 (Gone)</x:defines> 1037 <x:defines>Content-Location</x:defines> 1038 <x:defines>Content-Type</x:defines> 1039 <x:defines>Location</x:defines> 1034 1040 </x:source> 1035 1041 </reference> … … 1260 1266 <t> 1261 1267 The multipart/byteranges media type includes one or more parts, each 1262 with its own Content-Type and <x:ref>Content-Range</x:ref> fields. The1263 required boundary parameter specifies the boundary string used to separate1264 each body-part.1268 with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref> 1269 fields. The required boundary parameter specifies the boundary string used 1270 to separate each body-part. 1265 1271 </t> 1266 1272 <t> -
draft-ietf-httpbis/latest/p6-cache.html
r1739 r1740 794 794 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 795 795 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 796 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type797 of error recoverycould lead to dangerous consequences.796 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 797 could lead to dangerous consequences. 798 798 </p> 799 799 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 913 913 <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.6</a>. 914 914 </p> 915 <p id="rfc.section.2.2.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field). It can also forward a request with "Cache-Control:916 max-age=0" or "Cache-Control: no-cache" to disambiguatewhich response to use.915 <p id="rfc.section.2.2.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field). It can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate 916 which response to use. 917 917 </p> 918 918 <p id="rfc.section.2.2.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard. … … 951 951 <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) is present, use its value, or 952 952 </li> 953 <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 3.3</a>) is present, use its value minus the value of the Dateresponse header field, or953 <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 3.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or 954 954 </li> 955 955 <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a>. … … 993 993 </p> 994 994 <ul class="empty"> 995 <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the 996 response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic 997 operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 995 <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value" 996 denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 998 997 </li> 999 998 </ul> … … 1138 1137 to keep their contents up-to-date. 1139 1138 </p> 1140 <p id="rfc.section.2.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error response 1141 to a request with an unsafe method is received. 1142 </p> 1143 <p id="rfc.section.2.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host 1144 part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1139 <p id="rfc.section.2.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received. 1140 </p> 1141 <p id="rfc.section.2.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1145 1142 </p> 1146 1143 <p id="rfc.section.2.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown. … … 1184 1181 </p> 1185 1182 <p id="rfc.section.2.8.p.5">The stored response with matching selecting header fields is known as the selected response.</p> 1186 <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the Dateheader field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 2.2</a>.1183 <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section 2.2</a>. 1187 1184 </p> 1188 1185 <p id="rfc.section.2.8.p.7">If no selected response is available, the cache can forward the presented request to the origin server in a conditional request; … … 1305 1302 <div id="rfc.iref.n.3"></div> 1306 1303 <h4 id="rfc.section.3.2.1.6"><a href="#rfc.section.3.2.1.6">3.2.1.6</a> <a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4> 1307 <p id="rfc.section.3.2.1.6.p.1">The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Typerequest header fields, nor the request representation.1304 <p id="rfc.section.3.2.1.6.p.1">The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> request header fields, nor the request representation. 1308 1305 </p> 1309 1306 <div id="rfc.iref.c.13"></div> … … 1421 1418 <div id="rfc.iref.n.6"></div> 1422 1419 <h4 id="rfc.section.3.2.2.9"><a href="#rfc.section.3.2.2.9">3.2.2.9</a> <a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4> 1423 <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Typeresponse header fields, nor the response representation.1420 <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> response header fields, nor the response representation. 1424 1421 </p> 1425 1422 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3> … … 1592 1589 </ul> 1593 1590 <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning header fields to a receiver whose version is HTTP/1.0 or lower, 1594 then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header field in the message. 1595 </p> 1596 <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date 1597 value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning 1591 then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message. 1592 </p> 1593 <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the <a href="p2-semantics.html#header.date" class="smpl">Date</a> value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning 1598 1594 header fields.) If all of the warning-values are deleted for this reason, the Warning header field <em class="bcp14">MUST</em> be deleted as well. 1599 1595 </p> … … 1970 1966 <p id="rfc.section.A.p.1">Make the specified age calculation algorithm less conservative. (<a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>) 1971 1967 </p> 1972 <p id="rfc.section.A.p.2">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to 1973 use. (<a href="#validation.model" title="Validation Model">Section 2.4</a>) 1968 <p id="rfc.section.A.p.2">Remove requirement to consider <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> in successful responses in order to determine the appropriate response to use. (<a href="#validation.model" title="Validation Model">Section 2.4</a>) 1974 1969 </p> 1975 1970 <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.6</a>) -
draft-ietf-httpbis/latest/p6-cache.xml
r1739 r1740 332 332 impact on security. This is because different uses of the protocol require 333 333 different error handling strategies; for example, a Web browser might wish to 334 transparently recover from a response where the Location header field 335 doesn't parse according to the ABNF, whereby in a systems control protocol 336 using HTTP, this type of error recovery could lead to dangerous consequences. 334 transparently recover from a response where the <x:ref>Location</x:ref> 335 header field doesn't parse according to the ABNF, whereby in a systems 336 control protocol using HTTP, this type of error recovery could lead to 337 dangerous consequences. 337 338 </t> 338 339 </section> … … 580 581 <t> 581 582 When more than one suitable response is stored, a cache &MUST; use the 582 most recent response (as determined by the Date header field). It can also583 f orward a request with "Cache-Control: max-age=0" or "Cache-Control:584 no-cache" to disambiguate which response to use.583 most recent response (as determined by the <x:ref>Date</x:ref> header 584 field). It can also forward a request with "Cache-Control: max-age=0" or 585 "Cache-Control: no-cache" to disambiguate which response to use. 585 586 </t> 586 587 <t> … … 662 663 <t>If the <x:ref>Expires</x:ref> response header field 663 664 (<xref target="header.expires" />) is present, use its value minus the 664 value of the Dateresponse header field, or</t>665 value of the <x:ref>Date</x:ref> response header field, or</t> 665 666 <t>Otherwise, no explicit expiration time is present in the response. A 666 667 heuristic freshness lifetime might be applicable; see <xref … … 742 743 <list> 743 744 <t> 744 HTTP/1.1 requires origin servers to send a Date header field, if possible,745 with every response, giving the time at which the response was746 generated. The term "date_value" denotes the value of the Date747 header field, in a form appropriate for arithmetic operations. See745 HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header 746 field, if possible, with every response, giving the time at which the 747 response was generated. The term "date_value" denotes the value of the 748 Date header field, in a form appropriate for arithmetic operations. See 748 749 &header-date; for the definition of the Date header field, and for 749 750 requirements regarding responses without it. … … 1022 1023 <t> 1023 1024 A cache &MUST; invalidate the effective Request URI 1024 (&effective-request-uri;) as well as the URI(s) in the Location1025 and Content-Location response header fields (if present) when a non-error1026 response to a request with an unsafe method is received.1027 </t> 1028 <t> 1029 However, a cache &MUST-NOT; invalidate a URI from a Location or1030 Content-Location response header field if the host part of that URI differs1031 from the host part in the effective request URI (&effective-request-uri;).1032 This helps prevent denial of service attacks.1025 (&effective-request-uri;) as well as the URI(s) in the <x:ref>Location</x:ref> 1026 and <x:ref>Content-Location</x:ref> response header fields (if present) when 1027 a non-error response to a request with an unsafe method is received. 1028 </t> 1029 <t> 1030 However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref> 1031 or <x:ref>Content-Location</x:ref> response header field if the host part of 1032 that URI differs from the host part in the effective request URI 1033 (&effective-request-uri;). This helps prevent denial of service attacks. 1033 1034 </t> 1034 1035 <t> … … 1122 1123 <t> 1123 1124 If multiple selected responses are available, the most recent response 1124 (as determined by the Dateheader field) is used; see <xref1125 (as determined by the <x:ref>Date</x:ref> header field) is used; see <xref 1125 1126 target="constructing.responses.from.caches"/>. 1126 1127 </t> … … 1360 1361 The no-transform request directive indicates that an intermediary 1361 1362 (whether or not it implements a cache) &MUST-NOT; change the 1362 Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type request 1363 header fields, nor the request representation. 1363 <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or 1364 <x:ref>Content-Type</x:ref> request header fields, nor the request 1365 representation. 1364 1366 </t> 1365 1367 </section> … … 1589 1591 The no-transform response directive indicates that an intermediary 1590 1592 (regardless of whether it implements a cache) &MUST-NOT; change the 1591 Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type response 1592 header fields, nor the response representation. 1593 <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or 1594 <x:ref>Content-Type</x:ref> response header fields, nor the response 1595 representation. 1593 1596 </t> 1594 1597 </section> … … 1912 1915 If an implementation sends a message with one or more Warning header fields to a 1913 1916 receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include 1914 in each warning-value a warn-date that matches the Date header field in the1915 message.1917 in each warning-value a warn-date that matches the <x:ref>Date</x:ref> header 1918 field in the message. 1916 1919 </t> 1917 1920 <t> 1918 1921 If a system receives a message with a warning-value that includes 1919 a warn-date, and that warn-date is different from the Date value in the1920 response, then that warning-value &MUST; be deleted from the message before1921 storing, forwarding, or using it. (preventing the consequences of naive1922 caching of Warning header fields.) If all of the warning-values are deleted1923 for this reason, the Warning header field &MUST; be deleted as well.1922 a warn-date, and that warn-date is different from the <x:ref>Date</x:ref> 1923 value in the response, then that warning-value &MUST; be deleted from the 1924 message before storing, forwarding, or using it. (preventing the consequences 1925 of naive caching of Warning header fields.) If all of the warning-values are 1926 deleted for this reason, the Warning header field &MUST; be deleted as well. 1924 1927 </t> 1925 1928 <t> … … 2309 2312 <x:defines>5xx (Server Error)</x:defines> 2310 2313 <x:defines>504 (Gateway Timeout)</x:defines> 2314 <x:defines>Content-Encoding</x:defines> 2315 <x:defines>Content-Location</x:defines> 2316 <x:defines>Content-Type</x:defines> 2317 <x:defines>Date</x:defines> 2318 <x:defines>Location</x:defines> 2311 2319 </x:source> 2312 2320 </reference> … … 2532 2540 </t> 2533 2541 <t> 2534 Remove requirement to consider Content-Location in successful responses2535 in order to determine the appropriate response to use.2542 Remove requirement to consider <x:ref>Content-Location</x:ref> in successful 2543 responses in order to determine the appropriate response to use. 2536 2544 (<xref target="validation.model" />) 2537 2545 </t> -
draft-ietf-httpbis/latest/p7-auth.html
r1736 r1740 648 648 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 649 649 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 650 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type651 of error recoverycould lead to dangerous consequences.650 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 651 could lead to dangerous consequences. 652 652 </p> 653 653 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> … … 683 683 with or without padding, but excluding whitespace (<a href="#RFC4648" id="rfc.xref.RFC4648.1"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>). 684 684 </p> 685 <p id="rfc.section.2.1.p.5">The <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticateheader field containing at least one challenge applicable to the requested resource.686 </p> 687 <p id="rfc.section.2.1.p.6">The <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticateheader field containing at least one challenge applicable to the proxy for the requested resource.685 <p id="rfc.section.2.1.p.5">The <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one challenge applicable to the requested resource. 686 </p> 687 <p id="rfc.section.2.1.p.6">The <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing at least one challenge applicable to the proxy for the requested resource. 688 688 </p> 689 689 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span><span id="rfc.iref.g.4"></span> <a href="#challenge.and.response" class="smpl">challenge</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 690 690 </pre><div class="note" id="rfc.section.2.1.p.8"> 691 <p> <b>Note:</b> User agents will need to take special care in parsing the WWW-Authenticate and Proxy-Authenticate header field values because 692 they can contain more than one challenge, or if more than one of each is provided, since the contents of a challenge can itself 693 contain a comma-separated list of authentication parameters. 691 <p> <b>Note:</b> User agents will need to take special care in parsing the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field values because they can contain more than one challenge, or if more than one of each is provided, since the contents 692 of a challenge can itself contain a comma-separated list of authentication parameters. 694 693 </p> 695 694 </div> … … 701 700 <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an <a href="#header.authorization" class="smpl">Authorization</a> header field with the request. 702 701 </p> 703 <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a Proxy-Authorizationheader field with the request.704 </p> 705 <p id="rfc.section.2.1.p.12">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested,706 based upon a challenge received from the server (possibly at some point in the past). When creating their values, the user707 agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands,708 obtaining credentials from theuser as appropriate.702 <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field with the request. 703 </p> 704 <p id="rfc.section.2.1.p.12">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received 705 from the server (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting 706 the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the 707 user as appropriate. 709 708 </p> 710 709 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span><span id="rfc.iref.g.5"></span> <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 711 710 </pre><p id="rfc.section.2.1.p.14">Upon a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial 712 credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> return a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a WWW-Authenticateheader field containing at least one (possibly new) challenge applicable to the requested resource.711 credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> return a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one (possibly new) challenge applicable to the requested resource. 713 712 </p> 714 713 <p id="rfc.section.2.1.p.15">Likewise, upon a request that requires authentication by proxies that omit credentials or contain invalid or partial credentials, 715 a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticateheader field containing a (possibly new) challenge applicable to the proxy.714 a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing a (possibly new) challenge applicable to the proxy. 716 715 </p> 717 716 <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). … … 721 720 authentication information. However, such additional mechanisms are not defined by this specification. 722 721 </p> 723 <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticateand <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 4.1</a>.722 <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 4.1</a>. 724 723 </p> 725 724 <div id="rfc.iref.p.1"></div> … … 794 793 </li> 795 794 <li> 796 <p>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), 797 and/or proxy authentication (i.e., using Proxy-Authenticate). 795 <p>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>), and/or proxy authentication (i.e., using <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a>). 798 796 </p> 799 797 </li> … … 811 809 <div id="rfc.iref.s.1"></div> 812 810 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="status.401" href="#status.401">401 Unauthorized</a></h2> 813 <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticateheader field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section 4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section 4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been811 <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section 4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section 4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been 814 812 refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has 815 813 already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic … … 819 817 <div id="rfc.iref.s.2"></div> 820 818 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2> 821 <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorizationheader field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 4.3</a>).819 <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> return a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 4.3</a>). 822 820 </p> 823 821 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> … … 854 852 </p> 855 853 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a> 856 </pre><p id="rfc.section.4.2.p.3">Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection, and intermediaries <em class="bcp14">SHOULD NOT</em> forward it to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting them854 </pre><p id="rfc.section.4.2.p.3">Unlike <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>, the Proxy-Authenticate header field applies only to the current connection, and intermediaries <em class="bcp14">SHOULD NOT</em> forward it to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting them 857 855 from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate header 858 856 field. 859 857 </p> 860 <p id="rfc.section.4.2.p.4">Note that the parsing considerations for WWW-Authenticateapply to this header field as well; see <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section 4.4</a> for details.858 <p id="rfc.section.4.2.p.4">Note that the parsing considerations for <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> apply to this header field as well; see <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section 4.4</a> for details. 861 859 </p> 862 860 <div id="rfc.iref.p.3"></div> … … 868 866 </p> 869 867 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a> 870 </pre><p id="rfc.section.4.3.p.3">Unlike <a href="#header.authorization" class="smpl">Authorization</a>, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate 871 field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy 868 </pre><p id="rfc.section.4.3.p.3">Unlike <a href="#header.authorization" class="smpl">Authorization</a>, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy 872 869 that was expecting to receive credentials. A proxy <em class="bcp14">MAY</em> relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively 873 870 authenticate a given request. -
draft-ietf-httpbis/latest/p7-auth.xml
r1736 r1740 173 173 impact on security. This is because different uses of the protocol require 174 174 different error handling strategies; for example, a Web browser might wish to 175 transparently recover from a response where the Location header field 176 doesn't parse according to the ABNF, whereby in a systems control protocol 177 using HTTP, this type of error recovery could lead to dangerous consequences. 175 transparently recover from a response where the <x:ref>Location</x:ref> 176 header field doesn't parse according to the ABNF, whereby in a systems 177 control protocol using HTTP, this type of error recovery could lead to 178 dangerous consequences. 178 179 </t> 179 180 </section> … … 325 326 credentials or contain invalid or partial credentials, a proxy &SHOULD; 326 327 return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses 327 &MUST; include a <x:ref>Proxy-Authenticate header</x:ref>field containing a (possibly328 &MUST; include a <x:ref>Proxy-Authenticate</x:ref> header field containing a (possibly 328 329 new) challenge applicable to the proxy. 329 330 </t> … … 896 897 <x:source basename="p2-semantics" href="p2-semantics.xml"> 897 898 <x:defines>403 (Forbidden)</x:defines> 899 <x:defines>Location</x:defines> 898 900 </x:source> 899 901 </reference>
Note: See TracChangeset
for help on using the changeset viewer.