Changeset 1708
- Timestamp:
- 03/07/12 18:26:11 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1707 r1708 1380 1380 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1381 1381 Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), 204 1382 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length.1382 (No Content), and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.) 1383 1383 </p> 1384 1384 <div id="rfc.iref.t.4"></div> … … 1406 1406 <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. 1407 1407 </p> 1408 <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.9"><cite title="HTTP/1.1, part 2: Message Semantics">[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. 1409 </p> 1410 <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 304 response to a GET request, neither of which includes a message body, to 1411 indicate that the origin server would have applied a transfer coding to the message body if the request had been an unconditional 1412 GET. This indication is not required, however, because any recipient on the response chain (including the origin server) can 1413 remove transfer codings when they are not needed. 1408 <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">[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. 1409 </p> 1410 <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 1411 coding to the message body if the request had been an unconditional GET. This indication is not required, however, because 1412 any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed. 1414 1413 </p> 1415 1414 <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will … … 1431 1430 <div id="rfc.figure.u.36"></div><pre class="text"> Content-Length: 3495 1432 1431 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential 1433 transfer-coding) that would have been sent had the request been a GET. In the case of a 304 (Not Modified) response to a GET 1434 request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would have been 1435 sent in a 200 (OK) response. 1432 transfer-coding) that would have been sent had the request been a GET. In the case of 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.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would 1433 have been sent in a 200 (OK) response. 1436 1434 </p> 1437 1435 <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only … … 1713 1711 </p> 1714 1712 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1715 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.1 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1713 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1716 1714 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1717 1715 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 1755 1753 </p> 1756 1754 <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which 1757 are defined in <a href="#Part2" id="rfc.xref.Part2.1 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order1755 are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order 1758 1756 to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment 1759 1757 identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). … … 1814 1812 </p> 1815 1813 <div id="authority-form"> 1816 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,1814 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example, 1817 1815 </p> 1818 1816 </div> 1819 1817 <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1820 1818 </pre><div id="asterisk-form"> 1821 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1819 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1822 1820 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1823 1821 </p> … … 1974 1972 </p> 1975 1973 </div> 1976 <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 4"><cite title="HTTP/1.1, part 2: Message Semantics">[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>).1974 <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.15"><cite title="HTTP/1.1, part 2: Message Semantics">[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>). 1977 1975 </p> 1978 1976 <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> … … 1980 1978 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1981 1979 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 1982 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.1980 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request. 1983 1981 </p> 1984 1982 <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-1xx) response. … … 2128 2126 <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. 2129 2127 </p> 2130 <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 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2128 <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.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2131 2129 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. 2132 2130 </p> … … 2158 2156 <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> 2159 2157 <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 2160 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.1 7"><cite title="HTTP/1.1, part 2: Message Semantics">[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 understanding2158 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">[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 2161 2159 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. 2162 2160 </p> … … 2171 2169 </p> 2172 2170 <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> 2173 <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) 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.1 8"><cite title="HTTP/1.1, part 2: Message Semantics">[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 willing2171 <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) 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">[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 2174 2172 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2175 2173 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2178 2176 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2179 2177 <ul> 2180 <li>If a client will wait for a 100 (Continue) 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. 19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2181 </li> 2182 <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.2 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.2178 <li>If a client will wait for a 100 (Continue) 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">[Part2]</cite></a>) with the "100-continue" expectation. 2179 </li> 2180 <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">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 2183 2181 </li> 2184 2182 </ul> … … 2224 2222 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2225 2223 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2226 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.2 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2224 1xx 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">[Part2]</cite></a>). 2227 2225 </li> 2228 2226 </ul> … … 2261 2259 </p> 2262 2260 <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 2263 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.2 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2261 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2264 2262 </p> 2265 2263 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched … … 2525 2523 <li>Pointer to specification text</li> 2526 2524 </ul> 2527 <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 3"><cite title="HTTP/1.1, part 2: Message Semantics">[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>.2525 <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.24"><cite title="HTTP/1.1, part 2: Message Semantics">[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>. 2528 2526 </p> 2529 2527 <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. … … 2685 2683 that most implementations will choose substantially higher limits. 2686 2684 </p> 2687 <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 4"><cite title="HTTP/1.1, part 2: Message Semantics">[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.25"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2685 <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.25"><cite title="HTTP/1.1, part 2: Message Semantics">[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">[Part2]</cite></a>). 2688 2686 </p> 2689 2687 <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. … … 2730 2728 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 2731 2729 </h2> 2732 <table> 2730 <table> 2733 2731 <tr> 2734 2732 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> … … 2738 2736 <td class="reference"><b id="Part2">[Part2]</b></td> 2739 2737 <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-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), July 2012. 2738 </td> 2739 </tr> 2740 <tr> 2741 <td class="reference"><b id="Part4">[Part4]</b></td> 2742 <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. 2740 2743 </td> 2741 2744 </tr> … … 3742 3745 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3743 3746 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3744 <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 .1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a>, <a href="#rfc.xref.Part2.18">6.4.3</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.5</a>, <a href="#rfc.xref.Part2.23">7.4</a>, <a href="#rfc.xref.Part2.24">8.6</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3747 <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> 3745 3748 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1</a></li> 3746 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.1 6">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a></li>3747 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.1 3">5.3</a></li>3748 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.1 2">5.3</a></li>3749 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.17">6.3.2.2</a>, <a href="#rfc.xref.Part2.18">6.3.4</a></li> 3750 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3751 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3749 3752 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3750 <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> </li>3751 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.1 5">5.7</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>3752 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.1 8">6.4.3</a></li>3753 <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> 3754 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.16">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li> 3755 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.19">6.4.3</a></li> 3753 3756 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.2">2.3</a></li> 3754 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.2 2">6.5</a></li>3755 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.2 5">8.6</a></li>3756 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.2 4">8.6</a></li>3757 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2. 9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li>3758 <li><em>Section 8</em> <a href="#rfc.xref.Part2.1 0">4.3.1</a></li>3757 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.23">6.5</a></li> 3758 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.26">8.6</a></li> 3759 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.25">8.6</a></li> 3760 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.24">7.4</a></li> 3761 <li><em>Section 8</em> <a href="#rfc.xref.Part2.11">4.3.1</a></li> 3759 3762 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3760 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2. 19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li>3763 <li><em>Section 9.11</em> <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li> 3761 3764 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.1">1</a></li> 3765 </ul> 3766 </li> 3767 <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> 3768 <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> 3762 3769 </ul> 3763 3770 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1707 r1708 40 40 <!ENTITY status-203 "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 41 41 <!ENTITY status-3xx "<xref target='Part2' x:rel='#status.3xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 42 <!ENTITY status-304 "<xref target='Part4' x:rel='#status.304' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 42 43 <!ENTITY status-4xx "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 43 44 <!ENTITY status-414 "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 1483 1484 Successful (2xx) responses to CONNECT switch to tunnel mode instead of 1484 1485 having a message body. 1485 All 1xx (Informational), 204 (No Content), and 304 (Not Modified)1486 All 1xx (Informational), 204 (No Content), and <x:ref>304 (Not Modified)</x:ref> 1486 1487 responses &MUST-NOT; include a message body. 1487 1488 All other responses do include a message body, although the body 1488 &MAY; be of zero length. 1489 &MAY; be of zero length. (See &status-codes; and &status-304;.) 1489 1490 </t> 1490 1491 … … 1551 1552 <t> 1552 1553 Transfer-Encoding &MAY; be sent in a response to a HEAD request or in a 1553 304 response to a GET request, neither of which includes a message body, 1554 <x:ref>304 (Not Modified)</x:ref> response (&status-304;) to a GET request, 1555 neither of which includes a message body, 1554 1556 to indicate that the origin server would have applied a transfer coding 1555 1557 to the message body if the request had been an unconditional GET. … … 1602 1604 the size of the payload body (without any potential transfer-coding) 1603 1605 that would have been sent had the request been a GET. 1604 In the case of a 304 (Not Modified) response to a GET request,1605 Content-Length indicates the size of the payload body (without1606 In the case of a <x:ref>304 (Not Modified)</x:ref> response (&status-304;) 1607 to a GET request, Content-Length indicates the size of the payload body (without 1606 1608 any potential transfer-coding) that would have been sent in a 200 (OK) 1607 1609 response. … … 4109 4111 </reference> 4110 4112 4113 <reference anchor="Part4"> 4114 <front> 4115 <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> 4116 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding"> 4117 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> 4118 <address><email>fielding@gbiv.com</email></address> 4119 </author> 4120 <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon"> 4121 <organization abbrev="W3C">World Wide Web Consortium</organization> 4122 <address><email>ylafon@w3.org</email></address> 4123 </author> 4124 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke"> 4125 <organization abbrev="greenbytes">greenbytes GmbH</organization> 4126 <address><email>julian.reschke@greenbytes.de</email></address> 4127 </author> 4128 <date month="&ID-MONTH;" year="&ID-YEAR;" /> 4129 </front> 4130 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" /> 4131 <x:source basename="p4-conditional" href="p4-conditional.xml"> 4132 <x:defines>304 (Not Modified)</x:defines> 4133 </x:source> 4134 </reference> 4135 4111 4136 <reference anchor="Part6"> 4112 4137 <front> -
draft-ietf-httpbis/latest/p2-semantics.html
r1707 r1708 1788 1788 </li> 1789 1789 <li> 1790 <p>Other kinds of redirection, such as to a cached result (status code 304 (Not Modified), see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1790 <p>Other kinds of redirection, such as to a cached result (status code <a href="p4-conditional.html#status.304" class="smpl">304 1791 (Not Modified)</a>, see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1791 1792 </p> 1792 1793 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1707 r1708 1535 1535 <x:lt> 1536 1536 <t> 1537 Other kinds of redirection, such as to a cached result (status code 3041538 (Not Modified) , see &status-304;).1537 Other kinds of redirection, such as to a cached result (status code <x:ref>304 1538 (Not Modified)</x:ref>, see &status-304;). 1539 1539 </t> 1540 1540 </x:lt> … … 4565 4565 </front> 4566 4566 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/> 4567 <x:source href="p4-conditional.xml" basename="p4-conditional"/> 4567 <x:source basename="p4-conditional" href="p4-conditional.xml"> 4568 <x:defines>304 (Not Modified)</x:defines> 4569 </x:source> 4568 4570 </reference> 4569 4571 -
draft-ietf-httpbis/latest/p4-conditional.html
r1703 r1708 956 956 <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since 957 957 or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header 958 field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields 959 in the request. 958 field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request. 960 959 </p> 961 960 <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags … … 988 987 </p> 989 988 <p id="rfc.section.3.1.p.4">Origin servers <em class="bcp14">MUST NOT</em> perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead 990 they <em class="bcp14">MUST</em> respond with the 412 (Precondition Failed)status code.989 they <em class="bcp14">MUST</em> respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. 991 990 </p> 992 991 <p id="rfc.section.3.1.p.5">Proxy servers using a cached response as the selected representation <em class="bcp14">MUST NOT</em> perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead, … … 1019 1018 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a> 1020 1019 </pre><p id="rfc.section.3.2.p.4">If any of the entity-tags listed in the If-None-Match field-value match (as per <a href="#entity.tag.comparison" title="Comparison">Section 2.3.2</a>) the entity-tag of the selected representation, or if "*" is given and any current representation exists for that resource, 1021 then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) status code, including the cache-related header fields (particularly ETag) of the selected1022 representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed)status code.1023 </p> 1024 <p id="rfc.section.3.2.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified)response.1020 then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly ETag) of the selected representation that has a matching 1021 entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. 1022 </p> 1023 <p id="rfc.section.3.2.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. 1025 1024 </p> 1026 1025 <p id="rfc.section.3.2.p.6">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then … … 1058 1057 a normal GET. 1059 1058 </li> 1060 <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a 304 (Not Modified)response.1059 <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. 1061 1060 </li> 1062 1061 </ol> … … 1068 1067 </li> 1069 1068 <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than 1070 function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since 1071 header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header 1072 field whenever possible. 1069 function, for deciding whether to send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to 1070 use the exact date string received in a previous Last-Modified header field whenever possible. 1073 1071 </li> 1074 1072 <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from the Last-Modified header … … 1088 1086 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2> 1089 1087 <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field can be used to make a request method conditional by modification date: if the selected 1090 representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the 412 (Precondition Failed) status code. If the selected representation has not been modified since 1091 the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present. 1088 representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present. 1092 1089 </p> 1093 1090 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1703 r1708 696 696 If-Unmodified-Since header field) and one or more entity-tags (e.g., 697 697 in an If-Match, If-None-Match, or If-Range header field) as cache 698 validators, &MUST-NOT; return a response status code of 304 (Not Modified)698 validators, &MUST-NOT; return a response status code of <x:ref>304 (Not Modified)</x:ref> 699 699 unless doing so is consistent with all of the conditional header 700 700 fields in the request. … … 757 757 Origin servers &MUST-NOT; perform the requested method if none of the 758 758 entity-tags match, or if "*" is given and no current representation 759 exists; instead they &MUST; respond with the 412 (Precondition Failed)759 exists; instead they &MUST; respond with the <x:ref>412 (Precondition Failed)</x:ref> 760 760 status code. 761 761 </t> … … 819 819 server &MUST-NOT; perform the requested method. 820 820 Instead, if the request method was GET or HEAD, the server &SHOULD; 821 respond with a 304 (Not Modified)status code, including the cache-related821 respond with a <x:ref>304 (Not Modified)</x:ref> status code, including the cache-related 822 822 header fields (particularly ETag) of the selected representation that has 823 823 a matching entity-tag. For all other request methods, the server &MUST; 824 respond with a 412 (Precondition Failed)status code.824 respond with a <x:ref>412 (Precondition Failed)</x:ref> status code. 825 825 </t> 826 826 <t> … … 829 829 but &MUST; also ignore any If-Modified-Since header field(s) in the 830 830 request. That is, if no entity-tags match, then the server &MUST-NOT; 831 return a 304 (Not Modified)response.831 return a <x:ref>304 (Not Modified)</x:ref> response. 832 832 </t> 833 833 <t> … … 894 894 <t>If the selected representation has not been modified since a valid 895 895 If-Modified-Since date, the server &SHOULD; return a 896 304 (Not Modified)response.</t>896 <x:ref>304 (Not Modified)</x:ref> response.</t> 897 897 </list> 898 898 </t> … … 909 909 &Note; When handling an If-Modified-Since header field, some 910 910 servers will use an exact date comparison function, rather than a 911 less-than function, for deciding whether to send a 304 (Not912 Modified)response. To get best results when sending an If-Modified-Since911 less-than function, for deciding whether to send a <x:ref>304 (Not Modified)</x:ref> 912 response. To get best results when sending an If-Modified-Since 913 913 header field for cache validation, clients are 914 914 advised to use the exact date string received in a previous Last-Modified … … 948 948 has been modified since the time specified in this field, then the 949 949 server &MUST-NOT; perform the requested operation and &MUST; instead 950 respond with the 412 (Precondition Failed)status code.950 respond with the <x:ref>412 (Precondition Failed)</x:ref> status code. 951 951 If the selected representation has not been modified since the time 952 952 specified in this field, the server &SHOULD; perform the request … … 991 991 <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/> 992 992 <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/> 993 <x:anchor-alias value="304 (Not Modified)"/> 993 994 <t> 994 995 The 304 status code indicates that a conditional GET request has been … … 1038 1039 <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/> 1039 1040 <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/> 1041 <x:anchor-alias value="412 (Precondition Failed)"/> 1040 1042 <t> 1041 1043 The 412 status code indicates that one or more preconditions given in -
draft-ietf-httpbis/latest/p5-range.html
r1697 r1708 449 449 } 450 450 @bottom-center { 451 content: "Expires January 2, 2013";451 content: "Expires January 4, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 1">494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-03"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 496 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests."> … … 518 518 </tr> 519 519 <tr> 520 <td class="left">Expires: January 2, 2013</td>520 <td class="left">Expires: January 4, 2013</td> 521 521 <td class="right">J. Reschke, Editor</td> 522 522 </tr> … … 527 527 <tr> 528 528 <td class="left"></td> 529 <td class="right">July 1, 2012</td>529 <td class="right">July 3, 2012</td> 530 530 </tr> 531 531 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on January 2, 2013.</p>557 <p>This Internet-Draft will expire on January 4, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 764 764 Content-Type: image/gif 765 765 </pre><div class="note" id="rfc.section.3.2.p.4"> 766 <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 767 an unsatisfiable Range header field, since not all servers implement this header field. 766 <p> <b>Note:</b> Clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested 767 Range Not Satisfiable)</a> response instead of a 200 (OK) response for an unsatisfiable Range header field, since not all servers implement this header 768 field. 768 769 </p> 769 770 </div> … … 798 799 defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 799 800 </p> 800 <p id="rfc.section.4.2.p.2">When a client receives an incomplete 200 (OK) or 206 (Partial Content) response and already has one or more stored responses801 for the same method and effective request URI, all of the stored responseswith the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator,801 <p id="rfc.section.4.2.p.2">When a client receives an incomplete 200 (OK) or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses 802 with the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator, 802 803 then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses. 803 804 </p> … … 805 806 response and replace those of the matching stored responses. 806 807 </p> 807 <p id="rfc.section.4.2.p.4">If the new response is a 206 (Partial Content) response and at least one of the matching stored responses is a 200 (OK), then 808 the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored 809 responses are 206 responses, then the stored response with the most header fields is used as the source of header fields for 810 the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding 808 <p id="rfc.section.4.2.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a 200 (OK), then the combined response header fields consist 809 of the most recent 200 response's header fields. If all of the matching stored responses are 206 responses, then the stored 810 response with the most header fields is used as the source of header fields for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding 811 811 header fields in the stored response. 812 812 </p> … … 864 864 whose instance-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range-spec <em class="bcp14">MUST</em> ignore it and any content transferred along with it. 865 865 </p> 866 <p id="rfc.section.5.2.p.7">In the case of a byte range request: A server sending a response with status code 416 (Requested range not satisfiable) <em class="bcp14">SHOULD</em> include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of the 867 selected resource. A response with status code 206 (Partial Content) <em class="bcp14">MUST NOT</em> include a Content-Range field with a byte-range-resp-spec of "*". 866 <p id="rfc.section.5.2.p.7">In the case of a byte range request: A server sending a response with status code <a href="#status.416" class="smpl">416 (Requested Range Not 867 Satisfiable)</a> <em class="bcp14">SHOULD</em> include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of the 868 selected resource. A response with status code <a href="#status.206" class="smpl">206 (Partial Content)</a> <em class="bcp14">MUST NOT</em> include a Content-Range field with a byte-range-resp-spec of "*". 868 869 </p> 869 870 <p id="rfc.section.5.2.p.8">The "Content-Range" header field has no meaning for status codes that do not explicitly describe its semantic. Currently, 870 only status codes 206 (Partial Content) and 416 (Requested range not satisfiable)describe the meaning of this header field.871 only status codes <a href="#status.206" class="smpl">206 (Partial Content)</a> and <a href="#status.416" class="smpl">416 (Requested Range Not Satisfiable)</a> describe the meaning of this header field. 871 872 </p> 872 873 <p id="rfc.section.5.2.p.9">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p> … … 910 911 </p> 911 912 <p id="rfc.section.5.3.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target 912 resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a 206 (Partial Content) response. If the validator does not match, 913 then the server <em class="bcp14">SHOULD</em> send the entire representation using a 200 (OK) response. 913 resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a 200 (OK) response. 914 914 </p> 915 915 <div id="rfc.iref.r.1"></div> … … 951 951 <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current 952 952 length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set 953 is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a 416 (Requested range not satisfiable) status code. Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a 206 (Partial Content)status code containing the satisfiable ranges of the representation.953 is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a <a href="#status.416" class="smpl">416 (Requested Range Not Satisfiable)</a> status code. Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a <a href="#status.206" class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation. 954 954 </p> 955 955 <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a representation of length 10000): </p> … … 987 987 <ul> 988 988 <li>The presence of a Range header field in an unconditional GET modifies what is returned if the GET is otherwise successful. 989 In other words, the response carries a status code of 206 (Partial Content)instead of 200 (OK).989 In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of 200 (OK). 990 990 </li> 991 991 <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match, … … 1193 1193 <div id="rfc.iref.m.2"></div> 1194 1194 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="internet.media.type.multipart.byteranges" href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></h1> 1195 <p id="rfc.section.A.p.1">When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple1196 non-overlapping ranges), theseare transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.1195 <p id="rfc.section.A.p.1">When an HTTP <a href="#status.206" class="smpl">206 (Partial Content)</a> response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these 1196 are transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. 1197 1197 </p> 1198 1198 <div class="note" id="rfc.section.A.p.2"> -
draft-ietf-httpbis/latest/p5-range.xml
r1697 r1708 312 312 <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/> 313 313 <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/> 314 <x:anchor-alias value="206 (Partial Content)"/> 314 315 <t> 315 316 The server has fulfilled the partial GET request for the resource. … … 354 355 <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/> 355 356 <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/> 357 <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/> 356 358 <t> 357 359 A server &SHOULD; return a response with this status code if a request … … 377 379 <x:note> 378 380 <t> 379 &Note; Clients cannot depend on servers to send a 416 (Requested380 range not satisfiable)response instead of a 200 (OK) response for381 &Note; Clients cannot depend on servers to send a <x:ref>416 (Requested 382 Range Not Satisfiable)</x:ref> response instead of a 200 (OK) response for 381 383 an unsatisfiable Range header field, since not all servers 382 384 implement this header field. … … 442 444 </t> 443 445 <t> 444 When a client receives an incomplete 200 (OK) or 206 (Partial Content)446 When a client receives an incomplete 200 (OK) or <x:ref>206 (Partial Content)</x:ref> 445 447 response and already has one or more stored responses for the same method 446 448 and effective request URI, all of the stored responses with the same … … 456 458 </t> 457 459 <t> 458 If the new response is a 206 (Partial Content)response and at least one460 If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one 459 461 of the matching stored responses is a 200 (OK), then the combined response 460 462 header fields consist of the most recent 200 response's header fields. … … 578 580 <t> 579 581 In the case of a byte range request: 580 A server sending a response with status code 416 (Requested range not581 satisfiable)&SHOULD; include a Content-Range field with a byte-range-resp-spec582 A server sending a response with status code <x:ref>416 (Requested Range Not 583 Satisfiable)</x:ref> &SHOULD; include a Content-Range field with a byte-range-resp-spec 582 584 of "*". The instance-length specifies the current length of 583 the selected resource. A response with status code 206 (Partial584 Content)&MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*".585 the selected resource. A response with status code <x:ref>206 (Partial Content)</x:ref> 586 &MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*". 585 587 </t> 586 588 <t> 587 589 The "Content-Range" header field has no meaning for status codes that do not 588 590 explicitly describe its semantic. Currently, only status codes 589 206 (Partial Content) and 416 (Requested range not satisfiable)describe591 <x:ref>206 (Partial Content)</x:ref> and <x:ref>416 (Requested Range Not Satisfiable)</x:ref> describe 590 592 the meaning of this header field. 591 593 </t> … … 678 680 validator for the selected representation of the target resource, then 679 681 the server &SHOULD; send the specified sub-range of the representation 680 using a 206 (Partial Content)response. If the validator does not match,682 using a <x:ref>206 (Partial Content)</x:ref> response. If the validator does not match, 681 683 then the server &SHOULD; send the entire representation using a 200 (OK) 682 684 response. … … 760 762 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set 761 763 is unsatisfiable, the server &SHOULD; return a response with a 762 416 (Requested range not satisfiable)status code. Otherwise, the server763 &SHOULD; return a response with a 206 (Partial Content)status code764 <x:ref>416 (Requested Range Not Satisfiable)</x:ref> status code. Otherwise, the server 765 &SHOULD; return a response with a <x:ref>206 (Partial Content)</x:ref> status code 764 766 containing the satisfiable ranges of the representation. 765 767 </t> … … 830 832 <t>The presence of a Range header field in an unconditional GET modifies 831 833 what is returned if the GET is otherwise successful. In other 832 words, the response carries a status code of 206 (Partial833 Content)instead of 200 (OK).</t>834 words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref> 835 instead of 200 (OK).</t> 834 836 835 837 <t>The presence of a Range header field in a conditional GET (a request … … 1221 1223 <iref item="multipart/byteranges Media Type" primary="true"/> 1222 1224 <t> 1223 When an HTTP 206 (Partial Content)response message includes the1225 When an HTTP <x:ref>206 (Partial Content)</x:ref> response message includes the 1224 1226 content of multiple ranges (a response to a request for multiple 1225 1227 non-overlapping ranges), these are transmitted as a multipart -
draft-ietf-httpbis/latest/p6-cache.html
r1707 r1708 878 878 </p> 879 879 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire 880 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content) 881 response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does 880 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does 882 881 not understand the range units used in those fields. 883 882 </p> 884 883 <p id="rfc.section.2.1.p.6">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 2.9</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies 885 a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the 206 (Partial Content)status code.884 a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code. 886 885 </p> 887 886 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2> … … 1066 1065 <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section 3.6</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected. 1067 1066 </p> 1068 <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally 1069 forward to the requesting client, and the received response is no longer fresh, the cache can forward it to the requesting 1070 client without adding a new Warning (but without removing any existing Warning header fields). A cache shouldn't attempt to 1071 validate a response simply because that response became stale in transit. 1067 <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache 1068 can forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields). 1069 A cache shouldn't attempt to validate a response simply because that response became stale in transit. 1072 1070 </p> 1073 1071 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> … … 1087 1085 <p id="rfc.section.2.4.p.5"> </p> 1088 1086 <ul> 1089 <li>A 304 (Not Modified)response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses with 304 Not Modified">Section 2.4.1</a>.1087 <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses with 304 Not Modified">Section 2.4.1</a>. 1090 1088 </li> 1091 1089 <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional … … 1098 1096 </ul> 1099 1097 <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a> <a id="freshening.responses" href="#freshening.responses">Freshening Responses with 304 Not Modified</a></h3> 1100 <p id="rfc.section.2.4.1.p.1">When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache1101 key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored1102 response(s) with the new information providedin the 304 response.1098 <p id="rfc.section.2.4.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored 200 (OK) responses for the same cache key, the cache needs to identify which of 1099 the stored responses are updated by this new response and then update the stored response(s) with the new information provided 1100 in the 304 response. 1103 1101 </p> 1104 1102 <ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r1707 r1708 508 508 response header block has been received, a cache &MAY; store an incomplete 509 509 response message body if the cache entry is recorded as incomplete. 510 Likewise, a 206 (Partial Content)response &MAY; be stored as if it were510 Likewise, a <x:ref>206 (Partial Content)</x:ref> response &MAY; be stored as if it were 511 511 an incomplete 200 (OK) cache entry. However, a cache &MUST-NOT; store 512 512 incomplete or partial content responses if it does not support the Range … … 522 522 specifies a range that is wholly within the incomplete response. 523 523 A cache &MUST-NOT; send a partial response to a client without explicitly 524 marking it as such using the 206 (Partial Content)status code.524 marking it as such using the <x:ref>206 (Partial Content)</x:ref> status code. 525 525 </t> 526 526 </section> … … 866 866 <t> 867 867 If a cache receives a first-hand response (either an entire response, or a 868 304 (Not Modified)response) that it would normally forward to the868 <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the 869 869 requesting client, and the received response is no longer fresh, the cache 870 870 can forward it to the requesting client without adding a new Warning (but … … 906 906 <list style="symbols"> 907 907 <t> 908 A 304 (Not Modified)response status code indicates that the stored908 A <x:ref>304 (Not Modified)</x:ref> response status code indicates that the stored 909 909 response can be updated and reused; see <xref 910 910 target="freshening.responses"/>. … … 928 928 <section anchor="freshening.responses" title="Freshening Responses with 304 Not Modified"> 929 929 <t> 930 When a cache receives a 304 (Not Modified)response and already has one930 When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and already has one 931 931 or more stored 200 (OK) responses for the same cache key, the cache needs 932 932 to identify which of the stored responses are updated by this new response … … 2308 2308 </front> 2309 2309 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" /> 2310 <x:source basename="p4-conditional" href="p4-conditional.xml" /> 2310 <x:source basename="p4-conditional" href="p4-conditional.xml"> 2311 <x:defines>304 (Not Modified)</x:defines> 2312 </x:source> 2311 2313 </reference> 2312 2314 … … 2329 2331 </front> 2330 2332 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" /> 2331 <x:source basename="p5-range" href="p5-range.xml" /> 2333 <x:source basename="p5-range" href="p5-range.xml"> 2334 <x:defines>206 (Partial Content)</x:defines> 2335 </x:source> 2332 2336 </reference> 2333 2337 -
draft-ietf-httpbis/latest/p7-auth.html
r1697 r1708 449 449 } 450 450 @bottom-center { 451 content: "Expires January 2, 2013";451 content: "Expires January 4, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 1">491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-03"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: January 2, 2013</td>522 <td class="left">Expires: January 4, 2013</td> 523 523 <td class="right">greenbytes</td> 524 524 </tr> 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 1, 2012</td>527 <td class="right">July 3, 2012</td> 528 528 </tr> 529 529 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on January 2, 2013.</p>555 <p>This Internet-Draft will expire on January 4, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 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 401 (Unauthorized)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-Authenticate header field containing at least one challenge applicable to the requested resource.686 </p> 687 <p id="rfc.section.2.1.p.6">The 407 (Proxy Authentication Required)response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header 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 WWW-Authenticate 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 Proxy-Authenticate 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> ) ] … … 699 699 </p> 700 700 </div> 701 <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 401 702 (Unauthorized) — can do so by including an Authorization header field with the request. 703 </p> 704 <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 407 (Proxy Authentication 705 Required) — can do so by including a Proxy-Authorization header field with the request. 701 <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 Authorization header field with the request. 702 </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-Authorization header field with the request. 706 704 </p> 707 705 <p id="rfc.section.2.1.p.12">Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm … … 712 710 <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> ) ] 713 711 </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 714 credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> return a 401 (Unauthorized)response. Such responses <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.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-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. 715 713 </p> 716 714 <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, 717 a proxy <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required)response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy.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-Authenticate header field containing a (possibly new) challenge applicable to the proxy. 718 716 </p> 719 717 <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 403 (Forbidden) … … 823 821 <div id="rfc.iref.s.2"></div> 824 822 <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> 825 <p id="rfc.section.3.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client ought to first authenticate itself with the proxy. 826 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-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 4.3</a>). 823 <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-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 4.3</a>). 827 824 </p> 828 825 <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> … … 832 829 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="header.authorization" href="#header.authorization">Authorization</a></h2> 833 830 <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with a server — usually, but not necessarily, 834 after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent835 for the realm of the resource being requested.831 after receiving a <a href="#status.401" class="smpl">401 832 (Unauthorized)</a> response. Its value consists of credentials containing information of the user agent for the realm of the resource being requested. 836 833 </p> 837 834 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a> … … 856 853 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 857 854 <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters 858 applicable to the proxy for this 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.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required)response.855 applicable to the proxy for this 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.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. 859 856 </p> 860 857 <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> … … 884 881 applicable to 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.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 885 882 </p> 886 <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in 401 (Unauthorized)response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the883 <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in <a href="#status.401" class="smpl">401 (Unauthorized)</a> response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the 887 884 response. 888 885 </p> -
draft-ietf-httpbis/latest/p7-auth.xml
r1697 r1708 258 258 </t> 259 259 <t> 260 The 401 (Unauthorized)response message is used by an origin server260 The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server 261 261 to challenge the authorization of a user agent. This response &MUST; 262 262 include a WWW-Authenticate header field containing at least one … … 264 264 </t> 265 265 <t> 266 The 407 (Proxy Authentication Required)response message is used by a proxy to266 The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to 267 267 challenge the authorization of a client and &MUST; include a Proxy-Authenticate 268 268 header field containing at least one challenge … … 290 290 <t> 291 291 A user agent that wishes to authenticate itself with an origin server 292 — usually, but not necessarily, after receiving a 401 (Unauthorized)292 — usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref> 293 293 — can do so by including an Authorization header field with the 294 294 request. … … 296 296 <t> 297 297 A client that wishes to authenticate itself with a proxy — usually, 298 but not necessarily, after receiving a 407 (Proxy Authentication Required)298 but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref> 299 299 — can do so by including a Proxy-Authorization header field with the 300 300 request. … … 316 316 invalid credentials (e.g., a bad password) or partial credentials (e.g., 317 317 when the authentication scheme requires more than one round trip), an origin 318 server &SHOULD; return a 401 (Unauthorized)response. Such responses &MUST;318 server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such responses &MUST; 319 319 include a WWW-Authenticate header field containing at least one (possibly 320 320 new) challenge applicable to the requested resource. … … 323 323 Likewise, upon a request that requires authentication by proxies that omit 324 324 credentials or contain invalid or partial credentials, a proxy &SHOULD; 325 return a 407 (Proxy Authentication Required)response. Such responses325 return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses 326 326 &MUST; include a Proxy-Authenticate header field containing a (possibly 327 327 new) challenge applicable to the proxy. … … 498 498 <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/> 499 499 <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/> 500 <x:anchor-alias value="401 (Unauthorized)"/> 500 501 <t> 501 502 The request requires user authentication. The response &MUST; include a … … 515 516 <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/> 516 517 <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/> 517 <t> 518 This code is similar to 401 (Unauthorized), but indicates that the 518 <x:anchor-alias value="407 (Proxy Authentication Required)"/> 519 <t> 520 This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the 519 521 client ought to first authenticate itself with the proxy. The proxy &MUST; 520 522 return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a … … 538 540 <t> 539 541 The "Authorization" header field allows a user agent to authenticate 540 itself with a server — usually, but not necessarily, after receiving a 401541 (Unauthorized) response. Its value consists of credentials containing542 itself with a server — usually, but not necessarily, after receiving a <x:ref>401 543 (Unauthorized)</x:ref> response. Its value consists of credentials containing 542 544 information of the user agent for the realm of the resource being 543 545 requested. … … 593 595 challenge that indicates the authentication scheme(s) and parameters 594 596 applicable to the proxy for this effective request URI (&effective-request-uri;). 595 It &MUST; be included as part of a 407 (Proxy Authentication Required)response.597 It &MUST; be included as part of a <x:ref>407 (Proxy Authentication Required)</x:ref> response. 596 598 </t> 597 599 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/> … … 649 651 </t> 650 652 <t> 651 It &MUST; be included in 401 (Unauthorized)response messages and &MAY; be653 It &MUST; be included in <x:ref>401 (Unauthorized)</x:ref> response messages and &MAY; be 652 654 included in other response messages to indicate that supplying credentials 653 655 (or different credentials) might affect the response.
Note: See TracChangeset
for help on using the changeset viewer.