Ignore:
Timestamp:
Jul 3, 2012, 11:26:11 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink status codes definitions (for those defined in parts 4, 5, and 7)

Location:
draft-ietf-httpbis/latest
Files:
12 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1707 r1708  
    13801380         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
    13811381         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>.)
    13831383      </p>
    13841384      <div id="rfc.iref.t.4"></div>
     
    14061406      <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&nbsp;3.2</a>, before determining the message body length.
    14071407      </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.
    14141413      </p>
    14151414      <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
     
    14311430      <div id="rfc.figure.u.36"></div><pre class="text">  Content-Length: 3495
    14321431</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.
    14361434      </p>
    14371435      <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
     
    17131711      </p>
    17141712      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<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&nbsp;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.10"><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
     1713      <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&nbsp;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
    17161714         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
    17171715         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.
     
    17551753      </p>
    17561754      <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.11"><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&nbsp;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
     1755         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&nbsp;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
    17581756         to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment
    17591757         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>).
     
    18141812      </p>
    18151813      <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.12"><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,
    18171815         </p>
    18181816      </div>
    18191817      <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    18201818</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.13"><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,
    18221820            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    18231821         </p>
     
    19741972         </p>
    19751973      </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.14"><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&nbsp;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&nbsp;4</a>).
    19771975      </p>
    19781976      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
     
    19801978         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    19811979         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.15"><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.
    19831981      </p>
    19841982      <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.
     
    21282126      <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.
    21292127      </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.16"><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
     2128      <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
    21312129         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.
    21322130      </p>
     
    21582156      <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    21592157      <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.17"><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
     2158         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
    21612159         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.
    21622160      </p>
     
    21712169      </p>
    21722170      <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<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.18"><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
     2171      <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
    21742172         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21752173         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
     
    21782176      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21792177      <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.20"><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.
    21832181         </li>
    21842182      </ul>
     
    22242222         <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
    22252223            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.21"><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>).
    22272225         </li>
    22282226      </ul>
     
    22612259      </p>
    22622260      <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.22"><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>).
    22642262      </p>
    22652263      <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
     
    25252523         <li>Pointer to specification text</li>
    25262524      </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.23"><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&nbsp;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&nbsp;4.2</a>.
    25282526      </p>
    25292527      <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.
     
    26852683         that most implementations will choose substantially higher limits.
    26862684      </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.24"><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>).
    26882686      </p>
    26892687      <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.
     
    27302728      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    27312729      </h2>
    2732       <table>                   
     2730      <table>                     
    27332731         <tr>
    27342732            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
     
    27382736            <td class="reference"><b id="Part2">[Part2]</b></td>
    27392737            <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&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), July&nbsp;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&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), July&nbsp;2012.
    27402743            </td>
    27412744         </tr>
     
    37423745            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    37433746                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>
    3744                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    37453748                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
    3746                         <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a></li>
    3747                         <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    3748                         <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">5.3</a></li>
     3749                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
     3751                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    37493752                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3750                         <li><em>Section 4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>
    3752                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.4.3</a></li>
     3753                        <li><em>Section 4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.4.3</a></li>
    37533756                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
    3754                         <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.5</a></li>
    3755                         <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">8.6</a></li>
    3756                         <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.24">8.6</a></li>
    3757                         <li><em>Section 5.4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">4.3.1</a></li>
     3757                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.5</a></li>
     3758                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">8.6</a></li>
     3759                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3.1</a></li>
    37593762                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    3760                         <li><em>Section 9.11</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>
    37613764                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
     3765                     </ul>
     3766                  </li>
     3767                  <li><em>Part4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    37623769                     </ul>
    37633770                  </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1707 r1708  
    4040  <!ENTITY status-203             "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4141  <!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'/>">
    4243  <!ENTITY status-4xx             "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4344  <!ENTITY status-414             "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    14831484   Successful (2xx) responses to CONNECT switch to tunnel mode instead of
    14841485   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>
    14861487   responses &MUST-NOT; include a message body.
    14871488   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;.)
    14891490</t>
    14901491
     
    15511552<t>
    15521553   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,
    15541556   to indicate that the origin server would have applied a transfer coding
    15551557   to the message body if the request had been an unconditional GET.
     
    16021604   the size of the payload body (without any potential transfer-coding)
    16031605   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 (without
     1606   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
    16061608   any potential transfer-coding) that would have been sent in a 200 (OK)
    16071609   response.
     
    41094111</reference>
    41104112
     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
    41114136<reference anchor="Part6">
    41124137  <front>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1707 r1708  
    17881788         </li>
    17891789         <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>).
    17911792            </p>
    17921793         </li>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1707 r1708  
    15351535      <x:lt>
    15361536        <t>
    1537           Other kinds of redirection, such as to a cached result (status code 304
    1538           (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;).
    15391539        </t>
    15401540      </x:lt>
     
    45654565  </front>
    45664566  <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>
    45684570</reference>
    45694571
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1703 r1708  
    956956      <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
    957957         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.
    960959      </p>
    961960      <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
     
    988987      </p>
    989988      <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.
    991990      </p>
    992991      <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,
     
    10191018      <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>
    10201019</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&nbsp;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 selected
    1022          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.
    10251024      </p>
    10261025      <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
     
    10581057            a normal GET.
    10591058         </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.
    10611060         </li>
    10621061      </ol>
     
    10681067         </li>
    10691068         <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.
    10731071         </li>
    10741072         <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
     
    10881086      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    10891087      <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.
    10921089      </p>
    10931090      <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  
    696696   If-Unmodified-Since header field) and one or more entity-tags (e.g.,
    697697   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>
    699699   unless doing so is consistent with all of the conditional header
    700700   fields in the request.
     
    757757   Origin servers &MUST-NOT; perform the requested method if none of the
    758758   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>
    760760   status code.
    761761</t>
     
    819819   server &MUST-NOT; perform the requested method.
    820820   Instead, if the request method was GET or HEAD, the server &SHOULD;
    821    respond with a 304 (Not Modified) status code, including the cache-related
     821   respond with a <x:ref>304 (Not Modified)</x:ref> status code, including the cache-related
    822822   header fields (particularly ETag) of the selected representation that has
    823823   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.
    825825</t>
    826826<t>
     
    829829   but &MUST; also ignore any If-Modified-Since header field(s) in the
    830830   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.
    832832</t>
    833833<t>
     
    894894      <t>If the selected representation has not been modified since a valid
    895895         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>
    897897  </list>
    898898</t>
     
    909909      &Note; When handling an If-Modified-Since header field, some
    910910      servers will use an exact date comparison function, rather than a
    911       less-than function, for deciding whether to send a 304 (Not
    912       Modified) response. To get best results when sending an If-Modified-Since
     911      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
    913913      header field for cache validation, clients are
    914914      advised to use the exact date string received in a previous Last-Modified
     
    948948   has been modified since the time specified in this field, then the
    949949   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.
    951951   If the selected representation has not been modified since the time
    952952   specified in this field, the server &SHOULD; perform the request
     
    991991  <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
    992992  <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
     993  <x:anchor-alias value="304 (Not Modified)"/>
    993994<t>
    994995   The 304 status code indicates that a conditional GET request has been
     
    10381039  <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
    10391040  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
     1041  <x:anchor-alias value="412 (Precondition Failed)"/>
    10401042<t>
    10411043   The 412 status code indicates that one or more preconditions given in
  • draft-ietf-httpbis/latest/p5-range.html

    r1697 r1708  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 2, 2013";
     451       content: "Expires January 4, 2013";
    452452  }
    453453  @bottom-right {
     
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-07-01">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
     
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: January 2, 2013</td>
     520               <td class="left">Expires: January 4, 2013</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
     
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">July 1, 2012</td>
     529               <td class="right">July 3, 2012</td>
    530530            </tr>
    531531         </tbody>
     
    555555         in progress”.
    556556      </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>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    764764Content-Type: image/gif
    765765</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.
    768769         </p>
    769770      </div>
     
    798799         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>.
    799800      </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 responses
    801          for the same method and effective request URI, all of the stored responses 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,
     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,
    802803         then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses.
    803804      </p>
     
    805806         response and replace those of the matching stored responses.
    806807      </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
    811811         header fields in the stored response.
    812812      </p>
     
    864864         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.
    865865      </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 "*".
    868869      </p>
    869870      <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.
    871872      </p>
    872873      <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>
     
    910911      </p>
    911912      <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.
    914914      </p>
    915915      <div id="rfc.iref.r.1"></div>
     
    951951      <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
    952952         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.
    954954      </p>
    955955      <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a representation of length 10000): </p>
     
    987987      <ul>
    988988         <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).
    990990         </li>
    991991         <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,
     
    11931193      <div id="rfc.iref.m.2"></div>
    11941194      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<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 multiple
    1196          non-overlapping ranges), these 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>.
     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>.
    11971197      </p>
    11981198      <div class="note" id="rfc.section.A.p.2">
  • draft-ietf-httpbis/latest/p5-range.xml

    r1697 r1708  
    312312  <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/>
    313313  <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/>
     314  <x:anchor-alias value="206 (Partial Content)"/>
    314315<t>
    315316   The server has fulfilled the partial GET request for the resource.
     
    354355  <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/>
    355356  <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)"/>
    356358<t>
    357359   A server &SHOULD; return a response with this status code if a request
     
    377379<x:note>
    378380  <t>
    379     &Note; Clients cannot depend on servers to send a 416 (Requested
    380     range not satisfiable) response instead of a 200 (OK) response for
     381    &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
    381383    an unsatisfiable Range header field, since not all servers
    382384    implement this header field.
     
    442444</t>
    443445<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>
    445447   response and already has one or more stored responses for the same method
    446448   and effective request URI, all of the stored responses with the same
     
    456458</t>
    457459<t>
    458    If the new response is a 206 (Partial Content) response and at least one
     460   If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one
    459461   of the matching stored responses is a 200 (OK), then the combined response
    460462   header fields consist of the most recent 200 response's header fields.
     
    578580<t>
    579581   In the case of a byte range request:
    580    A server sending a response with status code 416 (Requested range not
    581    satisfiable) &SHOULD; include a Content-Range field with a byte-range-resp-spec
     582   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
    582584   of "*". The instance-length specifies the current length of
    583    the selected resource. A response with status code 206 (Partial
    584    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 "*".
    585587</t>
    586588<t>
    587589  The "Content-Range" header field has no meaning for status codes that do not
    588590  explicitly describe its semantic. Currently, only status codes
    589   206 (Partial Content) and 416 (Requested range not satisfiable) describe
     591  <x:ref>206 (Partial Content)</x:ref> and <x:ref>416 (Requested Range Not Satisfiable)</x:ref> describe
    590592  the meaning of this header field.
    591593</t>
     
    678680   validator for the selected representation of the target resource, then
    679681   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,
    681683   then the server &SHOULD; send the entire representation using a 200 (OK)
    682684   response.
     
    760762   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
    761763   is unsatisfiable, the server &SHOULD; return a response with a
    762    416 (Requested range not satisfiable) status code. Otherwise, the server
    763    &SHOULD; return a response with a 206 (Partial Content) status code
     764   <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
    764766   containing the satisfiable ranges of the representation.
    765767</t>
     
    830832     <t>The presence of a Range header field in an unconditional GET modifies
    831833        what is returned if the GET is otherwise successful. In other
    832         words, the response carries a status code of 206 (Partial
    833         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>
    834836
    835837     <t>The presence of a Range header field in a conditional GET (a request
     
    12211223<iref item="multipart/byteranges Media Type" primary="true"/>
    12221224<t>
    1223    When an HTTP 206 (Partial Content) response message includes the
     1225   When an HTTP <x:ref>206 (Partial Content)</x:ref> response message includes the
    12241226   content of multiple ranges (a response to a request for multiple
    12251227   non-overlapping ranges), these are transmitted as a multipart
  • draft-ietf-httpbis/latest/p6-cache.html

    r1707 r1708  
    878878      </p>
    879879      <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
    882881         not understand the range units used in those fields.
    883882      </p>
    884883      <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&nbsp;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.
    886885      </p>
    887886      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
     
    10661065      <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&nbsp;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.
    10671066      </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.
    10721070      </p>
    10731071      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
     
    10871085      <p id="rfc.section.2.4.p.5"> </p>
    10881086      <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&nbsp;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&nbsp;2.4.1</a>.
    10901088         </li>
    10911089         <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
     
    10981096      </ul>
    10991097      <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<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 cache
    1101          key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored
    1102          response(s) with the new information provided in 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.
    11031101      </p>
    11041102      <ul>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1707 r1708  
    508508   response header block has been received, a cache &MAY; store an incomplete
    509509   response message body if the cache entry is recorded as incomplete.
    510    Likewise, a 206 (Partial Content) response &MAY; be stored as if it were
     510   Likewise, a <x:ref>206 (Partial Content)</x:ref> response &MAY; be stored as if it were
    511511   an incomplete 200 (OK) cache entry.  However, a cache &MUST-NOT; store
    512512   incomplete or partial content responses if it does not support the Range
     
    522522   specifies a range that is wholly within the incomplete response.
    523523   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.
    525525</t>
    526526</section>
     
    866866<t>
    867867   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 the
     868   <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the
    869869   requesting client, and the received response is no longer fresh, the cache
    870870   can forward it to the requesting client without adding a new Warning (but
     
    906906   <list style="symbols">
    907907      <t>
    908          A 304 (Not Modified) response status code indicates that the stored
     908         A <x:ref>304 (Not Modified)</x:ref> response status code indicates that the stored
    909909         response can be updated and reused; see <xref
    910910         target="freshening.responses"/>.
     
    928928<section anchor="freshening.responses" title="Freshening Responses with 304 Not Modified">
    929929<t>
    930    When a cache receives a 304 (Not Modified) response and already has one
     930   When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and already has one
    931931   or more stored 200 (OK) responses for the same cache key, the cache needs
    932932   to identify which of the stored responses are updated by this new response
     
    23082308    </front>
    23092309    <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>
    23112313  </reference>
    23122314
     
    23292331    </front>
    23302332    <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>
    23322336  </reference>
    23332337
  • draft-ietf-httpbis/latest/p7-auth.html

    r1697 r1708  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 2, 2013";
     451       content: "Expires January 4, 2013";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-07-01">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: January 2, 2013</td>
     522               <td class="left">Expires: January 4, 2013</td>
    523523               <td class="right">greenbytes</td>
    524524            </tr>
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 1, 2012</td>
     527               <td class="right">July 3, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    553553         in progress”.
    554554      </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>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    683683         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>).
    684684      </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.
    688688      </p>
    689689      <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> ) ]
     
    699699         </p>
    700700      </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.
    706704      </p>
    707705      <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
     
    712710      <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> ) ]
    713711</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.
    715713      </p>
    716714      <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.
    718716      </p>
    719717      <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)
     
    823821      <div id="rfc.iref.s.2"></div>
    824822      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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&nbsp;4.3</a>).
    827824      </p>
    828825      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     
    832829      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
    833830      <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 agent
    835          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.
    836833      </p>
    837834      <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>
     
    856853      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    857854      <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.
    859856      </p>
    860857      <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>
     
    884881         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>).
    885882      </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 the
     883      <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
    887884         response.
    888885      </p>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1697 r1708  
    258258</t>
    259259<t>
    260    The 401 (Unauthorized) response message is used by an origin server
     260   The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
    261261   to challenge the authorization of a user agent. This response &MUST;
    262262   include a WWW-Authenticate header field containing at least one
     
    264264</t>
    265265<t>   
    266    The 407 (Proxy Authentication Required) response message is used by a proxy to
     266   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to
    267267   challenge the authorization of a client and &MUST; include a Proxy-Authenticate
    268268   header field containing at least one challenge
     
    290290<t>
    291291   A user agent that wishes to authenticate itself with an origin server
    292    &mdash; usually, but not necessarily, after receiving a 401 (Unauthorized)
     292   &mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
    293293   &mdash; can do so by including an Authorization header field with the
    294294   request.
     
    296296<t>   
    297297   A client that wishes to authenticate itself with a proxy &mdash; 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>
    299299   &mdash; can do so by including a Proxy-Authorization header field with the
    300300   request.
     
    316316   invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    317317   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;
    319319   include a WWW-Authenticate header field containing at least one (possibly
    320320   new) challenge applicable to the requested resource.
     
    323323   Likewise, upon a request that requires authentication by proxies that omit
    324324   credentials or contain invalid or partial credentials, a proxy &SHOULD;
    325    return a 407 (Proxy Authentication Required) response. Such responses
     325   return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
    326326   &MUST; include a Proxy-Authenticate header field containing a (possibly
    327327   new) challenge applicable to the proxy.
     
    498498  <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/>
    499499  <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/>
     500  <x:anchor-alias value="401 (Unauthorized)"/>
    500501<t>
    501502   The request requires user authentication. The response &MUST; include a
     
    515516  <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/>
    516517  <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
    519521   client ought to first authenticate itself with the proxy. The proxy &MUST;
    520522   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
     
    538540<t>
    539541   The "Authorization" header field allows a user agent to authenticate
    540    itself with a server &mdash; usually, but not necessarily, after receiving a 401
    541    (Unauthorized) response. Its value consists of credentials containing
     542   itself with a server &mdash; usually, but not necessarily, after receiving a <x:ref>401
     543   (Unauthorized)</x:ref> response. Its value consists of credentials containing
    542544   information of the user agent for the realm of the resource being
    543545   requested.
     
    593595   challenge that indicates the authentication scheme(s) and parameters
    594596   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.
    596598</t>
    597599<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
     
    649651</t>
    650652<t>   
    651    It &MUST; be included in 401 (Unauthorized) response messages and &MAY; be
     653   It &MUST; be included in <x:ref>401 (Unauthorized)</x:ref> response messages and &MAY; be
    652654   included in other response messages to indicate that supplying credentials
    653655   (or different credentials) might affect the response.
Note: See TracChangeset for help on using the changeset viewer.