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

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1737 r1740  
    961961      <p id="rfc.section.2.5.p.4">Unless noted otherwise, recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
    962962         except when they have a direct impact on security, since different applications of the protocol require different error handling
    963          strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field
    964          doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.
     963         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
     964         to be dangerous.
    965965      </p>
    966966      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
    … …  
    10011001      </p>
    10021002      <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
    1003          the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server)
    1004          that the server improperly handles higher request versions.
     1003         the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
    10051004      </p>
    10061005      <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
    … …  
    10111010         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    10121011         number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the
    1013          given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g.,
    1014          User-Agent) uniquely match the values sent by a client known to be in error.
     1012         given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
    10151013      </p>
    10161014      <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
    … …  
    12091207                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
    12101208</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1211          the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1209         the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12121210      </p>
    12131211      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
    … …  
    12201218      </p>
    12211219      <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    1222          to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations
    1223          can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include
     1220         to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include
    12241221         conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.
    12251222      </p>
    … …  
    14021399      <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.
    14031400      </p>
    1404       <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1401      <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    14051402      </p>
    14061403      <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
    … …  
    19501947         </li>
    19511948      </ul>
    1952       <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
     1949      <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in that response.
    19531950      </p>
    19541951      <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
    19551952      </p>
    19561953      <ul>
    1957          <li>Content-Encoding</li>
    1958          <li>Content-Range</li>
    1959          <li>Content-Type</li>
     1954         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)
     1955         </li>
     1956         <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
     1957         </li>
     1958         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)
     1959         </li>
    19601960      </ul>
    19611961      <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    … …  
    19661966         </p>
    19671967      </div>
    1968       <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1968      <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    19691969      </p>
    19701970      <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>
    19711971      <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19721972         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1973          on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
     1973         on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
    19741974      </p>
    19751975      <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
    … …  
    20422042      <p id="rfc.section.6.2.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    20432043      </p>
    2044       <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
    2045          fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
     2044      <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    20462045      </p>
    20472046      <p id="rfc.section.6.2.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    … …  
    21192118      <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.
    21202119      </p>
    2121       <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2120      <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    21222121         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.
    21232122      </p>
    … …  
    21492148      <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>
    21502149      <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2151          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     2150         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    21522151         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.
    21532152      </p>
    … …  
    21622161      </p>
    21632162      <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>
    2164       <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2163      <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    21652164         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21662165         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    21692168      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21702169      <ul>
    2171          <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.
    2172          </li>
    2173          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     2170         <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.
     2171         </li>
     2172         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.
    21742173         </li>
    21752174      </ul>
    … …  
    21802179      <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    21812180      <ul>
    2182          <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    2183          </li>
    2184          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an Expect header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
     2181         <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
     2182         </li>
     2183         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
    21852184            with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"
    21862185            expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared
    … …  
    21922191            prematurely.
    21932192         </li>
    2194          <li>If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the
    2195             request includes a request body, and the server responds with a final status code before reading the entire request body from
    2196             the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
     2193         <li>If an origin server receives a request that does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final
     2194            status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
    21972195            the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
    21982196            a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
    … …  
    22012199      <p id="rfc.section.6.4.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    22022200      <ul>
    2203          <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either
    2204             knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server,
    2205             it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
     2201         <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1
     2202            or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
    22062203         </li>
    22072204         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code.
    … …  
    22092206         <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
    22102207         </li>
    2211          <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect header field
    2212             with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2208         <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22132209         </li>
    22142210      </ul>
    … …  
    22472243      </p>
    22482244      <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2249          is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2245         is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22502246      </p>
    22512247      <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
    … …  
    25112507         <li>Pointer to specification text</li>
    25122508      </ul>
    2513       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2509      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    25142510      </p>
    25152511      <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.
    … …  
    26712667         that most implementations will choose substantially higher limits.
    26722668      </p>
    2673       <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2669      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    26742670      </p>
    26752671      <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.
    … …  
    27162712      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    27172713      </h2>
    2718       <table>                     
     2714      <table>                       
    27192715         <tr>
    27202716            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
    … …  
    27292725            <td class="reference"><b id="Part4">[Part4]</b></td>
    27302726            <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.
     2727            </td>
     2728         </tr>
     2729         <tr>
     2730            <td class="reference"><b id="Part5">[Part5]</b></td>
     2731            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), July&nbsp;2012.
    27312732            </td>
    27322733         </tr>
    … …  
    37333734            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    37343735                  <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>
    3735                   <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>
     3736                  <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.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.4.3</a>, <a href="#rfc.xref.Part2.24">6.5</a>, <a href="#rfc.xref.Part2.25">7.4</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    37363737                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
    3737                         <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>
     3738                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a></li>
    37383739                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
    37393740                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    37403741                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    37413742                        <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>
    3742                         <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>
    3743                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.4.3</a></li>
     3743                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.23">6.4.3</a></li>
     3744                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">6.4.3</a></li>
    37443745                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
    3745                         <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.5</a></li>
    3746                         <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">8.6</a></li>
    3747                         <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>
    3748                         <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>
     3746                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.5</a></li>
     3747                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">8.6</a></li>
     3748                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.26">8.6</a></li>
     3749                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.25">7.4</a></li>
    37493750                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3.1</a></li>
     3751                        <li><em>Section 9.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">5.6.2</a></li>
     3752                        <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.6.2</a></li>
    37503753                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    3751                         <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>
     3754                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.4.3</a></li>
    37523755                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
    37533756                     </ul>
    … …  
    37553758                  <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>
    37563759                        <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>
     3760                     </ul>
     3761                  </li>
     3762                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">5.6.2</a>, <a href="#Part5"><b>10.1</b></a><ul>
     3763                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">5.6.2</a></li>
    37573764                     </ul>
    37583765                  </li>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1737 r1740  
    2727  <!ENTITY representation         "<xref target='Part2' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2828  <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     29  <!ENTITY header-content-encoding    "<xref target='Part2' x:rel='#header.content-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     30  <!ENTITY header-content-range   "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     31  <!ENTITY header-content-type    "<xref target='Part2' x:rel='#header.content-type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2932  <!ENTITY header-date            "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3033  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    609612   on security, since different applications of the protocol require
    610613   different error handling strategies.  For example, a Web browser might
    611    wish to transparently recover from a response where the Location header
    612    field doesn't parse according to the ABNF, whereas a systems control
     614   wish to transparently recover from a response where the <x:ref>Location</x:ref>
     615   header field doesn't parse according to the ABNF, whereas a systems control
    613616   client might consider any form of error recovery to be dangerous.
    614617</t>
    … …  
    699702   the server incorrectly implements the HTTP specification, but only
    700703   after the client has attempted at least one normal request and determined
    701    from the response status or header fields (e.g., Server) that the
    702    server improperly handles higher request versions.
     704   from the response status or header fields (e.g., <x:ref>Server</x:ref>) that
     705   the server improperly handles higher request versions.
    703706</t>
    704707<t>
    … …  
    720723   version of the protocol. Such protocol downgrades &SHOULD-NOT; be
    721724   performed unless triggered by specific client attributes, such as when
    722    one or more of the request header fields (e.g., User-Agent) uniquely
    723    match the values sent by a client known to be in error.
     725   one or more of the request header fields (e.g., <x:ref>User-Agent</x:ref>)
     726   uniquely match the values sent by a client known to be in error.
    724727</t>
    725728<t>
    … …  
    11411144<t>
    11421145   The field-name token labels the corresponding field-value as having the
    1143    semantics defined by that header field.  For example, the Date header field
    1144    is defined in &header-date; as containing the origination
     1146   semantics defined by that header field.  For example, the <x:ref>Date</x:ref>
     1147   header field is defined in &header-date; as containing the origination
    11451148   timestamp for the message in which it appears.
    11461149</t>
    … …  
    11671170   The order in which header fields with differing field names are
    11681171   received is not significant. However, it is "good practice" to send
    1169    header fields that contain control data first, such as Host on
    1170    requests and Date on responses, so that implementations can decide
    1171    when not to handle a message as early as possible.  A server &MUST;
    1172    wait until the entire header section is received before interpreting
     1172   header fields that contain control data first, such as <x:ref>Host</x:ref>
     1173   on requests and <x:ref>Date</x:ref> on responses, so that implementations
     1174   can decide when not to handle a message as early as possible.  A server
     1175   &MUST; wait until the entire header section is received before interpreting
    11731176   a request message, since later header fields might include conditionals,
    11741177   authentication credentials, or deliberately misleading duplicate
    … …  
    15451548</t>
    15461549<t>
    1547    Unlike Content-Encoding (&content-codings;), Transfer-Encoding is a
    1548    property of the message, not of the payload, and thus &MAY; be added or
    1549    removed by any implementation along the request/response chain.
    1550    Additional information about the encoding parameters &MAY; be provided
    1551    by other header fields not defined by this specification.
     1550   Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;),
     1551   Transfer-Encoding is a property of the message, not of the payload, and thus
     1552   &MAY; be added or removed by any implementation along the request/response
     1553   chain. Additional information about the encoding parameters &MAY; be
     1554   provided by other header fields not defined by this specification.
    15521555</t>
    15531556<t>
    … …  
    26212624   but it &MAY; add any of these fields if not already present. If an
    26222625   <x:ref>Expires</x:ref> header field is added, it &MUST; be given a
    2623    field-value identical to that of the Date header field in that response.
     2626   field value identical to that of the <x:ref>Date</x:ref> header field in
     2627   that response.
    26242628</t>
    26252629<t>
    … …  
    26282632   any request:
    26292633  <list style="symbols">
    2630     <t>Content-Encoding</t>
    2631     <t>Content-Range</t>
    2632     <t>Content-Type</t>
     2634    <t><x:ref>Content-Encoding</x:ref> (&header-content-encoding;)</t>
     2635    <t><x:ref>Content-Range</x:ref> (&header-content-range;)</t>
     2636    <t><x:ref>Content-Type</x:ref> (&header-content-type;)</t>
    26332637  </list>
    26342638</t>
    … …  
    28162820<t>
    28172821   Comments &MAY; be used in the Via header field to identify the software
    2818    of each recipient, analogous to the User-Agent and Server header fields.
    2819    However, all comments in the Via field are optional and &MAY; be removed
    2820    by any recipient prior to forwarding the message.
     2822   of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
     2823   <x:ref>Server</x:ref> header fields. However, all comments in the Via field
     2824   are optional and &MAY; be removed by any recipient prior to forwarding the
     2825   message.
    28212826</t>
    28222827<t>
    … …  
    31073112    <t>
    31083113        If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    3109         sending the request body, it &MUST; send an Expect header
     3114        sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
    31103115        field (&header-expect;) with the "100-continue" expectation.
    31113116    </t>
    31123117    <t>
    3113         A client &MUST-NOT; send an Expect header field (&header-expect;)
    3114         with the "100-continue" expectation if it does not intend
    3115         to send a request body.
     3118        A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
     3119        the "100-continue" expectation if it does not intend to send a request
     3120        body.
    31163121    </t>
    31173122  </list>
    … …  
    31293134   Requirements for HTTP/1.1 origin servers:
    31303135  <list style="symbols">
    3131     <t> Upon receiving a request which includes an Expect header
     3136    <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
    31323137        field with the "100-continue" expectation, an origin server &MUST;
    31333138        either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
    … …  
    31403145    </t>
    31413146    <t> An origin server &SHOULD-NOT;  send a <x:ref>100 (Continue)</x:ref> response if
    3142         the request message does not include an Expect header
     3147        the request message does not include an <x:ref>Expect</x:ref> header
    31433148        field with the "100-continue" expectation, and &MUST-NOT; send a
    31443149        <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0
    … …  
    31633168    </t>
    31643169    <t> If an origin server receives a request that does not include an
    3165         Expect header field with the "100-continue" expectation,
     3170        <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
    31663171        the request includes a request body, and the server responds
    31673172        with a final status code before reading the entire request body
    … …  
    31793184   Requirements for HTTP/1.1 proxies:
    31803185  <list style="symbols">
    3181     <t> If a proxy receives a request that includes an Expect header
    3182         field with the "100-continue" expectation, and the proxy
     3186    <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>
     3187        header field with the "100-continue" expectation, and the proxy
    31833188        either knows that the next-hop server complies with HTTP/1.1 or
    31843189        higher, or does not know the HTTP version of the next-hop
    … …  
    31953200    <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the
    31963201        request message was received from an HTTP/1.0 (or earlier)
    3197         client and did not include an Expect header field with
     3202        client and did not include an <x:ref>Expect</x:ref> header field with
    31983203        the "100-continue" expectation. This requirement overrides the
    31993204        general rule for forwarding of <x:ref>1xx</x:ref> responses (see &status-1xx;).
    … …  
    41344139    <x:defines>502 (Bad Gateway)</x:defines>
    41354140    <x:defines>505 (HTTP Version Not Supported)</x:defines>
     4141    <x:defines>Content-Encoding</x:defines>
     4142    <x:defines>Content-Type</x:defines>
     4143    <x:defines>Date</x:defines>
     4144    <x:defines>Expect</x:defines>
     4145    <x:defines>Location</x:defines>
     4146    <x:defines>Server</x:defines>
     4147    <x:defines>User-Agent</x:defines>
    41364148  </x:source>
    41374149</reference>
    … …  
    41574169  <x:source basename="p4-conditional" href="p4-conditional.xml">
    41584170    <x:defines>304 (Not Modified)</x:defines>
     4171  </x:source>
     4172</reference>
     4173
     4174<reference anchor="Part5">
     4175  <front>
     4176    <title>HTTP/1.1, part 5: Range Requests and Partial Responses</title>
     4177    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     4178      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     4179      <address><email>fielding@gbiv.com</email></address>
     4180    </author>
     4181    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
     4182      <organization abbrev="W3C">World Wide Web Consortium</organization>
     4183      <address><email>ylafon@w3.org</email></address>
     4184    </author>
     4185    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
     4186      <organization abbrev="greenbytes">greenbytes GmbH</organization>
     4187      <address><email>julian.reschke@greenbytes.de</email></address>
     4188    </author>
     4189    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
     4190  </front>
     4191  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>
     4192  <x:source href="p5-range.xml" basename="p5-range">
     4193    <x:defines>Content-Range</x:defines>
    41594194  </x:source>
    41604195</reference>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1739 r1740  
    859859         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    860860         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    861          the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
    862          of error recovery could lead to dangerous consequences.
     861         the <a href="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
     862         could lead to dangerous consequences.
    863863      </p>
    864864      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    … …  
    890890      </p>
    891891      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#methods" class="smpl">method</a>         = <a href="#core.rules" class="smpl">token</a>
    892 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
    893          set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
     892</pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
     893         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not
     894            Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
    894895      </p>
    895896      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
    … …  
    954955      </p>
    955956      <p id="rfc.section.2.3.1.p.2">Responses to the OPTIONS method are not cacheable.</p>
    956       <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then
    957          the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
    958          to HTTP might use the OPTIONS body to make more detailed queries on the server.
     957      <p id="rfc.section.2.3.1.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
     958         body to make more detailed queries on the server.
    959959      </p>
    960960      <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.
    … …  
    966966         with that resource.
    967967      </p>
    968       <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,
    969          Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
     968      <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
    970969         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
    971970      </p>
    972       <p id="rfc.section.2.3.1.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
     971      <p id="rfc.section.2.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
    973972      </p>
    974973      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="GET" href="#GET">GET</a></h3>
    … …  
    10231022         the result.
    10241023      </p>
    1025       <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a Location header
    1026          field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
    1027       </p>
    1028       <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1024      <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
     1025      </p>
     1026      <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    10291027      </p>
    10301028      <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
    … …  
    10491047         related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
    10501048         with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an
    1051          appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on Content-Type values.
    1052       </p>
    1053       <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being
    1054          PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format
    1055          consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response
    1056          indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would
    1057          be a suitable target for the new representation.
    1058       </p>
     1049         appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values.
     1050      </p>
     1051      <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of:
     1052      </p>
     1053      <ol class="la">
     1054         <li>reconfigure the target resource to reflect the new media type;</li>
     1055         <li>transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state;
     1056            or,
     1057         </li>
     1058         <li>reject the request with a <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> response indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that
     1059            would be a suitable target for the new representation.
     1060         </li>
     1061      </ol>
    10591062      <p id="rfc.section.2.3.5.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent
    10601063         of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in
    … …  
    11081111      <div id="rfc.iref.t.1"></div>
    11091112      <div id="rfc.iref.m.7"></div>
    1110       <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a Max-Forwards value of zero (0) in
    1111          the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
     1113      <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    11121114      </p>
    11131115      <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1114          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    1115          client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    1116          infinite loop.
    1117       </p>
    1118       <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1116         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
     1117         messages in an infinite loop.
     1118      </p>
     1119      <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    11191120      </p>
    11201121      <div id="rfc.iref.c.2"></div>
    … …  
    11831184         double quotes will likely cause unnecessary confusion.
    11841185      </p>
    1185       <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;9.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
     1186      <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;9.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
    11861187         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
    11871188         it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section&nbsp;5.5</a>).
    … …  
    14001401         </li>
    14011402      </ul>
    1402       <p id="rfc.section.4.p.4">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's
    1403          media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;9.9</a>).
     1403      <p id="rfc.section.4.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;9.9</a>).
    14041404      </p>
    14051405      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    … …  
    17051705      <p id="rfc.section.4.4.2.p.1">The request has been fulfilled and has resulted in one or more new resources being created.</p>
    17061706      <p id="rfc.section.4.4.2.p.2">Newly created resources are typically linked to from the response payload, with the most relevant URI also being carried in
    1707          the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information
    1708          can be omitted (e.g., in the case of a response to a PUT request).
     1707         the <a href="#header.location" class="smpl">Location</a> header field. If the newly created resource's URI is the same as the Effective Request URI, this information can be omitted
     1708         (e.g., in the case of a response to a PUT request).
    17091709      </p>
    17101710      <p id="rfc.section.4.4.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
    17111711      </p>
    17121712      <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
    1713          the Location header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
     1713         the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    17141714      </p>
    17151715      <div id="rfc.iref.27"></div>
    … …  
    17751775      <ol>
    17761776         <li>
    1777             <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the Location header
    1778                field. In this specification, the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> fall under this category.
     1777            <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the <a href="#header.location" class="smpl">Location</a> header field. In this specification, the status codes <a href="#status.301" class="smpl">301
     1778                 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> fall under this category.
    17791779            </p>
    17801780         </li>
    … …  
    18011801         </p>
    18021802      </div>
    1803       <p id="rfc.section.4.5.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;9.13</a>.
     1803      <p id="rfc.section.4.5.p.4">A <a href="#header.location" class="smpl">Location</a> header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;9.13</a>.
    18041804      </p>
    18051805      <p id="rfc.section.4.5.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was
    … …  
    18231823         choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
    18241824      </p>
    1825       <p id="rfc.section.4.5.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.
     1825      <p id="rfc.section.4.5.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the <a href="#header.location" class="smpl">Location</a> field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection.
    18261826      </p>
    18271827      <p id="rfc.section.4.5.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.
    … …  
    18351835      <p id="rfc.section.4.5.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
    18361836      </p>
    1837       <p id="rfc.section.4.5.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
    1838          the new URI(s).
     1837      <p id="rfc.section.4.5.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s).
    18391838      </p>
    18401839      <div class="note" id="rfc.section.4.5.2.p.4">
    … …  
    18471846      <p id="rfc.section.4.5.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    18481847      </p>
    1849       <p id="rfc.section.4.5.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
    1850          the new URI(s).
     1848      <p id="rfc.section.4.5.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s).
    18511849      </p>
    18521850      <div class="note" id="rfc.section.4.5.3.p.3">
    … …  
    18581856      <h3 id="rfc.section.4.5.4"><a href="#rfc.section.4.5.4">4.5.4</a>&nbsp;<a id="status.303" href="#status.303">303 See Other</a></h3>
    18591857      <p id="rfc.section.4.5.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI
    1860          in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy
    1861          the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further,
     1858         in the <a href="#header.location" class="smpl">Location</a> header field, that is intended to provide an indirect response to the original request. In order to satisfy the original request,
     1859         a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further,
    18621860         and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is
    18631861         not considered equivalent to the effective request URI.
    … …  
    18681866      </p>
    18691867      <p id="rfc.section.4.5.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
    1870          transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such
    1871          that the follow-on representation might be useful to recipients without implying that it adequately represents the target
    1872          resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might
    1873          be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
    1874       </p>
    1875       <p id="rfc.section.4.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI.
     1868         transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> URI indicates a resource that is descriptive of the target resource, such that the follow-on representation might be useful
     1869         to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what
     1870         can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP
     1871         and thus entirely determined by the URI owner(s).
     1872      </p>
     1873      <p id="rfc.section.4.5.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the <a href="#header.location" class="smpl">Location</a> URI.
    18761874      </p>
    18771875      <div id="rfc.iref.36"></div>
    … …  
    18891887      <p id="rfc.section.4.5.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    18901888      </p>
    1891       <p id="rfc.section.4.5.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
    1892          the new URI(s).
     1889      <p id="rfc.section.4.5.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the <a href="#header.location" class="smpl">Location</a> field in the response. A response payload can contain a short hypertext note with a hyperlink to the new URI(s).
    18931890      </p>
    18941891      <div class="note" id="rfc.section.4.5.7.p.3">
    … …  
    19341931      <div id="rfc.iref.s.26"></div>
    19351932      <h3 id="rfc.section.4.6.5"><a href="#rfc.section.4.6.5">4.6.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    1936       <p id="rfc.section.4.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource.
     1933      <p id="rfc.section.4.6.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an <a href="#header.allow" class="smpl">Allow</a> header field containing a list of valid methods for the requested resource.
    19371934      </p>
    19381935      <div id="rfc.iref.45"></div>
    … …  
    19401937      <h3 id="rfc.section.4.6.6"><a href="#rfc.section.4.6.6">4.6.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
    19411938      <p id="rfc.section.4.6.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    1942          not acceptable according to the Accept and Accept-* header fields sent in the request.
     1939         not acceptable according to the <a href="#header.accept" class="smpl">Accept</a> and Accept-* header fields sent in the request.
    19431940      </p>
    19441941      <p id="rfc.section.4.6.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user
    … …  
    19991996         to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.
    20001997      </p>
    2001       <p id="rfc.section.4.6.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
     1998      <p id="rfc.section.4.6.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
    20021999      </p>
    20032000      <div id="rfc.iref.51"></div>
    … …  
    20192016      <div id="rfc.iref.s.35"></div>
    20202017      <h3 id="rfc.section.4.6.14"><a href="#rfc.section.4.6.14">4.6.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
    2021       <p id="rfc.section.4.6.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
     2018      <p id="rfc.section.4.6.14.p.1">The expectation given in an <a href="#header.expect" class="smpl">Expect</a> header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
    20222019         not be met by the next-hop server.
    20232020      </p>
    … …  
    20662063      <p id="rfc.section.4.7.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p>
    20672064      <p id="rfc.section.4.7.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the
    2068          delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;9.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
     2065         delay <em class="bcp14">MAY</em> be indicated in a <a href="#header.retry-after" class="smpl">Retry-After</a> header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;9.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a <a href="#status.500" class="smpl">500 (Internal
     2066            Server Error)</a> response.
    20692067      </p>
    20702068      <div class="note" id="rfc.section.4.7.4.p.3">
    … …  
    22012199         Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry.
    22022200      </p>
    2203       <p id="rfc.section.5.3.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
    2204          token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter
    2205          value of the charset parameter can be quoted.
     2201      <p id="rfc.section.5.3.p.5">HTTP uses charset in two contexts: within an <a href="#header.accept-charset" class="smpl">Accept-Charset</a> request header field (in which the charset value is an unquoted token) and as the value of a parameter in a <a href="#header.content-type" class="smpl">Content-Type</a> header field (within a request or response), in which case the parameter value of the charset parameter can be quoted.
    22062202      </p>
    22072203      <p id="rfc.section.5.3.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
    … …  
    22142210      </p>
    22152211      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#core.rules" class="smpl">token</a>
    2216 </pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;9.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;9.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
     2212</pre><p id="rfc.section.5.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;9.3</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;9.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
    22172213         mechanism will be required to remove the encoding.
    22182214      </p>
    … …  
    22512247      </p>
    22522248      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
    2253       <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;9.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;9.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
     2249      <p id="rfc.section.5.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;9.9</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;9.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
    22542250      </p>
    22552251      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
    … …  
    23052301      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="language.tags" href="#language.tags">Language Tags</a></h2>
    23062302      <p id="rfc.section.5.6.p.1">A language tag, as defined in <a href="#RFC5646" id="rfc.xref.RFC5646.1"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to
    2307          other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language
    2308          fields.
     2303         other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the <a href="#header.accept-language" class="smpl">Accept-Language</a> and <a href="#header.content-language" class="smpl">Content-Language</a> fields.
    23092304      </p>
    23102305      <p id="rfc.section.5.6.p.2">In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series
    … …  
    23672362         (request or response), the request method, the response status code, and the representation metadata. For example, the above
    23682363         semantic is true for the representation in any <a href="#status.200" class="smpl">200 (OK)</a> response to GET and for the representation in any PUT request. A 200 response to PUT, in contrast, contains either a representation
    2369          that describes the successful action or a representation of the target resource, with the latter indicated by a Content-Location
    2370          header field with the same value as the effective request URI. Likewise, response messages with an error status code usually
     2364         that describes the successful action or a representation of the target resource, with the latter indicated by a <a href="#header.content-location" class="smpl">Content-Location</a> header field with the same value as the effective request URI. Likewise, response messages with an error status code usually
    23712365         contain a representation that describes the error and what next steps are suggested for resolving it.
    23722366      </p>
    … …  
    23902384         <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
    23912385         </li>
    2392          <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
    2393             is a representation of the target resource.
    2394          </li>
    2395          <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response
    2396             asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
    2397             cannot be trusted unless it can be verified by other means (not defined by HTTP).
     2386         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is the same as the effective request URI, the response payload is a representation of the target
     2387            resource.
     2388         </li>
     2389         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation
     2390            of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified
     2391            by other means (not defined by HTTP).
    23982392         </li>
    23992393         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
    … …  
    24682462         the representation metadata header fields.
    24692463      </p>
    2470       <p id="rfc.section.7.3.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
    2471          a two-layer, ordered encoding model:
     2464      <p id="rfc.section.7.3.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model:
    24722465      </p>
    24732466      <div id="rfc.figure.u.23"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
    2474 </pre><p id="rfc.section.7.3.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
     2467</pre><p id="rfc.section.7.3.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
    24752468         body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown
    24762469         to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
    … …  
    24842477         such "content sniffing" when it is used.
    24852478      </p>
    2486       <p id="rfc.section.7.3.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
    2487          that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond
    2488          that defined by the Content-Type.
     2479      <p id="rfc.section.7.3.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
     2480         are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that
     2481         defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field.
    24892482      </p>
    24902483      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
    … …  
    25212514         to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
    25222515         (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    2523          improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.
     2516         improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response.
    25242517      </p>
    25252518      <p id="rfc.section.8.1.p.3">Server-driven negotiation has disadvantages: </p>
    … …  
    25432536      </p>
    25442537      <p id="rfc.section.8.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    2545          and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;9.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;9.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;9.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;9.4</a>), and User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;9.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
     2538         and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;9.1</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;9.2</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;9.3</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;9.4</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section&nbsp;9.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    25462539         within extension header fields not defined by this specification.
    25472540      </p>
    25482541      <div class="note" id="rfc.section.8.1.p.7">
    2549          <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
     2542         <p> <b>Note:</b> In practice, <a href="#header.user-agent" class="smpl">User-Agent</a> based negotiation is fragile, because new clients might not be recognized.
    25502543         </p>
    25512544      </div>
    … …  
    27912784      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    27922785      <p id="rfc.section.9.6.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
    2793          in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the
    2794          Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the
    2795          identity of its underlying media type.
     2786         in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of
     2787         its underlying media type.
    27962788      </p>
    27972789      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.41"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    … …  
    28072799         would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin
    28082800         server might choose to publish the same payload data as multiple representations that differ only in whether the coding is
    2809          defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each
    2810          response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content).
     2801         defined as part of <a href="#header.content-type" class="smpl">Content-Type</a> or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save
     2802         as ..." dialog instead of automatic decompression and rendering of content).
    28112803      </p>
    28122804      <p id="rfc.section.9.6.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;9.6</a>) that lists the content-coding(s) applied.
    … …  
    29992991      </p>
    30002992      <div class="note" id="rfc.section.9.13.p.9">
    3001          <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
     2993         <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    30022994            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    30032995         </p>
    … …  
    35913583               <tr>
    35923584                  <td class="left">identity</td>
    3593                   <td class="left">reserved (synonym for "no encoding" in Accept-Encoding header field)</td>
     3585                  <td class="left">reserved (synonym for "no encoding" in <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> header field)
     3586                  </td>
    35943587                  <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section&nbsp;9.3</a>
    35953588                  </td>
    … …  
    36073600         a priori method of determining the sensitivity of any particular piece of information within the context of any given request.
    36083601         Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth
    3609          special mention in this context: Server, Via, Referer and From.
     3602         special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>.
    36103603      </p>
    36113604      <p id="rfc.section.11.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    3612          against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option.
     3605         against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the <a href="#header.server" class="smpl">Server</a> header field a configurable option.
    36133606      </p>
    36143607      <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
    36153608         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
    36163609      </p>
    3617       <p id="rfc.section.11.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its
    3618          power can be abused if user details are not separated from the information contained in the Referer. Even when the personal
    3619          information has been removed, the Referer header field might indicate a private document's URI whose publication would be
    3620          inappropriate.
    3621       </p>
    3622       <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
    3623          hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
     3610      <p id="rfc.section.11.1.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can
     3611         be abused if user details are not separated from the information contained in the Referer. Even when the personal information
     3612         has been removed, the Referer header field might indicate a private document's URI whose publication would be inappropriate.
     3613      </p>
     3614      <p id="rfc.section.11.1.p.5">The information sent in the <a href="#header.from" class="smpl">From</a> field might conflict with the user's privacy interests or their site's security policy, and hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
    36243615      </p>
    36253616      <p id="rfc.section.11.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
    3626          of From and Referer information.
    3627       </p>
    3628       <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;9.18</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;9.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
     3617         of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information.
     3618      </p>
     3619      <p id="rfc.section.11.1.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;9.18</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;9.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
    36293620         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
    36303621         no better mechanism.
    36313622      </p>
    3632       <p id="rfc.section.11.1.p.8">Furthermore, the User-Agent header field might contain enough entropy to be used, possibly in conjunction with other material,
    3633          to uniquely identify the user.
     3623      <p id="rfc.section.11.1.p.8">Furthermore, the <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the
     3624         user.
    36343625      </p>
    36353626      <p id="rfc.section.11.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section&nbsp;2.3.7</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used
    … …  
    36383629      <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
    36393630      <p id="rfc.section.11.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
    3640          recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could
    3641          have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From
    3642          information.
    3643       </p>
    3644       <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
     3631         recommended that the user be able to select whether or not the <a href="#header.referer" class="smpl">Referer</a> field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively
     3632         enable/disable the sending of Referer and From information.
     3633      </p>
     3634      <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a <a href="#header.referer" class="smpl">Referer</a> header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
    36453635      </p>
    36463636      <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
    … …  
    36493639      </p>
    36503640      <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    3651       <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
    3652          to make sure that they do not attempt to invalidate resources over which they have no authority.
    3653       </p>
    3654       <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak
    3655          confidential information to the target server — although the fragment identifier is not transmitted in the final request,
    3656          it might be visible to the user agent through other means, such as scripting.
     3641      <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of <a href="#header.location" class="smpl">Location</a> and <a href="#header.content-location" class="smpl">Content-Location</a> header fields in responses that are generated under control of said organizations to make sure that they do not attempt to
     3642         invalidate resources over which they have no authority.
     3643      </p>
     3644      <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a <a href="#header.location" class="smpl">Location</a> header field might leak confidential information to the target server — although the fragment identifier is not transmitted
     3645         in the final request, it might be visible to the user agent through other means, such as scripting.
    36573646      </p>
    36583647      <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;Security Considerations for CONNECT
    … …  
    36623651      </p>
    36633652      <h2 id="rfc.section.11.5"><a href="#rfc.section.11.5">11.5</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    3664       <p id="rfc.section.11.5.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field
    3665          in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
    3666          languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
    3667          to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged to let the
    3668          configuration process include a message which makes the user aware of the loss of privacy involved.
     3653      <p id="rfc.section.11.5.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding
     3654         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
     3655         the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
     3656         to let the configuration process include a message which makes the user aware of the loss of privacy involved.
    36693657      </p>
    36703658      <p id="rfc.section.11.5.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
    … …  
    39123900      </p>
    39133901      <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;5.5.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of
    3914          a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10
    3915          to represent CR and LF, respectively, as is the case for some multi-byte character encodings.
     3902         a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10 to represent CR and
     3903         LF, respectively, as is the case for some multi-byte character encodings.
    39163904      </p>
    39173905      <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in
    … …  
    39193907      </p>
    39203908      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
    3921       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section&nbsp;5.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     3909      <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section&nbsp;5.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any <a href="#header.date" class="smpl">Date</a> header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    39223910      </p>
    39233911      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
    3924       <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on
    3925          the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some
    3926          experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;"
    3927          to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
     3912      <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's <a href="#header.content-encoding" class="smpl">Content-Encoding</a> header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the <a href="#header.content-type" class="smpl">Content-Type</a> header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for
     3913         Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform a function equivalent to Content-Encoding.
     3914         However, this parameter is not part of the MIME standards).
    39283915      </p>
    39293916      <div id="rfc.iref.c.11"></div>
    … …  
    39713958      </p>
    39723959      <p id="rfc.section.C.p.8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through
    3973          the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient was expected to repeat
    3974          this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
     3960         the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The Location field gave the URI of the proxy. The recipient was expected to repeat this single request via the proxy.
     3961         (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
    39753962      </p>
    39763963      <p id="rfc.section.C.p.9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
    … …  
    39783965      <p id="rfc.section.C.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    39793966      </p>
    3980       <p id="rfc.section.C.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
    3981          on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.5</a>)
    3982       </p>
    3983       <p id="rfc.section.C.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified
    3984          (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;9.11</a>)
    3985       </p>
    3986       <p id="rfc.section.C.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
    3987          symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    3988          (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;9.13</a>)
    3989       </p>
    3990       <p id="rfc.section.C.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.14</a>)
    3991       </p>
    3992       <p id="rfc.section.C.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.15</a>)
    3993       </p>
    3994       <p id="rfc.section.C.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    3995          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.60"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.17</a>)
     3967      <p id="rfc.section.C.p.11">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents
     3968         of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.5</a>)
     3969      </p>
     3970      <p id="rfc.section.C.p.12">The ABNF for the <a href="#header.expect" class="smpl">Expect</a> header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing
     3971         semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;9.11</a>)
     3972      </p>
     3973      <p id="rfc.section.C.p.13">Correct syntax of <a href="#header.location" class="smpl">Location</a> header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't
     3974         what was expected, and add some clarifications as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;9.13</a>)
     3975      </p>
     3976      <p id="rfc.section.C.p.14">Restrict <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.14</a>)
     3977      </p>
     3978      <p id="rfc.section.C.p.15">Allow <a href="#header.referer" class="smpl">Referer</a> field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.15</a>)
     3979      </p>
     3980      <p id="rfc.section.C.p.16">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.60"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.17</a>)
    39963981      </p>
    39973982      <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;5.3</a>)
    … …  
    40073992         and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    40083993      </p>
    4009       <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section&nbsp;9.2</a>)
    4010       </p>
    4011       <p id="rfc.section.C.p.23">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
    4012          servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking
    4013          relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;9.8</a>)
     3994      <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in <a href="#header.accept-charset" class="smpl">Accept-Charset</a>. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section&nbsp;9.2</a>)
     3995      </p>
     3996      <p id="rfc.section.C.p.23">Remove base URI setting semantics for <a href="#header.content-location" class="smpl">Content-Location</a> due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,
     3997         and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;9.8</a>)
    40143998      </p>
    40153999      <p id="rfc.section.C.p.24">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1739 r1740  
    305305   impact on security. This is because different uses of the protocol require
    306306   different error handling strategies; for example, a Web browser might wish to
    307    transparently recover from a response where the Location header field
    308    doesn't parse according to the ABNF, whereby in a systems control protocol
    309    using HTTP, this type of error recovery could lead to dangerous consequences.
     307   transparently recover from a response where the <x:ref>Location</x:ref>
     308   header field doesn't parse according to the ABNF, whereby in a systems
     309   control protocol using HTTP, this type of error recovery could lead to
     310   dangerous consequences.
    310311</t>
    311312</section>
    … …  
    388389<t>
    389390   The list of methods allowed by a resource can be specified in an
    390    Allow header field (<xref target="header.allow"/>). The status code of the response
    391    always notifies the client whether a method is currently allowed on a
    392    resource, since the set of allowed methods can change dynamically. An
    393    origin server &SHOULD; respond with the status code <x:ref>405 (Method Not Allowed)</x:ref>
    394    if the method is known by the origin server but not allowed for the
    395    resource, and <x:ref>501 (Not Implemented)</x:ref> if the method is
    396    unrecognized or not implemented by the origin server. The methods GET
    397    and HEAD &MUST; be supported by all general-purpose servers. All other
    398    methods are &OPTIONAL;; however, if the above methods are implemented,
    399    they &MUST; be implemented with the same semantics as those specified
    400    in <xref target="method.definitions"/>.
     391   <x:ref>Allow</x:ref> header field (<xref target="header.allow"/>). The
     392   status code of the response always notifies the client whether a method is
     393   currently allowed on a resource, since the set of allowed methods can change
     394   dynamically. An origin server &SHOULD; respond with the status code
     395   <x:ref>405 (Method Not Allowed)</x:ref> if the method is known by the origin
     396   server but not allowed for the resource, and <x:ref>501 (Not
     397   Implemented)</x:ref> if the method is unrecognized or not implemented by the
     398   origin server. The methods GET and HEAD &MUST; be supported by all
     399   general-purpose servers. All other methods are &OPTIONAL;; however, if the
     400   above methods are implemented, they &MUST; be implemented with the same
     401   semantics as those specified in <xref target="method.definitions"/>.
    401402</t>
    402403
    … …  
    520521<t>
    521522   If the OPTIONS request includes a message body (as indicated by the
    522    presence of Content-Length or Transfer-Encoding), then the media type
    523    &MUST; be indicated by a Content-Type field. Although this
    524    specification does not define any use for such a body, future
    525    extensions to HTTP might use the OPTIONS body to make more detailed
     523   presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>),
     524   then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref>
     525   field. Although this specification does not define any use for such a body,
     526   future extensions to HTTP might use the OPTIONS body to make more detailed
    526527   queries on the server.
    527528</t>
    … …  
    544545   A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that
    545546   indicate optional features implemented by the server and applicable to that
    546    resource (e.g., Allow), possibly including extensions not defined by
    547    this specification. The response body, if any, &SHOULD; also include
    548    information about the communication options. The format for such a
     547   resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not
     548   defined by this specification. The response body, if any, &SHOULD; also
     549   include information about the communication options. The format for such a
    549550   body is not defined by this specification, but might be defined by
    550551   future extensions to HTTP. Content negotiation &MAY; be used to select
    … …  
    554555</t>
    555556<t>
    556    The Max-Forwards header field &MAY; be used to target a
     557   The <x:ref>Max-Forwards</x:ref> header field &MAY; be used to target a
    557558   specific proxy in the request chain (see <xref target="header.max-forwards"/>).
    558559   If no Max-Forwards field is present in the request, then the forwarded
    … …  
    681682   &SHOULD; be <x:ref>201 (Created)</x:ref> and contain a representation which
    682683   describes the status of the request and refers to the new resource, and a
    683    Location header field (see <xref target="header.location"/>).
     684   <x:ref>Location</x:ref> header field (see <xref target="header.location"/>).
    684685</t>
    685686<t>
    686687   Responses to POST requests are only cacheable when they
    687688   include explicit freshness information (see &p6-explicit;). A
    688    cached POST response with a Content-Location header field
     689   cached POST response with a <x:ref>Content-Location</x:ref> header field
    689690   (see &header-content-location;) whose value is the effective
    690691   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
    … …  
    740741   representation or changing the resource configuration, or respond
    741742   with an appropriate error message containing sufficient information
    742    to explain why the representation is unsuitable.  The <x:ref>409 (Conflict)</x:ref>
    743    or <x:ref>415 (Unsupported Media Type)</x:ref> status codes are suggested, with the
    744    latter being specific to constraints on Content-Type values.
     743   to explain why the representation is unsuitable.  The
     744   <x:ref>409 (Conflict)</x:ref> or <x:ref>415 (Unsupported Media Type)</x:ref>
     745   status codes are suggested, with the latter being specific to constraints on
     746   <x:ref>Content-Type</x:ref> values.
    745747</t>
    746748<t>
    747749   For example, if the target resource is configured to always have a
    748    Content-Type of "text/html" and the representation being PUT has a
    749    Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
    750    (a) reconfigure the target resource to reflect the new media type;
    751    (b) transform the PUT representation to a format consistent with that
    752    of the resource before saving it as the new resource state; or,
    753    (c) reject the request with a 415 response indicating that the target
    754    resource is limited to "text/html", perhaps including a link to a
    755    different resource that would be a suitable target for the new
    756    representation.
     750   <x:ref>Content-Type</x:ref> of "text/html" and the representation being PUT
     751   has a Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
     752   <list style="letters">
     753      <t>reconfigure the target resource to reflect the new media type;</t>
     754      <t>transform the PUT representation to a format consistent with that
     755         of the resource before saving it as the new resource state; or,</t>
     756      <t>reject the request with a <x:ref>415 (Unsupported Media Type)</x:ref>
     757         response indicating that the target resource is limited to "text/html",
     758         perhaps including a link to a different resource that would be a
     759         suitable target for the new representation.</t>
     760   </list>
    757761</t>
    758762<t>
    … …  
    870874   &SHOULD; reflect the message received back to the client as the message body
    871875   of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the
    872    origin server or the first proxy to receive a Max-Forwards
     876   origin server or the first proxy to receive a <x:ref>Max-Forwards</x:ref>
    873877   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
    874878   A TRACE request &MUST-NOT; include a message body.
    … …  
    879883   information. The value of the Via header field (&header-via;) is of
    880884   particular interest, since it acts as a trace of the request chain.
    881    Use of the Max-Forwards header field allows the client to limit the
    882    length of the request chain, which is useful for testing a chain of
     885   Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
     886   limit the length of the request chain, which is useful for testing a chain of
    883887   proxies forwarding messages in an infinite loop.
    884888</t>
    885889<t>
    886    If the request is valid, the response &SHOULD; have a Content-Type of
    887    "message/http" (see &media-type-message-http;) and contain a message body
    888    that encloses a copy of the entire request message.
     890   If the request is valid, the response &SHOULD; have a
     891   <x:ref>Content-Type</x:ref> of "message/http" (see &media-type-message-http;)
     892   and contain a message body that encloses a copy of the entire request message.
    889893   Responses to the TRACE method are not cacheable.
    890894</t>
    … …  
    10231027<t>
    10241028   Many header fields use a format including (case-insensitively) named
    1025    parameters (for instance, Content-Type, defined in &header-content-type;).
    1026    Allowing both unquoted (token) and quoted (quoted-string) syntax for the
    1027    parameter value enables recipients to use existing parser components. When
    1028    allowing both forms, the meaning of a parameter value ought to be
    1029    independent of the syntax used for it (for an example, see the notes on
    1030    parameter handling for media types in &media-types;).
     1029   parameters (for instance, <x:ref>Content-Type</x:ref>, defined in
     1030   &header-content-type;). Allowing both unquoted (token) and quoted
     1031   (quoted-string) syntax for the parameter value enables recipients to use
     1032   existing parser components. When allowing both forms, the meaning of a
     1033   parameter value ought to be independent of the syntax used for it (for an
     1034   example, see the notes on parameter handling for media types in
     1035   &media-types;).
    10311036</t>
    10321037<t>
    … …  
    11731178<t>
    11741179   For most status codes the response can carry a payload, in which case a
    1175    Content-Type header field indicates the payload's media type
     1180   <x:ref>Content-Type</x:ref> header field indicates the payload's media type
    11761181   (&header-content-type;).
    11771182</t>
    … …  
    14081413<t>
    14091414   Newly created resources are typically linked to from the response payload,
    1410    with the most relevant URI also being carried in the Location header field.
    1411    If the newly created resource's URI is the same as the Effective Request URI,
    1412    this information can be omitted (e.g., in the case of a response to a PUT
    1413    request). 
     1415   with the most relevant URI also being carried in the <x:ref>Location</x:ref>
     1416   header field. If the newly created resource's URI is the same as the
     1417   Effective Request URI, this information can be omitted (e.g., in the case of
     1418   a response to a PUT request). 
    14141419</t>
    14151420<t>
    … …  
    14211426   A 201 response &MAY; contain an <x:ref>ETag</x:ref> response header field
    14221427   indicating the current value of the entity-tag for the representation of the
    1423    resource identified by the Location header field or, in case the Location
    1424    header field was omitted, by the Effective Request URI (see &header-etag;).
     1428   resource identified by the <x:ref>Location</x:ref> header field or, in case
     1429   the Location header field was omitted, by the Effective Request URI (see
     1430   &header-etag;).
    14251431</t>
    14261432</section>
    … …  
    15471553        <t>
    15481554          Redirects of the request to another URI, either temporarily or
    1549           permanently. The new URI is specified in the Location header field.
    1550           In this specification, the status codes <x:ref>301 (Moved Permanently)</x:ref>,
    1551           <x:ref>302 (Found)</x:ref>, and <x:ref>307 (Temporary Redirect)</x:ref>
    1552           fall under this category.
     1555          permanently. The new URI is specified in the <x:ref>Location</x:ref>
     1556          header field. In this specification, the status codes <x:ref>301
     1557          (Moved Permanently)</x:ref>, <x:ref>302 (Found)</x:ref>, and
     1558          <x:ref>307 (Temporary Redirect)</x:ref> fall under this category.
    15531559        </t>
    15541560      </x:lt>
    … …  
    15951601</x:note>
    15961602<t>
    1597    A Location header field on a 3xx response indicates that a client &MAY;
    1598    automatically redirect to the URI provided; see <xref target="header.location"/>.
     1603   A <x:ref>Location</x:ref> header field on a 3xx response indicates that a
     1604   client &MAY; automatically redirect to the URI provided; see
     1605   <xref target="header.location"/>.
    15991606</t>
    16001607<t>
    … …  
    16381645<t>
    16391646   If the server has a preferred choice of representation, it &SHOULD;
    1640    include the specific URI for that representation in the Location
     1647   include the specific URI for that representation in the <x:ref>Location</x:ref>
    16411648   field; user agents &MAY; use the Location field value for automatic
    16421649   redirection.
    … …  
    16661673</t>
    16671674<t>
    1668    The new permanent URI &SHOULD; be given by the Location field in the
    1669    response. A response payload can contain a short hypertext note with a
     1675   The new permanent URI &SHOULD; be given by the <x:ref>Location</x:ref> field
     1676   in the response. A response payload can contain a short hypertext note with a
    16701677   hyperlink to the new URI(s).
    16711678</t>
    … …  
    16911698</t>
    16921699<t>
    1693    The temporary URI &SHOULD; be given by the Location field in the
    1694    response. A response payload can contain a short hypertext note with a
     1700   The temporary URI &SHOULD; be given by the <x:ref>Location</x:ref> field in
     1701   the response. A response payload can contain a short hypertext note with a
    16951702   hyperlink to the new URI(s).
    16961703</t>
    … …  
    17121719   The 303 status code indicates that the server is redirecting the
    17131720   user agent to a different resource, as indicated by a URI in the
    1714    Location header field, that is intended to provide an indirect
     1721   <x:ref>Location</x:ref> header field, that is intended to provide an indirect
    17151722   response to the original request.  In order to satisfy the original
    17161723   request, a user agent &SHOULD; perform a retrieval request using the
    … …  
    17321739   A 303 response to a GET request indicates that the requested
    17331740   resource does not have a representation of its own that can be
    1734    transferred by the server over HTTP.  The Location URI indicates a
    1735    resource that is descriptive of the target resource, such that the
    1736    follow-on representation might be useful to recipients without
     1741   transferred by the server over HTTP.  The <x:ref>Location</x:ref> URI
     1742   indicates a resource that is descriptive of the target resource, such that
     1743   the follow-on representation might be useful to recipients without
    17371744   implying that it adequately represents the target resource.
    17381745   Note that answers to the questions of what can be represented, what
    … …  
    17441751   Except for responses to a HEAD request, the representation of a 303
    17451752   response &SHOULD; contain a short hypertext note with a hyperlink
    1746    to the Location URI.
     1753   to the <x:ref>Location</x:ref> URI.
    17471754</t>
    17481755</section>
    … …  
    17781785</t>
    17791786<t>
    1780    The temporary URI &SHOULD; be given by the Location field in the
    1781    response. A response payload can contain a short hypertext note with a
     1787   The temporary URI &SHOULD; be given by the <x:ref>Location</x:ref> field in
     1788   the response. A response payload can contain a short hypertext note with a
    17821789   hyperlink to the new URI(s).
    17831790</t>
    … …  
    18671874<t>
    18681875   The method specified in the request-line is not allowed for the target
    1869    resource. The response &MUST; include an Allow header field containing a
    1870    list of valid methods for the requested resource.
     1876   resource. The response &MUST; include an <x:ref>Allow</x:ref> header field
     1877   containing a list of valid methods for the requested resource.
    18711878</t>
    18721879</section>
    … …  
    18791886   The resource identified by the request is only capable of generating
    18801887   response representations which have content characteristics not acceptable
    1881    according to the Accept and Accept-* header fields sent in the request.
     1888   according to the <x:ref>Accept</x:ref> and Accept-* header fields sent in
     1889   the request.
    18821890</t>
    18831891<t>
    … …  
    19932001</t>
    19942002<t>
    1995    If the condition is temporary, the server &SHOULD; include a Retry-After
    1996    header field to indicate that it is temporary and after what
    1997    time the client &MAY; try again.
     2003   If the condition is temporary, the server &SHOULD; include a
     2004   <x:ref>Retry-After</x:ref> header field to indicate that it is temporary and
     2005   after what time the client &MAY; try again.
    19982006</t>
    19992007</section>
    … …  
    20322040  <x:anchor-alias value="417 (Expectation Failed)"/>
    20332041<t>
    2034    The expectation given in an Expect header field (see <xref target="header.expect"/>)
    2035    could not be met by this server, or, if the server is a proxy,
    2036    the server has unambiguous evidence that the request could not be met
    2037    by the next-hop server.
     2042   The expectation given in an <x:ref>Expect</x:ref> header field (see
     2043   <xref target="header.expect"/>) could not be met by this server, or, if the
     2044   server is a proxy, the server has unambiguous evidence that the request
     2045   could not be met by the next-hop server.
    20382046</t>
    20392047</section>
    … …  
    21262134   The implication is that this is a temporary condition which will be
    21272135   alleviated after some delay. If known, the length of the delay &MAY; be
    2128    indicated in a Retry-After header field (<xref target="header.retry-after"/>).
    2129    If no Retry-After is given, the client &SHOULD; handle the response as it
    2130    would for a 500 response.
     2136   indicated in a <x:ref>Retry-After</x:ref> header field
     2137   (<xref target="header.retry-after"/>). If no Retry-After is given, the
     2138   client &SHOULD; handle the response as it would for a <x:ref>500 (Internal
     2139   Server Error)</x:ref> response.
    21312140</t>
    21322141<x:note>
    … …  
    23752384</t>
    23762385<t>
    2377    HTTP uses charset in two contexts: within an Accept-Charset request
    2378    header field (in which the charset value is an unquoted token) and as the
    2379    value of a parameter in a Content-Type header field (within a request or
    2380    response), in which case the parameter value of the charset parameter
    2381    can be quoted.
     2386   HTTP uses charset in two contexts: within an <x:ref>Accept-Charset</x:ref>
     2387   request header field (in which the charset value is an unquoted token) and
     2388   as the value of a parameter in a <x:ref>Content-Type</x:ref> header field
     2389   (within a request or response), in which case the parameter value of the
     2390   charset parameter can be quoted.
    23822391</t>
    23832392<t>
    … …  
    24022411<t>
    24032412   All content-coding values are case-insensitive. HTTP/1.1 uses
    2404    content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
    2405    Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
     2413   content-coding values in the <x:ref>Accept-Encoding</x:ref>
     2414   (<xref target="header.accept-encoding"/>) and <x:ref>Content-Encoding</x:ref>
     2415   (<xref target="header.content-encoding"/>) header fields. Although the value
    24062416   describes the content-coding, what is more important is that it
    24072417   indicates what decoding mechanism will be required to remove the
    … …  
    24702480  <x:anchor-alias value="subtype"/>
    24712481<t>
    2472    HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>)
    2473    and Accept (<xref target="header.accept"/>) header fields in order to provide
    2474    open and extensible data typing and type negotiation.
     2482   HTTP uses Internet Media Types <xref target="RFC2046"/> in the
     2483   <x:ref>Content-Type</x:ref> (<xref target="header.content-type"/>)
     2484   and <x:ref>Accept</x:ref> (<xref target="header.accept"/>) header fields in
     2485   order to provide open and extensible data typing and type negotiation.
    24752486</t>
    24762487<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
    … …  
    25852596   natural language spoken, written, or otherwise conveyed by human beings for
    25862597   communication of information to other human beings. Computer languages are
    2587    explicitly excluded. HTTP uses language tags within the Accept-Language and
    2588    Content-Language fields.
     2598   explicitly excluded. HTTP uses language tags within the
     2599   <x:ref>Accept-Language</x:ref> and <x:ref>Content-Language</x:ref> fields.
    25892600</t>
    25902601<t>
    … …  
    26752686   A 200 response to PUT, in contrast, contains either a representation
    26762687   that describes the successful action or a representation of the target
    2677    resource, with the latter indicated by a Content-Location header field
    2678    with the same value as the effective request URI.  Likewise, response
    2679    messages with an error status code usually contain a representation that
    2680    describes the error and what next steps are suggested for resolving it.
     2688   resource, with the latter indicated by a <x:ref>Content-Location</x:ref>
     2689   header field with the same value as the effective request URI.  Likewise,
     2690   response messages with an error status code usually contain a representation
     2691   that describes the error and what next steps are suggested for resolving it.
    26812692</t>
    26822693<t>
    … …  
    27172728   and the request method was GET or HEAD, the response payload is a partial
    27182729   representation of the target resource.</t>
    2719    <t>If the response has a Content-Location header field, and that URI is the same
    2720    as the effective request URI, the response payload is a representation of the
    2721    target resource.</t>
    2722    <t>If the response has a Content-Location header field, and that URI is not the
    2723    same as the effective request URI, then the response asserts that its
    2724    payload is a representation of the resource identified by the
    2725    Content-Location URI. However, such an assertion cannot be trusted unless
     2730   <t>If the response has a <x:ref>Content-Location</x:ref> header field, and
     2731   that URI is the same as the effective request URI, the response payload is a
     2732   representation of the target resource.</t>
     2733   <t>If the response has a <x:ref>Content-Location</x:ref> header field, and
     2734   that URI is not the same as the effective request URI, then the response
     2735   asserts that its payload is a representation of the resource identified by
     2736   the Content-Location URI. However, such an assertion cannot be trusted unless
    27262737   it can be verified by other means (not defined by HTTP).</t>
    27272738   <t>Otherwise, the response is a representation of an anonymous (i.e.,
    … …  
    27822793</t>
    27832794<t>
    2784    The data type of the representation data
    2785    is determined via the header fields Content-Type and Content-Encoding.
     2795   The data type of the representation data is determined via the header fields
     2796   <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
    27862797   These define a two-layer, ordered encoding model:
    27872798</t>
    … …  
    27902801</artwork></figure>
    27912802<t>
    2792    Content-Type specifies the media type of the underlying data, which
    2793    defines both the data format and how that data &SHOULD; be processed
     2803   <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,
     2804   which defines both the data format and how that data &SHOULD; be processed
    27942805   by the recipient (within the scope of the request method semantics).
    27952806   Any HTTP/1.1 message containing a payload body &SHOULD; include a
    … …  
    28152826</t>
    28162827<t>
    2817    Content-Encoding is used to indicate any additional content
     2828   <x:ref>Content-Encoding</x:ref> is used to indicate any additional content
    28182829   codings applied to the data, usually for the purpose of data
    28192830   compression, that are a property of the representation.  If
    28202831   Content-Encoding is not present, then there is no additional
    2821    encoding beyond that defined by the Content-Type.
     2832   encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
    28222833</t>
    28232834</section>
    … …  
    28872898   avoid the round-trip delay of a subsequent request if the "best
    28882899   guess" is good enough for the user). In order to improve the server's
    2889    guess, the user agent &MAY; include request header fields (Accept,
    2890    Accept-Language, Accept-Encoding, etc.) which describe its
     2900   guess, the user agent &MAY; include request header fields (<x:ref>Accept</x:ref>,
     2901   <x:ref>Accept-Language</x:ref>, <x:ref>Accept-Encoding</x:ref>, etc.) which describe its
    28912902   preferences for such a response.
    28922903</t>
    … …  
    29312942   HTTP/1.1 includes the following header fields for enabling
    29322943   server-driven negotiation through description of user agent
    2933    capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
    2934    (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language
    2935    (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;).
     2944   capabilities and user preferences: <x:ref>Accept</x:ref>
     2945   (<xref target="header.accept"/>), <x:ref>Accept-Charset</x:ref>
     2946   (<xref target="header.accept-charset"/>), <x:ref>Accept-Encoding</x:ref>
     2947   (<xref target="header.accept-encoding"/>), <x:ref>Accept-Language</x:ref>
     2948   (<xref target="header.accept-language"/>), and <x:ref>User-Agent</x:ref>
     2949   (&header-user-agent;).
    29362950   However, an origin server is not limited to these dimensions and &MAY; vary
    29372951   the response based on any aspect of the request, including aspects
    … …  
    29412955<x:note>
    29422956  <t>
    2943     &Note; In practice, User-Agent based negotiation is fragile,
     2957    &Note; In practice, <x:ref>User-Agent</x:ref> based negotiation is fragile,
    29442958    because new clients might not be recognized.
    29452959  </t>
    … …  
    33493363   have been applied to the representation beyond those inherent in the media
    33503364   type, and thus what decoding mechanisms have to be applied in order to obtain
    3351    the media-type referenced by the Content-Type header field.
     3365   the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
    33523366   Content-Encoding is primarily used to allow a representation to be
    33533367   compressed without losing the identity of its underlying media type.
    … …  
    33783392   representation.  Likewise, an origin server might choose to publish the
    33793393   same payload data as multiple representations that differ only in whether
    3380    the coding is defined as part of Content-Type or Content-Encoding, since
    3381    some user agents will behave differently in their handling of each
    3382    response (e.g., open a "Save as ..." dialog instead of automatic
    3383    decompression and rendering of content).
     3394   the coding is defined as part of <x:ref>Content-Type</x:ref> or
     3395   Content-Encoding, since some user agents will behave differently in their
     3396   handling of each response (e.g., open a "Save as ..." dialog instead of
     3397   automatic decompression and rendering of content).
    33843398</t>
    33853399<t>
    … …  
    37803794<x:note>
    37813795  <t>
    3782     &Note; The Content-Location header field (&header-content-location;) differs
    3783     from Location in that the Content-Location identifies the most specific
    3784     resource corresponding to the enclosed representation.
    3785     It is therefore possible for a response to contain header fields for
    3786     both Location and Content-Location.
     3796    &Note; The <x:ref>Content-Location</x:ref> header field
     3797    (&header-content-location;) differs from Location in that the
     3798    Content-Location identifies the most specific resource corresponding to the
     3799    enclosed representation. It is therefore possible for a response to contain
     3800    header fields for both Location and Content-Location.
    37873801  </t>
    37883802</x:note>
    … …  
    44244438   </c>
    44254439   <c>identity</c>
    4426    <c>reserved (synonym for "no encoding" in Accept-Encoding header field)</c>
     4440   <c>reserved (synonym for "no encoding" in <x:ref>Accept-Encoding</x:ref>
     4441   header field)</c>
    44274442   <c>
    44284443      <xref target="header.accept-encoding"/>
    … …  
    44504465   applications &SHOULD; supply as much control over this information as
    44514466   possible to the provider of that information. Four header fields are
    4452    worth special mention in this context: Server, Via, Referer and From.
     4467   worth special mention in this context: <x:ref>Server</x:ref>,
     4468   <x:ref>Via</x:ref>, <x:ref>Referer</x:ref> and <x:ref>From</x:ref>.
    44534469</t>
    44544470<t>
    … …  
    44564472   server machine to become more vulnerable to attacks against software
    44574473   that is known to contain security holes. Implementors &SHOULD; make the
    4458    Server header field a configurable option.
     4474   <x:ref>Server</x:ref> header field a configurable option.
    44594475</t>
    44604476<t>
    … …  
    44664482</t>
    44674483<t>
    4468    The Referer header field allows reading patterns to be studied and reverse
    4469    links drawn. Although it can be very useful, its power can be abused
    4470    if user details are not separated from the information contained in
    4471    the Referer. Even when the personal information has been removed, the
    4472    Referer header field might indicate a private document's URI whose
    4473    publication would be inappropriate.
    4474 </t>
    4475 <t>
    4476    The information sent in the From field might conflict with the user's
    4477    privacy interests or their site's security policy, and hence it
     4484   The <x:ref>Referer</x:ref> header field allows reading patterns to be
     4485   studied and reverse links drawn. Although it can be very useful, its power
     4486   can be abused if user details are not separated from the information
     4487   contained in the Referer. Even when the personal information has been
     4488   removed, the Referer header field might indicate a private document's URI
     4489   whose publication would be inappropriate.
     4490</t>
     4491<t>
     4492   The information sent in the <x:ref>From</x:ref> field might conflict with
     4493   the user's privacy interests or their site's security policy, and hence it
    44784494   &SHOULD-NOT;  be transmitted without the user being able to disable,
    44794495   enable, and modify the contents of the field. The user &MUST; be able
    … …  
    44834499<t>
    44844500   We suggest, though do not require, that a convenient toggle interface
    4485    be provided for the user to enable or disable the sending of From and
    4486    Referer information.
    4487 </t>
    4488 <t>
    4489    The User-Agent (<xref target="header.user-agent"/>) or Server (<xref
    4490    target="header.server"/>) header fields can sometimes be used to determine
    4491    that a specific client or server has a particular security hole which might
    4492    be exploited. Unfortunately, this same information is often used for other
    4493    valuable purposes for which HTTP currently has no better mechanism.
    4494 </t>
    4495 <t>
    4496    Furthermore, the User-Agent header field might contain enough entropy to be
    4497    used, possibly in conjunction with other material, to uniquely identify the
    4498    user.
     4501   be provided for the user to enable or disable the sending of
     4502   <x:ref>From</x:ref> and <x:ref>Referer</x:ref> information.
     4503</t>
     4504<t>
     4505   The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or
     4506   <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields can
     4507   sometimes be used to determine that a specific client or server has a
     4508   particular security hole which might be exploited. Unfortunately, this same
     4509   information is often used for other valuable purposes for which HTTP
     4510   currently has no better mechanism.
     4511</t>
     4512<t>
     4513   Furthermore, the <x:ref>User-Agent</x:ref> header field might contain enough
     4514   entropy to be used, possibly in conjunction with other material, to uniquely
     4515   identify the user.
    44994516</t>
    45004517<t>
    … …  
    45124529   reveal an otherwise private information source, it is strongly
    45134530   recommended that the user be able to select whether or not the
    4514    Referer field is sent. For example, a browser client could have a
    4515    toggle switch for browsing openly/anonymously, which would
     4531   <x:ref>Referer</x:ref> field is sent. For example, a browser client could
     4532   have a toggle switch for browsing openly/anonymously, which would
    45164533   respectively enable/disable the sending of Referer and From
    45174534   information.
    45184535</t>
    45194536<t>
    4520    Clients &SHOULD-NOT; include a Referer header field in a (non-secure)
    4521    HTTP request if the referring page was transferred with a secure
     4537   Clients &SHOULD-NOT; include a <x:ref>Referer</x:ref> header field in a
     4538   (non-secure) HTTP request if the referring page was transferred with a secure
    45224539   protocol.
    45234540</t>
    … …  
    45344551<t>
    45354552   If a single server supports multiple organizations that do not trust
    4536    one another, then it &MUST; check the values of Location and Content-Location
    4537    header fields in responses that are generated under control of
    4538    said organizations to make sure that they do not attempt to
    4539    invalidate resources over which they have no authority.
     4553   one another, then it &MUST; check the values of <x:ref>Location</x:ref> and
     4554   <x:ref>Content-Location</x:ref> header fields in responses that are
     4555   generated under control of said organizations to make sure that they do not
     4556   attempt to invalidate resources over which they have no authority.
    45404557</t>
    45414558<t>
    45424559   Furthermore, appending the fragment identifier from one URI to another
    4543    one obtained from a Location header field might leak confidential
    4544    information to the target server &mdash; although the fragment identifier is
    4545    not transmitted in the final request, it might be visible to the user agent
    4546    through other means, such as scripting.
     4560   one obtained from a <x:ref>Location</x:ref> header field might leak
     4561   confidential information to the target server &mdash; although the fragment
     4562   identifier is not transmitted in the final request, it might be visible to
     4563   the user agent through other means, such as scripting.
    45474564</t>
    45484565</section>
    … …  
    45614578<t>
    45624579   Accept header fields can reveal information about the user to all
    4563    servers which are accessed. The Accept-Language header field in particular
    4564    can reveal information the user would consider to be of a private
    4565    nature, because the understanding of particular languages is often
     4580   servers which are accessed. The <x:ref>Accept-Language</x:ref> header field
     4581   in particular can reveal information the user would consider to be of a
     4582   private nature, because the understanding of particular languages is often
    45664583   strongly correlated to the membership of a particular ethnic group.
    45674584   User agents which offer the option to configure the contents of an
    … …  
    46274644  </front>
    46284645  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
    4629   <x:source href="p1-messaging.xml" basename="p1-messaging"/>
     4646  <x:source href="p1-messaging.xml" basename="p1-messaging">
     4647    <x:defines>Content-Length</x:defines>
     4648    <x:defines>Transfer-Encoding</x:defines>
     4649    <x:defines>Via</x:defines>
     4650  </x:source>
    46304651</reference>
    46314652
    … …  
    53615382   environment &SHOULD; translate all line breaks within the text media
    53625383   types described in <xref target="canonicalization.and.text.defaults"/>
    5363    of this document to the RFC 2049
    5364    canonical form of CRLF. Note, however, that this might be complicated
    5365    by the presence of a Content-Encoding and by the fact that HTTP
    5366    allows the use of some character encodings which do not use octets 13 and
    5367    10 to represent CR and LF, respectively, as is the case for some multi-byte
    5368    character encodings.
     5384   of this document to the RFC 2049 canonical form of CRLF. Note, however, that
     5385   this might be complicated by the presence of a <x:ref>Content-Encoding</x:ref>
     5386   and by the fact that HTTP allows the use of some character encodings which do
     5387   not use octets 13 and 10 to represent CR and LF, respectively, as is the case
     5388   for some multi-byte character encodings.
    53695389</t>
    53705390<t>
    … …  
    53815401   HTTP/1.1 uses a restricted set of date formats (&http-date;) to
    53825402   simplify the process of date comparison. Proxies and gateways from
    5383    other protocols &SHOULD; ensure that any Date header field present in a
    5384    message conforms to one of the HTTP/1.1 formats and rewrite the date
    5385    if necessary.
     5403   other protocols &SHOULD; ensure that any <x:ref>Date</x:ref> header field
     5404   present in a message conforms to one of the HTTP/1.1 formats and rewrite
     5405   the date if necessary.
    53865406</t>
    53875407</section>
    … …  
    53905410<t>
    53915411   MIME does not include any concept equivalent to HTTP/1.1's
    5392    Content-Encoding header field. Since this acts as a modifier on the
    5393    media type, proxies and gateways from HTTP to MIME-compliant
    5394    protocols &MUST; either change the value of the Content-Type header
    5395    field or decode the representation before forwarding the message. (Some
    5396    experimental applications of Content-Type for Internet mail have used
     5412   <x:ref>Content-Encoding</x:ref> header field. Since this acts as a modifier
     5413   on the media type, proxies and gateways from HTTP to MIME-compliant
     5414   protocols &MUST; either change the value of the <x:ref>Content-Type</x:ref>
     5415   header field or decode the representation before forwarding the message.
     5416   (Some experimental applications of Content-Type for Internet mail have used
    53975417   a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
    53985418   a function equivalent to Content-Encoding. However, this parameter is
    … …  
    55035523  Deprecate <x:ref>305 (Use Proxy)</x:ref> status code, because user agents did
    55045524  not implement it. It used to indicate that the target resource needs to be
    5505   accessed through the proxy given by the Location field. The Location field
    5506   gave the URI of the proxy. The recipient was expected to repeat this single
    5507   request via the proxy.
     5525  accessed through the proxy given by the <x:ref>Location</x:ref> field. The
     5526  Location field gave the URI of the proxy. The recipient was expected to
     5527  repeat this single request via the proxy.
    55085528  (<xref target="status.305"/>)
    55095529</t>
    … …  
    55185538</t>
    55195539<t>
    5520   Reclassify "Allow" as response header field, removing the option to
    5521   specify it in a PUT request.
     5540  Reclassify "<x:ref>Allow</x:ref>" as response header field, removing the
     5541  option to specify it in a PUT request.
    55225542  Relax the server requirement on the contents of the Allow header field and
    55235543  remove requirement on clients to always trust the header field value.
    … …  
    55255545</t>
    55265546<t>
    5527   The ABNF for the Expect header field has been both fixed (allowing parameters
    5528   for value-less expectations as well) and simplified (allowing trailing
    5529   semicolons after "100-continue" when they were invalid before).
     5547  The ABNF for the <x:ref>Expect</x:ref> header field has been both fixed
     5548  (allowing parameters for value-less expectations as well) and simplified
     5549  (allowing trailing semicolons after "100-continue" when they were invalid
     5550  before).
    55305551  (<xref target="header.expect"/>)
    55315552</t>
    55325553<t>
    5533   Correct syntax of Location header field to allow URI references (including
    5534   relative references and fragments), as referred symbol "absoluteURI" wasn't
    5535   what was expected, and add some clarifications as to when use of fragments
    5536   would not be appropriate.
     5554  Correct syntax of <x:ref>Location</x:ref> header field to allow URI
     5555  references (including relative references and fragments), as referred symbol
     5556  "absoluteURI" wasn't what was expected, and add some clarifications as to
     5557  when use of fragments would not be appropriate.
    55375558  (<xref target="header.location"/>)
    55385559</t>
    55395560<t>
    5540   Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
    5541   extension methods could have used it as well).
     5561  Restrict <x:ref>Max-Forwards</x:ref> header field to OPTIONS and TRACE
     5562  (previously, extension methods could have used it as well).
    55425563  (<xref target="header.max-forwards"/>)
    55435564</t>
    55445565<t>
    5545   Allow Referer field value of "about:blank" as alternative to not specifying it.
     5566  Allow <x:ref>Referer</x:ref> field value of "about:blank" as alternative to
     5567  not specifying it.
    55465568  (<xref target="header.referer"/>)
    55475569</t>
    55485570<t>
    5549   In the description of the Server header field, the Via field
    5550   was described as a SHOULD. The requirement was and is stated
    5551   correctly in the description of the Via header field in &header-via;.
     5571  In the description of the <x:ref>Server</x:ref> header field, the
     5572  <x:ref>Via</x:ref> field was described as a SHOULD. The requirement was and
     5573  is stated correctly in the description of the Via header field in
     5574  &header-via;.
    55525575  (<xref target="header.server"/>)
    55535576</t>
    … …  
    55765599</t>
    55775600<t>
    5578   Remove ISO-8859-1 special-casing in Accept-Charset.
     5601  Remove ISO-8859-1 special-casing in <x:ref>Accept-Charset</x:ref>.
    55795602  (<xref target="header.accept-charset"/>)
    55805603</t>
    55815604<t>
    5582   Remove base URI setting semantics for Content-Location due to poor
    5583   implementation support, which was caused by too many broken servers emitting
     5605  Remove base URI setting semantics for <x:ref>Content-Location</x:ref> due to
     5606  poor implementation support, which was caused by too many broken servers emitting
    55845607  bogus Content-Location header fields, and also the potentially undesirable effect
    55855608  of potentially breaking relative links in content-negotiated resources.

  • draft-ietf-httpbis/latest/p4-conditional.html

    r1739 r1740  
    661661         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    662662         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    663          the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
    664          of error recovery could lead to dangerous consequences.
     663         the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
     664         could lead to dangerous consequences.
    665665      </p>
    666666      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    … …  
    691691      </p>
    692692      <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such
    693          that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,
    694          Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate
    695          the stored responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same
     693         that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET.
     694      </p>
     695      <p id="rfc.section.2.1.p.3">A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored
     696         responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same
    696697         validator unless their payload body would be identical.
    697698      </p>
    698       <p id="rfc.section.2.1.p.3">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate
     699      <p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate
    699700         an entry using a validator that it obtained in the distant past. A strong validator <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource over time. However, there is no
    700701         implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for
    701702         representations of multiple resources at the same time and does not imply that those representations are equivalent).
    702703      </p>
    703       <p id="rfc.section.2.1.p.4">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change
     704      <p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change
    704705         to a representation always results in a unique node name and revision identifier being assigned before the representation
    705706         is made accessible to GET. A cryptographic hash function applied to the representation data is also sufficient if the data
    … …  
    708709         occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior.
    709710      </p>
    710       <p id="rfc.section.2.1.p.5">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation
     711      <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation
    711712         data. This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to
    712713         ensure uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations
    … …  
    714715         In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.
    715716      </p>
    716       <p id="rfc.section.2.1.p.6">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might
     717      <p id="rfc.section.2.1.p.7">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might
    717718         be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in
    718719         order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server
    … …  
    721722         those modifications.
    722723      </p>
    723       <p id="rfc.section.2.1.p.7">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when
     724      <p id="rfc.section.2.1.p.8">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when
    724725         a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of a representation's
    725726         payload body. Strong validators are usable and preferred for all conditional requests, including cache validation, partial
    … …  
    745746         use its value to make conditional requests and test the validity of locally cached responses.
    746747      </p>
    747       <p id="rfc.section.2.2.1.p.3">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date field-value
    748          for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially
    749          if the representation changes near the time that the response is generated.
    750       </p>
    751       <p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (Date). If the last modification time
    752          is derived from implementation-specific metadata that evaluates to some time in the future, according to the origin server's
    753          clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact
     748      <p id="rfc.section.2.2.1.p.3">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the <a href="p2-semantics.html#header.date" class="smpl">Date</a> field value for its response. This allows a recipient to make an accurate assessment of the representation's modification
     749         time, especially if the representation changes near the time that the response is generated.
     750      </p>
     751      <p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (<a href="p2-semantics.html#header.date" class="smpl">Date</a>). If the last modification time is derived from implementation-specific metadata that evaluates to some time in the future,
     752         according to the origin server's clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact
    754753         on cache validation.
    755754      </p>
    … …  
    771770         <li>The validator is about to be used by a client in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field, because the client has a cache entry, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> for the associated representation, and
    772771         </li>
    773          <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
     772         <li>That cache entry includes a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and
     773         </li>
    774774         <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li>
    775775      </ul>
    … …  
    779779            and
    780780         </li>
    781          <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
     781         <li>That cache entry includes a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and
     782         </li>
    782783         <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li>
    783784      </ul>
    784785      <p id="rfc.section.2.2.2.p.4">This method relies on the fact that if two different responses were sent by the origin server during the same second, but
    785          both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified
    786          time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from
    787          different clocks, or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
     786         both had the same Last-Modified time, then at least one of those responses would have a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified
     787         values are generated from different clocks, or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
    788788      </p>
    789789      <div id="rfc.iref.e.1"></div>
    … …  
    883883      </div>
    884884      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3>
    885       <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>):
     885      <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>):
    886886      </p>
    887887      <div id="rfc.figure.u.6"></div>
    … …  
    10911091         as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    10921092      </p>
    1093       <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, Content-Location, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
     1093      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
     1094            (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
    10941095      </p>
    10951096      <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1739 r1740  
    197197   impact on security. This is because different uses of the protocol require
    198198   different error handling strategies; for example, a Web browser might wish to
    199    transparently recover from a response where the Location header field
    200    doesn't parse according to the ABNF, whereby in a systems control protocol
    201    using HTTP, this type of error recovery could lead to dangerous consequences.
     199   transparently recover from a response where the <x:ref>Location</x:ref>
     200   header field doesn't parse according to the ABNF, whereby in a systems
     201   control protocol using HTTP, this type of error recovery could lead to
     202   dangerous consequences.
    202203</t>
    203204</section>
    … …  
    273274   a change occurs to the representation data such that a change would be
    274275   observable in the payload body of a <x:ref>200 (OK)</x:ref> response to GET.
     276</t>
     277<t>   
    275278   A strong validator &MAY; be changed for other reasons, such as when a semantically
    276279   significant part of the representation metadata is changed (e.g.,
    277    Content-Type), but it is in the best interests of the origin server to only
    278    change the value when it is necessary to invalidate the stored responses
    279    held by remote caches and authoring tools.  A strong validator &MUST; be
    280    unique across all representations of a given resource, such that no two
    281    representations of that resource share the same validator unless
    282    their payload body would be identical.
     280   <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin
     281   server to only change the value when it is necessary to invalidate the
     282   stored responses held by remote caches and authoring tools.  A strong
     283   validator &MUST; be unique across all representations of a given resource,
     284   such that no two representations of that resource share the same validator
     285   unless their payload body would be identical.
    283286</t>
    284287<t>
    … …  
    384387<t>
    385388   An origin server &SHOULD; obtain the Last-Modified value of the
    386    representation as close as possible to the time that it generates
    387    the Date field-value for its response. This allows a recipient to
     389   representation as close as possible to the time that it generates the
     390   <x:ref>Date</x:ref> field value for its response. This allows a recipient to
    388391   make an accurate assessment of the representation's modification time,
    389392   especially if the representation changes near the time that the
    … …  
    392395<t>
    393396   An origin server with a clock &MUST-NOT; send a Last-Modified date
    394    that is later than the server's time of message origination (Date).
     397   that is later than the server's time of message origination (<x:ref>Date</x:ref>).
    395398   If the last modification time is derived from implementation-specific
    396399   metadata that evaluates to some time in the future, according to the
    … …  
    426429        a cache entry, or <x:ref>If-Range</x:ref> for the associated
    427430        representation, and</t>
    428      <t>That cache entry includes a Date value, which gives the time
    429         when the origin server sent the original response, and</t>
     431     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
     432        time when the origin server sent the original response, and</t>
    430433     <t>The presented Last-Modified time is at least 60 seconds before
    431434        the Date value.</t>
    … …  
    437440     <t>The validator is being compared by an intermediate cache to the
    438441        validator stored in its cache entry for the representation, and</t>
    439      <t>That cache entry includes a Date value, which gives the time
    440         when the origin server sent the original response, and</t>
     442     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
     443        time when the origin server sent the original response, and</t>
    441444     <t>The presented Last-Modified time is at least 60 seconds before
    442445        the Date value.</t>
    … …  
    447450   sent by the origin server during the same second, but both had the
    448451   same Last-Modified time, then at least one of those responses would
    449    have a Date value equal to its Last-Modified time. The arbitrary 60-second
    450    limit guards against the possibility that the Date and Last-Modified
    451    values are generated from different clocks, or at somewhat
     452   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
     453   arbitrary 60-second limit guards against the possibility that the Date and
     454   Last-Modified values are generated from different clocks, or at somewhat
    452455   different times during the preparation of the response. An
    453456   implementation &MAY; use a value larger than 60 seconds, if it is
    … …  
    597600   Consider a resource that is subject to content negotiation (&content-negotiation;),
    598601   and where the representations returned upon a GET request vary based on
    599    the Accept-Encoding request header field (&header-accept-encoding;):
     602   the <x:ref>Accept-Encoding</x:ref> request header field
     603   (&header-accept-encoding;):
    600604</t>
    601605<figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"  x:indent-with="  ">
    … …  
    10151019</t>
    10161020<t>
    1017    A 304 response &MUST; include a Date header field (&header-date;)
    1018    unless the origin server does not have a clock that can provide a
    1019    reasonable approximation of the current time.  If a <x:ref>200 (OK)</x:ref>
    1020    response to the same request would have included any of the header fields
    1021    <x:ref>Cache-Control</x:ref>, Content-Location, <x:ref>ETag</x:ref>,
    1022    <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then those same header
    1023    fields &MUST; be sent in a 304 response.
     1021   A 304 response &MUST; include a <x:ref>Date</x:ref> header field
     1022   (&header-date;) unless the origin server does not have a clock that can
     1023   provide a reasonable approximation of the current time.  If a <x:ref>200
     1024   (OK)</x:ref> response to the same request would have included any of the
     1025   header fields <x:ref>Cache-Control</x:ref>, <x:ref>Content-Location</x:ref>,
     1026   <x:ref>ETag</x:ref>, <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then
     1027   those same header fields &MUST; be sent in a 304 response.
    10241028</t>
    10251029<t>
    … …  
    12081212    <x:defines>2xx (Successful)</x:defines>
    12091213    <x:defines>200 (OK)</x:defines>
     1214    <x:defines>Accept-Encoding</x:defines>
     1215    <x:defines>Content-Location</x:defines>
     1216    <x:defines>Content-Type</x:defines>
     1217    <x:defines>Date</x:defines>
     1218    <x:defines>Location</x:defines>
    12101219  </x:source>
    12111220</reference>

  • draft-ietf-httpbis/latest/p5-range.html

    r1739 r1740  
    683683         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    684684         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    685          the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
    686          of error recovery could lead to dangerous consequences.
     685         the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
     686         could lead to dangerous consequences.
    687687      </p>
    688688      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    … …  
    738738      </p>
    739739      <ul>
    740          <li>Either a <a href="#header.content-range" class="smpl">Content-Range</a> header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;5.2</a>) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields
    741             for each part. If a Content-Length header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of octets transmitted in the message body.
     740         <li>Either a <a href="#header.content-range" class="smpl">Content-Range</a> header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;5.2</a>) indicating the range included with this response, or a multipart/byteranges <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> including Content-Range fields for each part. If a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of octets transmitted in the message body.
    742741         </li>
    743742         <li>Date</li>
    744          <li> <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, Content-Location and/or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
     743         <li> <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> and/or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
    745744         </li>
    746745      </ul>
    … …  
    11911190         </p>
    11921191      </div>
    1193       <p id="rfc.section.A.p.3">The multipart/byteranges media type includes one or more parts, each with its own Content-Type and <a href="#header.content-range" class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body-part.
     1192      <p id="rfc.section.A.p.3">The multipart/byteranges media type includes one or more parts, each with its own <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-range" class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body-part.
    11941193      </p>
    11951194      <p id="rfc.section.A.p.4"> </p>

  • draft-ietf-httpbis/latest/p5-range.xml

    r1739 r1740  
    187187   impact on security. This is because different uses of the protocol require
    188188   different error handling strategies; for example, a Web browser might wish to
    189    transparently recover from a response where the Location header field
    190    doesn't parse according to the ABNF, whereby in a systems control protocol
    191    using HTTP, this type of error recovery could lead to dangerous consequences.
     189   transparently recover from a response where the <x:ref>Location</x:ref>
     190   header field doesn't parse according to the ABNF, whereby in a systems
     191   control protocol using HTTP, this type of error recovery could lead to
     192   dangerous consequences.
    192193</t>
    193194</section>
    … …  
    329330        (<xref target="header.content-range"/>) indicating
    330331        the range included with this response, or a multipart/byteranges
    331         Content-Type including Content-Range fields for each part. If a
    332         Content-Length header field is present in the response, its
    333         value &MUST; match the actual number of octets transmitted in the
    334         message body.
     332        <x:ref>Content-Type</x:ref> including Content-Range fields for each
     333        part. If a <x:ref>Content-Length</x:ref> header field is present in the
     334        response, its value &MUST; match the actual number of octets
     335        transmitted in the message body.
    335336    </t>
    336337    <t>
    … …  
    339340    <t>
    340341        <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
    341         <x:ref>Expires</x:ref>, Content-Location and/or
     342        <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref> and/or
    342343        <x:ref>Vary</x:ref>, if the header field would have been sent in a
    343344        <x:ref>200 (OK)</x:ref> response to the same request
    … …  
    10081009  </front>
    10091010  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
    1010   <x:source href="p1-messaging.xml" basename="p1-messaging"/>
     1011  <x:source href="p1-messaging.xml" basename="p1-messaging">
     1012    <x:defines>Content-Length</x:defines>
     1013  </x:source>
    10111014</reference>
    10121015
    … …  
    10321035    <x:defines>200 (OK)</x:defines>
    10331036    <x:defines>410 (Gone)</x:defines>
     1037    <x:defines>Content-Location</x:defines>
     1038    <x:defines>Content-Type</x:defines>
     1039    <x:defines>Location</x:defines>
    10341040  </x:source>
    10351041</reference>
    … …  
    12601266<t>
    12611267   The multipart/byteranges media type includes one or more parts, each
    1262    with its own Content-Type and <x:ref>Content-Range</x:ref> fields. The
    1263    required boundary parameter specifies the boundary string used to separate
    1264    each body-part.
     1268   with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref>
     1269   fields. The required boundary parameter specifies the boundary string used
     1270   to separate each body-part.
    12651271</t>
    12661272<t>

  • draft-ietf-httpbis/latest/p6-cache.html

    r1739 r1740  
    794794         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    795795         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    796          the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
    797          of error recovery could lead to dangerous consequences.
     796         the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
     797         could lead to dangerous consequences.
    798798      </p>
    799799      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    … …  
    913913      <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.6</a>.
    914914      </p>
    915       <p id="rfc.section.2.2.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field). It can also forward a request with "Cache-Control:
    916          max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
     915      <p id="rfc.section.2.2.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field). It can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate
     916         which response to use.
    917917      </p>
    918918      <p id="rfc.section.2.2.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.
    … …  
    951951         <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) is present, use its value, or
    952952         </li>
    953          <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header field, or
     953         <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or
    954954         </li>
    955955         <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
    … …  
    993993      </p>
    994994      <ul class="empty">
    995          <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
    996             response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic
    997             operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     995         <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value"
     996            denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    998997         </li>
    999998      </ul>
    … …  
    11381137         to keep their contents up-to-date.
    11391138      </p>
    1140       <p id="rfc.section.2.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error response
    1141          to a request with an unsafe method is received.
    1142       </p>
    1143       <p id="rfc.section.2.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host
    1144          part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
     1139      <p id="rfc.section.2.6.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
     1140      </p>
     1141      <p id="rfc.section.2.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    11451142      </p>
    11461143      <p id="rfc.section.2.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
    … …  
    11841181      </p>
    11851182      <p id="rfc.section.2.8.p.5">The stored response with matching selecting header fields is known as the selected response.</p>
    1186       <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the Date header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;2.2</a>.
     1183      <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;2.2</a>.
    11871184      </p>
    11881185      <p id="rfc.section.2.8.p.7">If no selected response is available, the cache can forward the presented request to the origin server in a conditional request;
    … …  
    13051302      <div id="rfc.iref.n.3"></div>
    13061303      <h4 id="rfc.section.3.2.1.6"><a href="#rfc.section.3.2.1.6">3.2.1.6</a>&nbsp;<a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4>
    1307       <p id="rfc.section.3.2.1.6.p.1">The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Type request header fields, nor the request representation.
     1304      <p id="rfc.section.3.2.1.6.p.1">The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> request header fields, nor the request representation.
    13081305      </p>
    13091306      <div id="rfc.iref.c.13"></div>
    … …  
    14211418      <div id="rfc.iref.n.6"></div>
    14221419      <h4 id="rfc.section.3.2.2.9"><a href="#rfc.section.3.2.2.9">3.2.2.9</a>&nbsp;<a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4>
    1423       <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Type response header fields, nor the response representation.
     1420      <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> response header fields, nor the response representation.
    14241421      </p>
    14251422      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
    … …  
    15921589      </ul>
    15931590      <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning header fields to a receiver whose version is HTTP/1.0 or lower,
    1594          then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header field in the message.
    1595       </p>
    1596       <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date
    1597          value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
     1591         then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message.
     1592      </p>
     1593      <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the <a href="p2-semantics.html#header.date" class="smpl">Date</a> value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
    15981594         header fields.) If all of the warning-values are deleted for this reason, the Warning header field <em class="bcp14">MUST</em> be deleted as well.
    15991595      </p>
    … …  
    19701966      <p id="rfc.section.A.p.1">Make the specified age calculation algorithm less conservative. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>)
    19711967      </p>
    1972       <p id="rfc.section.A.p.2">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to
    1973          use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
     1968      <p id="rfc.section.A.p.2">Remove requirement to consider <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> in successful responses in order to determine the appropriate response to use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
    19741969      </p>
    19751970      <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.6</a>)

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1739 r1740  
    332332   impact on security. This is because different uses of the protocol require
    333333   different error handling strategies; for example, a Web browser might wish to
    334    transparently recover from a response where the Location header field
    335    doesn't parse according to the ABNF, whereby in a systems control protocol
    336    using HTTP, this type of error recovery could lead to dangerous consequences.
     334   transparently recover from a response where the <x:ref>Location</x:ref>
     335   header field doesn't parse according to the ABNF, whereby in a systems
     336   control protocol using HTTP, this type of error recovery could lead to
     337   dangerous consequences.
    337338</t>
    338339</section>
    … …  
    580581<t>
    581582   When more than one suitable response is stored, a cache &MUST; use the
    582    most recent response (as determined by the Date header field). It can also
    583    forward a request with "Cache-Control: max-age=0" or "Cache-Control:
    584    no-cache" to disambiguate which response to use.
     583   most recent response (as determined by the <x:ref>Date</x:ref> header
     584   field). It can also forward a request with "Cache-Control: max-age=0" or
     585   "Cache-Control: no-cache" to disambiguate which response to use.
    585586</t>
    586587<t>
    … …  
    662663      <t>If the <x:ref>Expires</x:ref> response header field
    663664      (<xref target="header.expires" />) is present, use its value minus the
    664       value of the Date response header field, or</t>
     665      value of the <x:ref>Date</x:ref> response header field, or</t>
    665666      <t>Otherwise, no explicit expiration time is present in the response. A
    666667      heuristic freshness lifetime might be applicable; see <xref
    … …  
    742743   <list>
    743744      <t>
    744          HTTP/1.1 requires origin servers to send a Date header field, if possible,
    745          with every response, giving the time at which the response was
    746          generated. The term "date_value" denotes the value of the Date
    747          header field, in a form appropriate for arithmetic operations. See
     745         HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header
     746         field, if possible, with every response, giving the time at which the
     747         response was generated. The term "date_value" denotes the value of the
     748         Date header field, in a form appropriate for arithmetic operations. See
    748749         &header-date; for the definition of the Date header field, and for
    749750         requirements regarding responses without it.
    … …  
    10221023<t>
    10231024   A cache &MUST; invalidate the effective Request URI
    1024    (&effective-request-uri;) as well as the URI(s) in the Location
    1025    and Content-Location response header fields (if present) when a non-error
    1026    response to a request with an unsafe method is received.
    1027 </t>
    1028 <t>
    1029    However, a cache &MUST-NOT; invalidate a URI from a Location or
    1030    Content-Location response header field if the host part of that URI differs
    1031    from the host part in the effective request URI (&effective-request-uri;).
    1032    This helps prevent denial of service attacks.
     1025   (&effective-request-uri;) as well as the URI(s) in the <x:ref>Location</x:ref>
     1026   and <x:ref>Content-Location</x:ref> response header fields (if present) when
     1027   a non-error response to a request with an unsafe method is received.
     1028</t>
     1029<t>
     1030   However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref>
     1031   or <x:ref>Content-Location</x:ref> response header field if the host part of
     1032   that URI differs from the host part in the effective request URI
     1033   (&effective-request-uri;). This helps prevent denial of service attacks.
    10331034</t>
    10341035<t>
    … …  
    11221123<t>
    11231124   If multiple selected responses are available, the most recent response
    1124    (as determined by the Date header field) is used; see <xref
     1125   (as determined by the <x:ref>Date</x:ref> header field) is used; see <xref
    11251126   target="constructing.responses.from.caches"/>.
    11261127</t>
    … …  
    13601361   The no-transform request directive indicates that an intermediary
    13611362   (whether or not it implements a cache) &MUST-NOT; change the
    1362    Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type request
    1363    header fields, nor the request representation.
     1363   <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or
     1364   <x:ref>Content-Type</x:ref> request header fields, nor the request
     1365   representation.
    13641366</t>
    13651367</section>
    … …  
    15891591   The no-transform response directive indicates that an intermediary
    15901592   (regardless of whether it implements a cache) &MUST-NOT; change the
    1591    Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type response
    1592    header fields, nor the response representation.
     1593   <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or
     1594   <x:ref>Content-Type</x:ref> response header fields, nor the response
     1595   representation.
    15931596</t>
    15941597</section>
    … …  
    19121915   If an implementation sends a message with one or more Warning header fields to a
    19131916   receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include
    1914    in each warning-value a warn-date that matches the Date header field in the
    1915    message.
     1917   in each warning-value a warn-date that matches the <x:ref>Date</x:ref> header
     1918   field in the message.
    19161919</t>
    19171920<t>
    19181921   If a system receives a message with a warning-value that includes
    1919    a warn-date, and that warn-date is different from the Date value in the
    1920    response, then that warning-value &MUST; be deleted from the message before
    1921    storing, forwarding, or using it. (preventing the consequences of naive
    1922    caching of Warning header fields.) If all of the warning-values are deleted
    1923    for this reason, the Warning header field &MUST; be deleted as well.
     1922   a warn-date, and that warn-date is different from the <x:ref>Date</x:ref>
     1923   value in the response, then that warning-value &MUST; be deleted from the
     1924   message before storing, forwarding, or using it. (preventing the consequences
     1925   of naive caching of Warning header fields.) If all of the warning-values are
     1926   deleted for this reason, the Warning header field &MUST; be deleted as well.
    19241927</t>
    19251928<t>
    … …  
    23092312      <x:defines>5xx (Server Error)</x:defines>
    23102313      <x:defines>504 (Gateway Timeout)</x:defines>
     2314      <x:defines>Content-Encoding</x:defines>
     2315      <x:defines>Content-Location</x:defines>
     2316      <x:defines>Content-Type</x:defines>
     2317      <x:defines>Date</x:defines>
     2318      <x:defines>Location</x:defines>
    23112319    </x:source>
    23122320  </reference>
    … …  
    25322540</t>
    25332541<t>
    2534   Remove requirement to consider Content-Location in successful responses
    2535   in order to determine the appropriate response to use.
     2542  Remove requirement to consider <x:ref>Content-Location</x:ref> in successful
     2543  responses in order to determine the appropriate response to use.
    25362544  (<xref target="validation.model" />)
    25372545</t>

  • draft-ietf-httpbis/latest/p7-auth.html

    r1736 r1740  
    648648         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    649649         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    650          the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
    651          of error recovery could lead to dangerous consequences.
     650         the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
     651         could lead to dangerous consequences.
    652652      </p>
    653653      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    … …  
    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 <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.
     685      <p id="rfc.section.2.1.p.5">The <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one challenge applicable to the requested resource.
     686      </p>
     687      <p id="rfc.section.2.1.p.6">The <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing at least one challenge applicable to the proxy for the requested resource.
    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> ) ]
    690690</pre><div class="note" id="rfc.section.2.1.p.8">
    691          <p> <b>Note:</b> User agents will need to take special care in parsing the WWW-Authenticate and Proxy-Authenticate header field values because
    692             they can contain more than one challenge, or if more than one of each is provided, since the contents of a challenge can itself
    693             contain a comma-separated list of authentication parameters.
     691         <p> <b>Note:</b> User agents will need to take special care in parsing the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field values because they can contain more than one challenge, or if more than one of each is provided, since the contents
     692            of a challenge can itself contain a comma-separated list of authentication parameters.
    694693         </p>
    695694      </div>
    … …  
    701700      <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an <a href="#header.authorization" class="smpl">Authorization</a> header field with the request.
    702701      </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.
    704       </p>
    705       <p id="rfc.section.2.1.p.12">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested,
    706          based upon a challenge received from the server (possibly at some point in the past). When creating their values, the user
    707          agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands,
    708          obtaining credentials from the user as appropriate.
     702      <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field with the request.
     703      </p>
     704      <p id="rfc.section.2.1.p.12">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received
     705         from the server (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
     706         the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the
     707         user as appropriate.
    709708      </p>
    710709      <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> ) ]
    711710</pre><p id="rfc.section.2.1.p.14">Upon a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial
    712          credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> return a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.
     711         credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> return a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one (possibly new) challenge applicable to the requested resource.
    713712      </p>
    714713      <p id="rfc.section.2.1.p.15">Likewise, upon a request that requires authentication by proxies that omit credentials or contain invalid or partial credentials,
    715          a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy.
     714         a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing a (possibly new) challenge applicable to the proxy.
    716715      </p>
    717716      <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    … …  
    721720         authentication information. However, such additional mechanisms are not defined by this specification.
    722721      </p>
    723       <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
     722      <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
    724723      </p>
    725724      <div id="rfc.iref.p.1"></div>
    … …  
    794793         </li>
    795794         <li>
    796             <p>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate),
    797                and/or proxy authentication (i.e., using Proxy-Authenticate).
     795            <p>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>), and/or proxy authentication (i.e., using <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a>).
    798796            </p>
    799797         </li>
    … …  
    811809      <div id="rfc.iref.s.1"></div>
    812810      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.401" href="#status.401">401 Unauthorized</a></h2>
    813       <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
     811      <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
    814812         refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
    815813         already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
    … …  
    819817      <div id="rfc.iref.s.2"></div>
    820818      <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>
    821       <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&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>).
     819      <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> return a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&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 <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
    822820      </p>
    823821      <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>
    … …  
    854852      </p>
    855853      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    856 </pre><p id="rfc.section.4.2.p.3">Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection, and intermediaries <em class="bcp14">SHOULD NOT</em> forward it to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting them
     854</pre><p id="rfc.section.4.2.p.3">Unlike <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>, the Proxy-Authenticate header field applies only to the current connection, and intermediaries <em class="bcp14">SHOULD NOT</em> forward it to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting them
    857855         from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate header
    858856         field.
    859857      </p>
    860       <p id="rfc.section.4.2.p.4">Note that the parsing considerations for WWW-Authenticate apply to this header field as well; see <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section&nbsp;4.4</a> for details.
     858      <p id="rfc.section.4.2.p.4">Note that the parsing considerations for <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> apply to this header field as well; see <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section&nbsp;4.4</a> for details.
    861859      </p>
    862860      <div id="rfc.iref.p.3"></div>
    … …  
    868866      </p>
    869867      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
    870 </pre><p id="rfc.section.4.3.p.3">Unlike <a href="#header.authorization" class="smpl">Authorization</a>, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate
    871          field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy
     868</pre><p id="rfc.section.4.3.p.3">Unlike <a href="#header.authorization" class="smpl">Authorization</a>, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy
    872869         that was expecting to receive credentials. A proxy <em class="bcp14">MAY</em> relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively
    873870         authenticate a given request.

  • draft-ietf-httpbis/latest/p7-auth.xml

    r1736 r1740  
    173173   impact on security. This is because different uses of the protocol require
    174174   different error handling strategies; for example, a Web browser might wish to
    175    transparently recover from a response where the Location header field
    176    doesn't parse according to the ABNF, whereby in a systems control protocol
    177    using HTTP, this type of error recovery could lead to dangerous consequences.
     175   transparently recover from a response where the <x:ref>Location</x:ref>
     176   header field doesn't parse according to the ABNF, whereby in a systems
     177   control protocol using HTTP, this type of error recovery could lead to
     178   dangerous consequences.
    178179</t>
    179180</section>
    … …  
    325326   credentials or contain invalid or partial credentials, a proxy &SHOULD;
    326327   return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
    327    &MUST; include a <x:ref>Proxy-Authenticate header</x:ref> field containing a (possibly
     328   &MUST; include a <x:ref>Proxy-Authenticate</x:ref> header field containing a (possibly
    328329   new) challenge applicable to the proxy.
    329330</t>
    … …  
    896897  <x:source basename="p2-semantics" href="p2-semantics.xml">
    897898    <x:defines>403 (Forbidden)</x:defines>
     899    <x:defines>Location</x:defines>
    898900  </x:source>
    899901</reference>
Note: See TracChangeset for help on using the changeset viewer.