Changeset 994


Ignore:
Timestamp:
07/09/10 11:46:12 (12 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

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

Legend:

Unmodified
Added
Removed

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

    r992 r994  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-09-06">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: March 10, 2011</td>
     437               <td class="left">Expires: March 11, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">September 6, 2010</td>
     490               <td class="right">September 7, 2010</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on March 10, 2011.</p>
     518      <p>This Internet-Draft will expire on March 11, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    608608                     </li>
    609609                     <li class="tocline1">7.1.3&nbsp;&nbsp;&nbsp;<a href="#persistent.proxy">Proxy Servers</a><ul class="toc">
    610                            <li class="tocline1">7.1.3.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></li>
    611                            <li class="tocline1">7.1.3.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.headers">Non-modifiable Headers</a></li>
     610                           <li class="tocline1">7.1.3.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></li>
     611                           <li class="tocline1">7.1.3.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li>
    612612                        </ul>
    613613                     </li>
    … …  
    11881188      </p>
    11891189      <div class="note" id="rfc.section.3.2.p.7">
    1190          <p> <b>Note:</b> The "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
    1191             A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
     1190         <p> <b>Note:</b> The "Set-Cookie" header field as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
     1191            A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
    11921192         </p>
    11931193      </div>
    … …  
    17231723      </p>
    17241724      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1725       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1725      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    17261726         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    17271727         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    … …  
    17681768      </p>
    17691769      <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    1770       <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token
    1771          "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token "close".
     1770      <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection-token
     1771         "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token "close".
    17721772      </p>
    17731773      <p id="rfc.section.7.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
    1774          a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than
    1775          that request, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close.
    1776       </p>
    1777       <p id="rfc.section.7.1.2.1.p.3">If either the client or the server sends the close token in the Connection header, that request becomes the last one for the
    1778          connection.
     1774         a Connection header field with the connection-token close. In case the client does not want to maintain a connection for more
     1775         than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token close.
     1776      </p>
     1777      <p id="rfc.section.7.1.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one
     1778         for the connection.
    17791779      </p>
    17801780      <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    … …  
    17961796         to. Each persistent connection applies to only one transport link.
    17971797      </p>
    1798       <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
    1799       </p>
    1800       <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.headers" href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></h4>
    1801       <p id="rfc.section.7.1.3.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: </p>
    1802       <ul>
    1803          <li>End-to-end headers, which are transmitted to the ultimate recipient of a request or response. End-to-end headers in responses
    1804             MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry.
    1805          </li>
    1806          <li>Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded
    1807             by proxies.
    1808          </li>
    1809       </ul>
    1810       <p id="rfc.section.7.1.3.1.p.2">The following HTTP/1.1 headers are hop-by-hop headers: </p>
     1798      <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
     1799      </p>
     1800      <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4>
     1801      <p id="rfc.section.7.1.3.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p>
     1802      <ul>
     1803         <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields
     1804            in responses MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry.
     1805         </li>
     1806         <li>Hop-by-hop header fields, which are meaningful only for a single transport-level connection, and are not stored by caches
     1807            or forwarded by proxies.
     1808         </li>
     1809      </ul>
     1810      <p id="rfc.section.7.1.3.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
    18111811      <ul>
    18121812         <li>Connection</li>
    … …  
    18191819         <li>Upgrade</li>
    18201820      </ul>
    1821       <p id="rfc.section.7.1.3.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p>
    1822       <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>).
    1823       </p>
    1824       <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a>&nbsp;<a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h4>
    1825       <p id="rfc.section.7.1.3.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent
    1826          proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.
     1821      <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
     1822      <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>).
     1823      </p>
     1824      <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
     1825      <p id="rfc.section.7.1.3.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A transparent
     1826         proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header field unless the definition of that header field requires or specifically allows that.
    18271827      </p>
    18281828      <p id="rfc.section.7.1.3.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
    … …  
    18391839         <li>Expires</li>
    18401840      </ul>
    1841       <p id="rfc.section.7.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header in that response.
     1841      <p id="rfc.section.7.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires 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.
    18421842      </p>
    18431843      <p id="rfc.section.7.1.3.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:
    … …  
    18511851      </p>
    18521852      <div class="note" id="rfc.section.7.1.3.2.p.7">
    1853          <p> <b>Warning:</b> Unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are
    1854             introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
     1853         <p> <b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms
     1854            are introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    18551855         </p>
    18561856      </div>
    … …  
    18951895      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    18961896      <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    1897          status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
     1897         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    18981898      </p>
    18991899      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    19001900      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    1901          to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
    1902          be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
    1903          at the body.
     1901         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
     1902         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
     1903         looking at the body.
    19041904      </p>
    19051905      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    … …  
    19611961      <ol>
    19621962         <li>Initiate a new connection to the server</li>
    1963          <li>Transmit the request-headers</li>
     1963         <li>Transmit the request-header fields</li>
    19641964         <li>Initialize a variable R to the estimated round-trip time to the server (e.g., based on the time it took to establish the connection),
    19651965            or to a constant value of 5 seconds if the round-trip time is not available.
    … …  
    20032003         and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
    20042004      </p>
    2005       <p id="rfc.section.9.1.p.2">The Connection header's value has the following grammar:</p>
     2005      <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p>
    20062006      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span>  <a href="#header.connection" class="smpl">Connection</a>       = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>
    20072007  <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
    … …  
    20122012         header field might not be sent if there are no parameters associated with that connection option.
    20132013      </p>
    2014       <p id="rfc.section.9.1.p.5">Message headers listed in the Connection header <em class="bcp14">MUST NOT</em> include end-to-end headers, such as Cache-Control.
     2014      <p id="rfc.section.9.1.p.5">Message header fields listed in the Connection header field <em class="bcp14">MUST NOT</em> include end-to-end header fields, such as Cache-Control.
    20152015      </p>
    20162016      <p id="rfc.section.9.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
    … …  
    20242024      <p id="rfc.section.9.1.p.10">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
    20252025      </p>
    2026       <p id="rfc.section.9.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header <em class="bcp14">MUST</em>, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the
     2026      <p id="rfc.section.9.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header field <em class="bcp14">MUST</em>, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the
    20272027         connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a>.
    20282028      </p>
    … …  
    20742074         then it is optional. A client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request.
    20752075      </p>
    2076       <p id="rfc.section.9.3.p.8">The HTTP-date sent in a Date header <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
     2076      <p id="rfc.section.9.3.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    20772077         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    20782078         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    … …  
    21912191</pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    21922192      </p>
    2193       <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p>
     2193      <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
    21942194      <div id="rfc.iref.u.5"></div>
    21952195      <div id="rfc.iref.h.14"></div>
    … …  
    28662866      <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers <em class="bcp14">SHOULD</em> be tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required.
    28672867      </p>
    2868       <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers,
    2869          recognize a single LF as a line terminator and ignore the leading CR.
     2868      <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers
     2869         fields, recognize a single LF as a line terminator and ignore the leading CR.
    28702870      </p>
    28712871      <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that
    … …  
    28842884         <li>All expiration-related calculations <em class="bcp14">MUST</em> be done in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
    28852885         </li>
    2886          <li>If an HTTP header incorrectly carries a date value with a time zone other than GMT, it <em class="bcp14">MUST</em> be converted into GMT using the most conservative possible conversion.
     2886         <li>If an HTTP header field incorrectly carries a date value with a time zone other than GMT, it <em class="bcp14">MUST</em> be converted into GMT using the most conservative possible conversion.
    28872887         </li>
    28882888      </ul>
    … …  
    29192919      <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    29202920      <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3>
    2921       <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification.
     2921      <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification.
    29222922      </p>
    29232923      <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
    … …  
    29312931      </p>
    29322932      <ul>
    2933          <li>Both clients and servers <em class="bcp14">MUST</em> support the Host request-header.
    2934          </li>
    2935          <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header.
    2936          </li>
    2937          <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header.
     2933         <li>Both clients and servers <em class="bcp14">MUST</em> support the Host request-header field.
     2934         </li>
     2935         <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header field.
     2936         </li>
     2937         <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header field.
    29382938         </li>
    29392939         <li>Servers <em class="bcp14">MUST</em> accept absolute URIs.
    … …  
    29542954         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;9.1</a>.
    29552955      </p>
    2956       <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     2956      <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented
     2957         in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    29572958      </p>
    29582959      <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    32603261         <li>Get rid of prose rules that span multiple lines.</li>
    32613262         <li>Get rid of unused rules LOALPHA and UPALPHA.</li>
    3262          <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li>
     3263         <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header field.</li>
    32633264         <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li>
    32643265         <li>Rewrite prose rule "token" in terms of "tchar", rewrite prose rule "TEXT".</li>
    … …  
    32723273         </li>
    32733274      </ul>
    3274       <p id="rfc.section.D.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    3275       </p>
    3276       <ul>
    3277          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     3275      <p id="rfc.section.D.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     3276      </p>
     3277      <ul>
     3278         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    32783279      </ul>
    32793280      <p id="rfc.section.D.4.p.3">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
    … …  
    33193320         <li>Only reference RFC 5234's core rules.</li>
    33203321         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    3321          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     3322         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    33223323      </ul>
    33233324      <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p1-messaging-05</a></h2>
    … …  
    33543355      <ul>
    33553356         <li>Rewrite introduction; add mostly new Architecture Section.</li>
    3356          <li>Move definition of quality values from Part 3 into Part 1; make TE request header grammar independent of accept-params (defined
    3357             in Part 3).
     3357         <li>Move definition of quality values from Part 3 into Part 1; make TE request header field grammar independent of accept-params
     3358            (defined in Part 3).
    33583359         </li>
    33593360      </ul>

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

    r992 r994  
    11991199<x:note>
    12001200  <t>
    1201    <x:h>Note:</x:h> The "Set-Cookie" header as implemented in
     1201   <x:h>Note:</x:h> The "Set-Cookie" header field as implemented in
    12021202   practice (as opposed to how it is specified in <xref target="RFC2109"/>)
    12031203   can occur multiple times, but does not use the list syntax, and thus cannot
    12041204   be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/>
    1205    for details.) Also note that the Set-Cookie2 header specified in
     1205   for details.) Also note that the Set-Cookie2 header field specified in
    12061206   <xref target="RFC2965"/> does not share this problem.
    12071207  </t>
    … …  
    22632263  <x:anchor-alias value="qvalue"/>
    22642264<t>
    2265    Both transfer codings (TE request header, <xref target="header.te"/>)
     2265   Both transfer codings (TE request header field, <xref target="header.te"/>)
    22662266   and content negotiation (&content.negotiation;) use short "floating point"
    22672267   numbers to indicate the relative importance ("weight") of various
    … …  
    23622362<t>
    23632363   An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
    2364    maintain a persistent connection unless a Connection header including
     2364   maintain a persistent connection unless a Connection header field including
    23652365   the connection-token "close" was sent in the request. If the server
    23662366   chooses to close the connection immediately after sending the
    2367    response, it &SHOULD; send a Connection header including the
     2367   response, it &SHOULD; send a Connection header field including the
    23682368   connection-token "close".
    23692369</t>
    … …  
    23712371   An HTTP/1.1 client &MAY; expect a connection to remain open, but would
    23722372   decide to keep it open based on whether the response from a server
    2373    contains a Connection header with the connection-token close. In case
     2373   contains a Connection header field with the connection-token close. In case
    23742374   the client does not want to maintain a connection for more than that
    2375    request, it &SHOULD; send a Connection header including the
     2375   request, it &SHOULD; send a Connection header field including the
    23762376   connection-token close.
    23772377</t>
    23782378<t>
    23792379   If either the client or the server sends the close token in the
    2380    Connection header, that request becomes the last one for the
     2380   Connection header field, that request becomes the last one for the
    23812381   connection.
    23822382</t>
    … …  
    24352435   A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
    24362436   with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
    2437    for information and discussion of the problems with the Keep-Alive header
     2437   for information and discussion of the problems with the Keep-Alive header field
    24382438   implemented by many HTTP/1.0 clients).
    24392439</t>
    24402440
    2441 <section title="End-to-end and Hop-by-hop Headers" anchor="end-to-end.and.hop-by-hop.headers">
     2441<section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields">
    24422442<!--<t>
    24432443  <cref anchor="TODO-end-to-end" source="jre">
    … …  
    24482448<t>
    24492449   For the purpose of defining the behavior of caches and non-caching
    2450    proxies, we divide HTTP headers into two categories:
     2450   proxies, we divide HTTP header fields into two categories:
    24512451  <list style="symbols">
    2452       <t>End-to-end headers, which are  transmitted to the ultimate
    2453         recipient of a request or response. End-to-end headers in
     2452      <t>End-to-end header fields, which are  transmitted to the ultimate
     2453        recipient of a request or response. End-to-end header fields in
    24542454        responses MUST be stored as part of a cache entry and &MUST; be
    24552455        transmitted in any response formed from a cache entry.</t>
    24562456
    2457       <t>Hop-by-hop headers, which are meaningful only for a single
     2457      <t>Hop-by-hop header fields, which are meaningful only for a single
    24582458        transport-level connection, and are not stored by caches or
    24592459        forwarded by proxies.</t>
    … …  
    24612461</t>
    24622462<t>
    2463    The following HTTP/1.1 headers are hop-by-hop headers:
     2463   The following HTTP/1.1 header fields are hop-by-hop header fields:
    24642464  <list style="symbols">
    24652465      <t>Connection</t>
    … …  
    24742474</t>
    24752475<t>
    2476    All other headers defined by HTTP/1.1 are end-to-end headers.
    2477 </t>
    2478 <t>
    2479    Other hop-by-hop headers &MUST; be listed in a Connection header
     2476   All other header fields defined by HTTP/1.1 are end-to-end header fields.
     2477</t>
     2478<t>
     2479   Other hop-by-hop header fields &MUST; be listed in a Connection header field
    24802480   (<xref target="header.connection"/>).
    24812481</t>
    24822482</section>
    24832483
    2484 <section title="Non-modifiable Headers" anchor="non-modifiable.headers">
     2484<section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields">
    24852485<!--<t>
    24862486  <cref anchor="TODO-non-mod-headers" source="jre">
    … …  
    24912491<t>
    24922492   Some features of HTTP/1.1, such as Digest Authentication, depend on the
    2493    value of certain end-to-end headers. A transparent proxy &SHOULD-NOT;
    2494    modify an end-to-end header unless the definition of that header requires
     2493   value of certain end-to-end header fields. A transparent proxy &SHOULD-NOT;
     2494   modify an end-to-end header field unless the definition of that header field requires
    24952495   or specifically allows that.
    24962496</t>
    … …  
    25152515<t>
    25162516   but it &MAY; add any of these fields if not already present. If an
    2517    Expires header is added, it &MUST; be given a field-value identical to
    2518    that of the Date header in that response.
     2517   Expires header field is added, it &MUST; be given a field-value identical to
     2518   that of the Date header field in that response.
    25192519</t>
    25202520<t>
    … …  
    25362536<x:note>
    25372537  <t>
    2538     <x:h>Warning:</x:h> Unnecessary modification of end-to-end headers might
     2538    <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might
    25392539    cause authentication failures if stronger authentication
    25402540    mechanisms are introduced in later versions of HTTP. Such
    … …  
    26402640   using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
    26412641   empty trailer &MAY; be used to prematurely mark the end of the message.
    2642    If the body was preceded by a Content-Length header, the client &MUST;
     2642   If the body was preceded by a Content-Length header field, the client &MUST;
    26432643   close the connection.
    26442644</t>
    … …  
    26502650   allow a client that is sending a request message with a request body
    26512651   to determine if the origin server is willing to accept the request
    2652    (based on the request headers) before the client sends the request
     2652   (based on the request header fields) before the client sends the request
    26532653   body. In some cases, it might either be inappropriate or highly
    26542654   inefficient for the client to send the body if the server will reject
    … …  
    27712771    </t>
    27722772    <t>
    2773       Transmit the request-headers
     2773      Transmit the request-header fields
    27742774    </t>
    27752775    <t>
    … …  
    28642864</t>
    28652865<t>
    2866    The Connection header's value has the following grammar:
     2866   The Connection header field's value has the following grammar:
    28672867</t>
    28682868<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="Connection-v"/><iref primary="true" item="Grammar" subitem="connection-token"/>
    … …  
    28822882</t>
    28832883<t>
    2884    Message headers listed in the Connection header &MUST-NOT; include
    2885    end-to-end headers, such as Cache-Control.
     2884   Message header fields listed in the Connection header field &MUST-NOT; include
     2885   end-to-end header fields, such as Cache-Control.
    28862886</t>
    28872887<t>
    … …  
    29092909<t>
    29102910   A system receiving an HTTP/1.0 (or lower-version) message that
    2911    includes a Connection header &MUST;, for each connection-token in this
     2911   includes a Connection header field &MUST;, for each connection-token in this
    29122912   field, remove and ignore any header field(s) from the message with
    29132913   the same name as the connection-token. This protects against mistaken
    … …  
    30153015</t>
    30163016<t>
    3017    The HTTP-date sent in a Date header &SHOULD-NOT;  represent a date and
     3017   The HTTP-date sent in a Date header field &SHOULD-NOT;  represent a date and
    30183018   time subsequent to the generation of the message. It &SHOULD; represent
    30193019   the best available approximation of the date and time of message
    … …  
    32393239<t>
    32403240   Many older HTTP/1.0 applications do not understand the Transfer-Encoding
    3241    header.
     3241   header field.
    32423242</t>
    32433243</section>
    … …  
    46864686<t>
    46874687   The line terminator for header fields is the sequence CRLF.
    4688    However, we recommend that applications, when parsing such headers,
     4688   However, we recommend that applications, when parsing such headers fields,
    46894689   recognize a single LF as a line terminator and ignore the leading CR.
    46904690</t>
    … …  
    47184718        of an age or expiration time.</t>
    47194719
    4720      <t>If an HTTP header incorrectly carries a date value with a time
     4720     <t>If an HTTP header field incorrectly carries a date value with a time
    47214721        zone other than GMT, it &MUST; be converted into GMT using the
    47224722        most conservative possible conversion.</t>
    … …  
    47844784<section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
    47854785<t>
    4786    The requirements that clients and servers support the Host request-header,
    4787    report an error if the Host request-header (<xref target="header.host"/>) is
     4786   The requirements that clients and servers support the Host request-header
     4787   field (<xref target="header.host"/>), report an error if it is
    47884788   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    47894789   are among the most important changes defined by this
    … …  
    48074807   requirements:
    48084808  <list style="symbols">
    4809      <t>Both clients and servers &MUST; support the Host request-header.</t>
    4810 
    4811      <t>A client that sends an HTTP/1.1 request &MUST; send a Host header.</t>
     4809     <t>Both clients and servers &MUST; support the Host request-header field.</t>
     4810
     4811     <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t>
    48124812
    48134813     <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1
    4814         request does not include a Host request-header.</t>
     4814        request does not include a Host request-header field.</t>
    48154815
    48164816     <t>Servers &MUST; accept absolute URIs.</t>
    … …  
    48474847<t>
    48484848   The original HTTP/1.0 form of persistent connections (the Connection:
    4849    Keep-Alive and Keep-Alive header) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
     4849   Keep-Alive and Keep-Alive header field) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
    48504850</t>
    48514851</section>
    … …  
    52735273    <t>
    52745274      Move "Product Tokens" section (back) into Part 1, as "token" is used
    5275       in the definition of the Upgrade header.
     5275      in the definition of the Upgrade header field.
    52765276    </t>
    52775277    <t>
    … …  
    53005300</t>
    53015301<t>
    5302   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     5302  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    53035303  <list style="symbols">
    53045304    <t>
    5305       Reference RFC 3984, and update header registrations for headers defined
     5305      Reference RFC 3984, and update header field registrations for headers defined
    53065306      in this document.
    53075307    </t>
    … …  
    53935393    <t>
    53945394      Rewrite ABNFs to spell out whitespace rules, factor out
    5395       header value format definitions.
     5395      header field value format definitions.
    53965396    </t>
    53975397  </list>
    … …  
    54645464    <t>
    54655465      Move definition of quality values from Part 3 into Part 1;
    5466       make TE request header grammar independent of accept-params (defined in Part 3).
     5466      make TE request header field grammar independent of accept-params (defined in Part 3).
    54675467    </t>
    54685468  </list>

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

    r981 r994  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: March 5, 2011</td>
     436               <td class="left">Expires: March 11, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">September 1, 2010</td>
     489               <td class="right">September 7, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire on March 5, 2011.</p>
     516      <p>This Internet-Draft will expire on March 11, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    917917         </li>
    918918         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
    919             representation of the target (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    920          </li>
    921          <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload
     919            representation of the target (see <a href="p6-cache.html#combining.responses" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     920         </li>
     921         <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
    922922            is a representation of the target resource.
    923923         </li>
    924          <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response
     924         <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
    925925            asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
    926926            cannot be trusted unless it can be verified by other means (not defined by HTTP).
    … …  
    10051005      <div id="rfc.iref.h.1"></div>
    10061006      <div id="rfc.iref.m.3"></div>
    1007       <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP headers in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
     1007      <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
    10081008         representation implied by the request without transferring the representation body. This method is often used for testing
    10091009         hypertext links for validity, accessibility, and recent modification.
    … …  
    10331033      </p>
    10341034      <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
    1035          a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
    1036       </p>
    1037       <p id="rfc.section.7.5.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.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1035         a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
     1036      </p>
     1037      <p id="rfc.section.7.5.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.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    10381038      </p>
    10391039      <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
    … …  
    10511051         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    10521052      </p>
    1053       <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
     1053      <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* header fields (headers starting with the prefix "Content-") that it does not understand or implement
     1054         and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    10541055      </p>
    10551056      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
    … …  
    11061107      <p id="rfc.section.8.p.1">Each Status-Code is described below, including any metadata required in the response.</p>
    11071108      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>
    1108       <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is
    1109          terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any
    1110          1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     1109      <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional header fields,
     1110         and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did
     1111         not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    11111112      </p>
    11121113      <p id="rfc.section.8.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100
    … …  
    13611362      <div id="rfc.iref.s.24"></div>
    13621363      <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    1363       <p id="rfc.section.8.4.6.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 containing a list of valid methods for the requested resource.
     1364      <p id="rfc.section.8.4.6.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.
    13641365      </p>
    13651366      <div id="rfc.iref.48"></div>
    … …  
    13671368      <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
    13681369      <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    1369          not acceptable according to the accept headers sent in the request.
     1370         not acceptable according to the accept header fields sent in the request.
    13701371      </p>
    13711372      <p id="rfc.section.8.4.7.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
    … …  
    13741375      </p>
    13751376      <div class="note" id="rfc.section.8.4.7.p.3">
    1376          <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.
    1377             In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the headers
    1378             of an incoming response to determine if it is acceptable.
     1377         <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the
     1378            request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the
     1379            header fields of an incoming response to determine if it is acceptable.
    13791380         </p>
    13801381      </div>
    … …  
    14901491      <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
    14911492      <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication
    1492          is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
     1493         is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
    14931494      </p>
    14941495      <div class="note" id="rfc.section.8.5.4.p.2">
    … …  
    15511552      </p>
    15521553      <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the
    1553          Expect request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
    1554       </p>
    1555       <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
     1554         Expect request-header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
     1555      </p>
     1556      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    15561557      <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
    15571558      </p>
    … …  
    15681569      <div id="rfc.figure.u.16"></div><pre class="text">  From: webmaster@example.org
    15691570</pre><p id="rfc.section.9.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    1570          on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving
     1571         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving
    15711572         end.
    15721573      </p>
    … …  
    15961597</pre><p id="rfc.section.9.4.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p>
    15971598      <ul>
    1598          <li>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</li>
     1599         <li>With a 201 Created response, because in this usage the Location header field specifies the URI for the entire created resource.</li>
    15991600         <li>With 305 Use Proxy.</li>
    16001601      </ul>
    … …  
    16291630         URI was obtained (the "referrer", although the header field is misspelled.).
    16301631      </p>
    1631       <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc.
    1632          It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
     1632      <p id="rfc.section.9.6.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
     1633         etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
    16331634         where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field.
    16341635      </p>
    … …  
    16731674</pre><p id="rfc.section.9.8.p.4">Example:</p>
    16741675      <div id="rfc.figure.u.27"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    1675 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1676</pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    16761677      </p>
    16771678      <div class="note" id="rfc.section.9.8.p.7">
    … …  
    20982099         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
    20992100      </p>
    2100       <p id="rfc.section.11.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power
    2101          can be abused if user details are not separated from the information contained in the Referer. Even when the personal information
    2102          has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate.
     2101      <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
     2102         power can be abused if user details are not separated from the information contained in the Referer. Even when the personal
     2103         information has been removed, the Referer header field might indicate a private document's URI whose publication would be
     2104         inappropriate.
    21032105      </p>
    21042106      <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
    … …  
    21122114         has no better mechanism.
    21132115      </p>
    2114       <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request headers within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
    2115          data from the client.
     2116      <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</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
     2117         to collect data from the client.
    21162118      </p>
    21172119      <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>
    … …  
    21282130      </p>
    21292131      <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
    2130       <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 headers in responses that are generated under control of said organizations
     2132      <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
    21312133         to make sure that they do not attempt to invalidate resources over which they have no authority.
    21322134      </p>
    … …  
    22522254         was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;8.3.6</a>)
    22532255      </p>
    2254       <p id="rfc.section.A.p.5">Reclassify Allow header as response header, removing the option to specify it in a PUT request. Relax the server requirement
    2255          on the contents of the Allow header and remove requirement on clients to always trust the header value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.1</a>)
    2256       </p>
    2257       <p id="rfc.section.A.p.6">Correct syntax of Location header to allow URI references (including relative references and fragments), as referred symbol
    2258          "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
     2256      <p id="rfc.section.A.p.5">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
     2257         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.1</a>)
     2258      </p>
     2259      <p id="rfc.section.A.p.6">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
     2260         symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    22592261         (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;9.4</a>)
    22602262      </p>
    2261       <p id="rfc.section.A.p.7">Allow Referer 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.6</a>)
    2262       </p>
    2263       <p id="rfc.section.A.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly
    2264          in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><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.8</a>)
     2263      <p id="rfc.section.A.p.7">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.6</a>)
     2264      </p>
     2265      <p id="rfc.section.A.p.8">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
     2266         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><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.8</a>)
    22652267      </p>
    22662268      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    24222424      </p>
    24232425      <ul>
    2424          <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li>
     2426         <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header field.</li>
    24252427         <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li>
    24262428         <li>Copy definition of delta-seconds from Part6 instead of referencing it.</li>
    … …  
    24442446         </li>
    24452447      </ul>
    2446       <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     2448      <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    24472449      </p>
    24482450      <ul>
    2449          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     2451         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    24502452      </ul>
    24512453      <p id="rfc.section.C.4.p.3">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
    … …  
    24822484         <li>Use "/" instead of "|" for alternatives.</li>
    24832485         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    2484          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     2486         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    24852487      </ul>
    24862488      <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p2-semantics-05</a></h2>

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

    r981 r994  
    2222  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2323  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    24   <!ENTITY caching-combining-headers  "<xref target='Part6' x:rel='#combining.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     24  <!ENTITY combining-responses        "<xref target='Part6' x:rel='#combining.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2525  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2626  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    7878  <!ENTITY p6-explicit               "<xref target='Part6' x:rel='#calculating.freshness.lifetime'
    7979xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    80   <!ENTITY p6-combine               "<xref target='Part6' x:rel='#combining.headers'
    81 xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    8280]>
    8381<?rfc toc="yes" ?>
    … …  
    692690   <t>If the response status code is 204, 206, or 304 and the request method was GET
    693691   or HEAD, the response payload is a partial representation of the target
    694    (see &caching-combining-headers;).</t>
    695    <t>If the response has a Content-Location header, and that URI is the same
     692   (see &combining-responses;).</t>
     693   <t>If the response has a Content-Location header field, and that URI is the same
    696694   as the effective request URI, the response payload is a representation of the
    697695   target resource.</t>
    698    <t>If the response has a Content-Location header, and that URI is not the
     696   <t>If the response has a Content-Location header field, and that URI is not the
    699697   same as the effective request URI, then the response asserts that its
    700698   payload is a representation of the resource identified by the
    … …  
    874872   The HEAD method is identical to GET except that the server &MUST-NOT;
    875873   return a message-body in the response. The metadata contained
    876    in the HTTP headers in response to a HEAD request &SHOULD; be identical
     874   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    877875   to the information sent in response to a GET request. This method can
    878876   be used for obtaining metadata about the representation implied by the
    … …  
    932930   &SHOULD; be 201 (Created) and contain a representation which describes the
    933931   status of the request and refers to the new resource, and a Location
    934    header (see <xref target="header.location"/>).
     932   header field (see <xref target="header.location"/>).
    935933</t>
    936934<t>
    937935   Responses to POST requests are only cacheable when they
    938936   include explicit freshness information (see &p6-explicit;). A
    939    cached POST response with a Content-Location header
     937   cached POST response with a Content-Location header field
    940938   (see &header-content-location;) whose value is the effective
    941939   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
    … …  
    971969   error response &SHOULD; be given that reflects the nature of the problem.
    972970   The recipient of the representation &MUST-NOT; ignore any Content-*
    973    headers (headers starting with the prefix "Content-") that it does
     971   header fields (headers starting with the prefix "Content-") that it does
    974972   not understand or implement
    975973   and &MUST; return a 501 (Not Implemented) response in such cases.
    … …  
    10951093<t>
    10961094   This class of status code indicates a provisional response,
    1097    consisting only of the Status-Line and optional headers, and is
    1098    terminated by an empty line. There are no required headers for this
     1095   consisting only of the Status-Line and optional header fields, and is
     1096   terminated by an empty line. There are no required header fields for this
    10991097   class of status code. Since HTTP/1.0 did not define any 1xx status
    11001098   codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client
    … …  
    16191617   The method specified in the Request-Line is not allowed for the target
    16201618   resource. The response &MUST; include an
    1621    Allow header containing a list of valid methods for the requested
     1619   Allow header field containing a list of valid methods for the requested
    16221620   resource.
    16231621</t>
    … …  
    16301628   The resource identified by the request is only capable of generating
    16311629   response representations which have content characteristics not acceptable
    1632    according to the accept headers sent in the request.
     1630   according to the accept header fields sent in the request.
    16331631</t>
    16341632<t>
    … …  
    16451643  <t>
    16461644    <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are
    1647     not acceptable according to the accept headers sent in the
     1645    not acceptable according to the accept header fields sent in the
    16481646    request. In some cases, this might even be preferable to sending a
    1649     406 response. User agents are encouraged to inspect the headers of
     1647    406 response. User agents are encouraged to inspect the header fields of
    16501648    an incoming response to determine if it is acceptable.
    16511649  </t>
    … …  
    18721870   is that this is a temporary condition which will be alleviated after
    18731871   some delay. If known, the length of the delay &MAY; be indicated in a
    1874    Retry-After header. If no Retry-After is given, the client &SHOULD;
     1872   Retry-After header field. If no Retry-After is given, the client &SHOULD;
    18751873   handle the response as it would for a 500 response.
    18761874</t>
    … …  
    20011999   return a 417 (Expectation Failed) status code if it receives a request
    20022000   with an expectation that it cannot meet. However, the Expect
    2003    request-header itself is end-to-end; it &MUST; be forwarded if the
     2001   request-header field itself is end-to-end; it &MUST; be forwarded if the
    20042002   request is forwarded.
    20052003</t>
    20062004<t>
    20072005   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
    2008    Expect header.
     2006   Expect header field.
    20092007</t>
    20102008<t>
    … …  
    20432041   of this field is that the request is being performed on behalf of the
    20442042   person given, who accepts responsibility for the method performed. In
    2045    particular, robot agents &SHOULD; include this header so that the
     2043   particular, robot agents &SHOULD; include this header field so that the
    20462044   person responsible for running the robot can be contacted if problems
    20472045   occur on the receiving end.
    … …  
    20992097   <list style="symbols">
    21002098      <t>With a 201 Created response, because in this usage the Location header
    2101       specifies the URI for the entire created resource.</t>
     2099      field specifies the URI for the entire created resource.</t>
    21022100      <t>With 305 Use Proxy.</t>
    21032101   </list>
    … …  
    21692167</t>
    21702168<t>
    2171    The Referer header allows servers to generate lists of back-links to
     2169   The Referer header field allows servers to generate lists of back-links to
    21722170   resources for interest, logging, optimized caching, etc. It also allows
    21732171   obsolete or mistyped links to be traced for maintenance. Some servers use
    … …  
    22672265<t>
    22682266   If the response is being forwarded through a proxy, the proxy
    2269    application &MUST-NOT; modify the Server response-header. Instead, it
     2267   application &MUST-NOT; modify the Server response-header field. Instead, it
    22702268   &MUST; include a Via field (as described in &header-via;).
    22712269</t>
    … …  
    26862684</t>
    26872685<t>
    2688    The Referer header allows reading patterns to be studied and reverse
     2686   The Referer header field allows reading patterns to be studied and reverse
    26892687   links drawn. Although it can be very useful, its power can be abused
    26902688   if user details are not separated from the information contained in
    26912689   the Referer. Even when the personal information has been removed, the
    2692    Referer header might indicate a private document's URI whose
     2690   Referer header field might indicate a private document's URI whose
    26932691   publication would be inappropriate.
    26942692</t>
    … …  
    27152713<t>
    27162714   Some methods, like TRACE (<xref target="TRACE"/>), expose information
    2717    that was sent in request headers within the body of their response.
     2715   that was sent in request header fields within the body of their response.
    27182716   Clients &SHOULD; be careful with sensitive information, like Cookies,
    2719    Authorization credentials and other headers that might be used to
     2717   Authorization credentials and other header fields that might be used to
    27202718   collect data from the client.
    27212719</t>
    … …  
    27502748   If a single server supports multiple organizations that do not trust
    27512749   one another, then it &MUST; check the values of Location and Content-Location
    2752    headers in responses that are generated under control of
     2750   header fields in responses that are generated under control of
    27532751   said organizations to make sure that they do not attempt to
    27542752   invalidate resources over which they have no authority.
    … …  
    32843282</t>
    32853283<t>
    3286   Reclassify Allow header as response header, removing the option to
     3284  Reclassify "Allow" as response header field, removing the option to
    32873285  specify it in a PUT request.
    3288   Relax the server requirement on the contents of the Allow header and
    3289   remove requirement on clients to always trust the header value.
     3286  Relax the server requirement on the contents of the Allow header field and
     3287  remove requirement on clients to always trust the header field value.
    32903288  (<xref target="header.allow"/>)
    32913289</t>
    32923290<t>
    3293   Correct syntax of Location header to allow URI references (including
     3291  Correct syntax of Location header field to allow URI references (including
    32943292  relative references and fragments), as referred symbol "absoluteURI" wasn't
    32953293  what was expected, and add some clarifications as to when use of fragments
    … …  
    32983296</t>
    32993297<t>
    3300   Allow Referer value of "about:blank" as alternative to not specifying it.
     3298  Allow Referer field value of "about:blank" as alternative to not specifying it.
    33013299  (<xref target="header.referer"/>)
    33023300</t>
    33033301<t>
    3304   In the description of the Server header, the Via field
     3302  In the description of the Server header field, the Via field
    33053303  was described as a SHOULD. The requirement was and is stated
    3306   correctly in the description of the Via header in &header-via;.
     3304  correctly in the description of the Via header field in &header-via;.
    33073305  (<xref target="header.server"/>)
    33083306</t>
    … …  
    35113509    <t>
    35123510      Move "Product Tokens" section (back) into Part 1, as "token" is used
    3513       in the definition of the Upgrade header.
     3511      in the definition of the Upgrade header field.
    35143512    </t>
    35153513    <t>
    … …  
    35583556</t>
    35593557<t>
    3560   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     3558  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    35613559  <list style="symbols">
    35623560    <t>
    3563       Reference RFC 3984, and update header registrations for headers defined
     3561      Reference RFC 3984, and update header field registrations for headers defined
    35643562      in this document.
    35653563    </t>
    … …  
    36313629    <t>
    36323630      Rewrite ABNFs to spell out whitespace rules, factor out
    3633       header value format definitions.
     3631      header field value format definitions.
    36343632    </t>
    36353633  </list>

  • draft-ietf-httpbis/latest/p3-payload.html

    r987 r994  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-09-03">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: March 7, 2011</td>
     430               <td class="left">Expires: March 11, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    485485            <tr>
    486486               <td class="left"></td>
    487                <td class="right">September 3, 2010</td>
     487               <td class="right">September 7, 2010</td>
    488488            </tr>
    489489         </tbody>
    … …  
    511511         in progress”.
    512512      </p>
    513       <p>This Internet-Draft will expire on March 7, 2011.</p>
     513      <p>This Internet-Draft will expire on March 11, 2011.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    589589         </li>
    590590         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc">
    591                <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
     591               <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li>
    592592            </ul>
    593593         </li>
    … …  
    706706         Character Set registry <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry.
    707707      </p>
    708       <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token)
    709          and as the value of a parameter in a Content-Type header (within a request or response), in which case the parameter value
    710          of the charset parameter can be quoted.
     708      <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
     709         token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter
     710         value of the charset parameter can be quoted.
    711711      </p>
    712712      <p id="rfc.section.2.1.p.8">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>.
    713713      </p>
    714714      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="missing.charset" href="#missing.charset">Missing Charset</a></h3>
    715       <p id="rfc.section.2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should
    716          guess". Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
     715      <p id="rfc.section.2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header field without charset parameter incorrectly to mean "recipient
     716         should guess". Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
    717717      </p>
    718718      <p id="rfc.section.2.1.1.p.2">Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients <em class="bcp14">MUST</em> respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset <em class="bcp14">MUST</em> use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially
    … …  
    751751      <ul class="empty">
    752752         <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding
    753             header, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header.
     753            header field, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header field.
    754754         </li>
    755755      </ul>
    … …  
    996996      <div id="rfc.iref.h.1"></div>
    997997      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
    998       <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers
    999          can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request
    1000          for an in-line image.
     998      <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept header
     999         fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of
     1000         a request for an in-line image.
    10011001      </p>
    10021002      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
    … …  
    11151115         mentioned.
    11161116      </p>
    1117       <p id="rfc.section.6.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is
    1118          present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
     1117      <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character set is acceptable. If an Accept-Charset header
     1118         field is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header field,
     1119         then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
    11191120      </p>
    11201121      <div id="rfc.iref.a.3"></div>
    … …  
    11511152      </ol>
    11521153      <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
    1153          to the Accept-Encoding header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
     1154         to the Accept-Encoding header field, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
    11541155      </p>
    11551156      <p id="rfc.section.6.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
    … …  
    11931194         </p>
    11941195      </div>
    1195       <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
    1196          preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;8.1</a>.
     1196      <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
     1197         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section&nbsp;8.1</a>.
    11971198      </p>
    11981199      <p id="rfc.section.6.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
    … …  
    13191320         but this does not change how the digest is computed as defined in the preceding paragraph.
    13201321      </p>
    1321       <p id="rfc.section.6.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
    1322          headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the
    1323          body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application.
    1324          The Transfer-Encoding header field is not allowed within body-parts.
     1322      <p id="rfc.section.6.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP header fields (including Content-MD5, Content-Transfer-Encoding,
     1323         and Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding or Content-Encoding header field, it is
     1324         assumed that the content of the body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest
     1325         as is -- i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts.
    13251326      </p>
    13261327      <p id="rfc.section.6.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
    … …  
    14871488         make some suggestions for reducing security risks.
    14881489      </p>
    1489       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>
    1490       <p id="rfc.section.8.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header
    1491          in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
    1492          languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
    1493          to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration
    1494          process include a message which makes the user aware of the loss of privacy involved.
    1495       </p>
    1496       <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,
    1497          and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any
    1498          Vary response-header fields generated by the server, that such sending could improve the quality of service.
     1490      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</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>
     1491      <p id="rfc.section.8.1.p.1">Accept request-headers fields can reveal information about the user to all servers which are accessed. The Accept-Language
     1492         header field in particular can reveal information the user would consider to be of a private nature, because the understanding
     1493         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
     1494         the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
     1495         to let the configuration process include a message which makes the user aware of the loss of privacy involved.
     1496      </p>
     1497      <p id="rfc.section.8.1.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
     1498         by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
     1499         looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service.
    14991500      </p>
    15001501      <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
    … …  
    15041505         also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
    15051506         be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could
    1506          filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
     1507         filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
    15071508      </p>
    15081509      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    … …  
    17571758         experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.
    17581759      </p>
    1759       <p id="rfc.section.B.p.2">A number of other headers, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
     1760      <p id="rfc.section.B.p.2">A number of other header fields, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
    17601761      </p>
    17611762      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    … …  
    17631764      </p>
    17641765      <p id="rfc.section.C.p.2">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
    1765          servers emitting bogus Content-Location headers, and also the potentially undesirable effect of potentially breaking relative
    1766          links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
     1766         servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking
     1767         relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
    17671768      </p>
    17681769      <p id="rfc.section.C.p.3">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
    … …  
    19011902         </li>
    19021903      </ul>
    1903       <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1904      <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    19041905      </p>
    19051906      <ul>
    1906          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     1907         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    19071908      </ul>
    19081909      <h2 id="rfc.section.E.5"><a href="#rfc.section.E.5">E.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h2>
    … …  
    19321933         <li>Use "/" instead of "|" for alternatives.</li>
    19331934         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1934          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     1935         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    19351936      </ul>
    19361937      <h2 id="rfc.section.E.7"><a href="#rfc.section.E.7">E.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p3-payload-05</a></h2>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r987 r994  
    398398<t>
    399399   HTTP uses charset in two contexts: within an Accept-Charset request
    400    header (in which the charset value is an unquoted token) and as the
    401    value of a parameter in a Content-Type header (within a request or
     400   header field (in which the charset value is an unquoted token) and as the
     401   value of a parameter in a Content-Type header field (within a request or
    402402   response), in which case the parameter value of the charset parameter
    403403   can be quoted.
    … …  
    410410<section title="Missing Charset" anchor="missing.charset">
    411411<t>
    412    Some HTTP/1.0 software has interpreted a Content-Type header without
     412   Some HTTP/1.0 software has interpreted a Content-Type header field without
    413413   charset parameter incorrectly to mean "recipient should guess".
    414414   Senders wishing to defeat this behavior &MAY; include a charset
    … …  
    478478        The default (identity) encoding; the use of no transformation
    479479        whatsoever. This content-coding is used only in the Accept-Encoding
    480         header, and &SHOULD-NOT;  be used in the Content-Encoding
    481         header.
     480        header field, and &SHOULD-NOT;  be used in the Content-Encoding
     481        header field.
    482482  </t></list>
    483483</t>
    … …  
    979979<t>
    980980   The "Accept" request-header field can be used by user agents to specify
    981    response media types that are acceptable. Accept headers can be used to
     981   response media types that are acceptable. Accept header fields can be used to
    982982   indicate that the request is specifically limited to a small set of desired
    983983   types, as in the case of a request for an in-line image.
    … …  
    11331133</t>
    11341134<t>
    1135    If no Accept-Charset header is present, the default is that any
    1136    character set is acceptable. If an Accept-Charset header is present,
     1135   If no Accept-Charset header field is present, the default is that any
     1136   character set is acceptable. If an Accept-Charset header field is present,
    11371137   and if the server cannot send a response which is acceptable
    1138    according to the Accept-Charset header, then the server &SHOULD; send
     1138   according to the Accept-Charset header field, then the server &SHOULD; send
    11391139   an error response with the 406 (Not Acceptable) status code, though
    11401140   the sending of an unacceptable response is also allowed.
    … …  
    12011201   If an Accept-Encoding field is present in a request, and if the
    12021202   server cannot send a response which is acceptable according to the
    1203    Accept-Encoding header, then the server &SHOULD; send an error response
     1203   Accept-Encoding header field, then the server &SHOULD; send an error response
    12041204   with the 406 (Not Acceptable) status code.
    12051205</t>
    … …  
    12791279<t>
    12801280   It might be contrary to the privacy expectations of the user to send
    1281    an Accept-Language header with the complete linguistic preferences of
     1281   an Accept-Language header field with the complete linguistic preferences of
    12821282   the user in every request. For a discussion of this issue, see
    1283    <xref target="privacy.issues.connected.to.accept.headers"/>.
     1283   <xref target="privacy.issues.connected.to.accept.header.fields"/>.
    12841284</t>
    12851285<t>
    … …  
    15411541   There are several consequences of this. The payload for composite
    15421542   types &MAY; contain many body-parts, each with its own MIME and HTTP
    1543    headers (including Content-MD5, Content-Transfer-Encoding, and
    1544    Content-Encoding headers). If a body-part has a Content-Transfer-Encoding
    1545    or Content-Encoding header, it is assumed that the content
     1543   header fields (including Content-MD5, Content-Transfer-Encoding, and
     1544   Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding
     1545   or Content-Encoding header field, it is assumed that the content
    15461546   of the body-part has had the encoding applied, and the body-part is
    15471547   included in the Content-MD5 digest as is -- i.e., after the
    … …  
    17301730</t>
    17311731
    1732 <section title="Privacy Issues Connected to Accept Headers" anchor="privacy.issues.connected.to.accept.headers">
    1733 <t>
    1734    Accept request-headers can reveal information about the user to all
    1735    servers which are accessed. The Accept-Language header in particular
     1732<section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
     1733<t>
     1734   Accept request-headers fields can reveal information about the user to all
     1735   servers which are accessed. The Accept-Language header field in particular
    17361736   can reveal information the user would consider to be of a private
    17371737   nature, because the understanding of particular languages is often
    17381738   strongly correlated to the membership of a particular ethnic group.
    17391739   User agents which offer the option to configure the contents of an
    1740    Accept-Language header to be sent in every request are strongly
     1740   Accept-Language header field to be sent in every request are strongly
    17411741   encouraged to let the configuration process include a message which
    17421742   makes the user aware of the loss of privacy involved.
    … …  
    17441744<t>
    17451745   An approach that limits the loss of privacy would be for a user agent
    1746    to omit the sending of Accept-Language headers by default, and to ask
    1747    the user whether or not to start sending Accept-Language headers to a
     1746   to omit the sending of Accept-Language header fields by default, and to ask
     1747   the user whether or not to start sending Accept-Language header fields to a
    17481748   server if it detects, by looking for any Vary response-header fields
    17491749   generated by the server, that such sending could improve the quality
    … …  
    17621762   privacy, user agents ought to be conservative in offering accept
    17631763   header configuration options to end users. As an extreme privacy
    1764    measure, proxies could filter the accept headers in relayed requests.
     1764   measure, proxies could filter the accept header fields in relayed requests.
    17651765   General purpose user agents which provide a high degree of header
    17661766   configurability &SHOULD; warn users about the loss of privacy which can
    … …  
    26472647</t>
    26482648<t>
    2649    A number of other headers, such as Content-Disposition and Title,
     2649   A number of other header fields, such as Content-Disposition and Title,
    26502650   from SMTP and MIME are also often implemented (see <xref target="RFC2076"/>).
    26512651</t>
    … …  
    26602660  Remove base URI setting semantics for Content-Location due to poor
    26612661  implementation support, which was caused by too many broken servers emitting
    2662   bogus Content-Location headers, and also the potentially undesirable effect
     2662  bogus Content-Location header fields, and also the potentially undesirable effect
    26632663  of potentially breaking relative links in content-negotiated resources.
    26642664  (<xref target="header.content-location"/>)
    … …  
    28552855</t>
    28562856<t>
    2857   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     2857  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    28582858  <list style="symbols">
    28592859    <t>
    2860       Reference RFC 3984, and update header registrations for headers defined
     2860      Reference RFC 3984, and update header field registrations for headers defined
    28612861      in this document.
    28622862    </t>
    … …  
    29172917    <t>
    29182918      Rewrite ABNFs to spell out whitespace rules, factor out
    2919       header value format definitions.
     2919      header field value format definitions.
    29202920    </t>
    29212921  </list>

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

    r981 r994  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: March 5, 2011</td>
     428               <td class="left">Expires: March 11, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">September 1, 2010</td>
     485               <td class="right">September 7, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire on March 5, 2011.</p>
     511      <p>This Internet-Draft will expire on March 11, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    598598      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    599599         errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on
    600          resource metadata will be discussed first and then followed by each conditional request-header, concluding with a definition
     600         resource metadata will be discussed first and then followed by each conditional request-header field, concluding with a definition
    601601         of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more
    602602         content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements
    … …  
    802802      <p id="rfc.section.4.p.11">or </p>
    803803      <ul>
    804          <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has
    805             a cache entry for the associated representation, and
     804         <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header field, because the client
     805            has a cache entry for the associated representation, and
    806806         </li>
    807807         <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
    … …  
    841841         </li>
    842842         <li><em class="bcp14">SHOULD</em> send a Last-Modified value if it is feasible to send one, unless the risk of a breakdown in semantic transparency that could
    843             result from using this date in an If-Modified-Since header would lead to serious problems.
     843            result from using this date in an If-Modified-Since header field would lead to serious problems.
    844844         </li>
    845845      </ul>
    … …  
    912912      <p id="rfc.section.6.1.p.5">The principle behind entity-tags is that only the service author knows the semantics of a resource well enough to select an
    913913         appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality
    914          would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0)
     914         would open up a can of worms. Thus, comparisons of any other header fields (except Last-Modified, for compatibility with HTTP/1.0)
    915915         are never used for purposes of validating a cache entry.
    916916      </p>
    … …  
    929929  <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    930930</pre><p id="rfc.section.6.2.p.4">If any of the entity-tags match the entity-tag of the representation that would have been returned in the response to a similar
    931          GET request (without the If-Match header) on that resource, or if "*" is given and any current representation exists for that
    932          resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
     931         GET request (without the If-Match header field) on that resource, or if "*" is given and any current representation exists
     932         for that resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    933933      </p>
    934934      <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
    … …  
    936936      </p>
    937937      <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the
    938          If-Match header <em class="bcp14">MUST</em> be ignored.
     938         If-Match header field <em class="bcp14">MUST</em> be ignored.
    939939      </p>
    940940      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
    … …  
    962962</pre><p id="rfc.section.6.3.p.3">An example of the field is:</p>
    963963      <div id="rfc.figure.u.12"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    964 </pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header and no Range header requests that the representation be transferred only if
    965          it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes the
    966          following cases:
     964</pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header field and no Range header field requests that the representation be transferred
     965         only if it has been modified since the date given by the If-Modified-Since header field. The algorithm for determining this
     966         includes the following cases:
    967967      </p>
    968968      <ol>
    … …  
    988988            field whenever possible.
    989989         </li>
    990          <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for
    991             the same request, the client needs to be aware that this date is interpreted in the server's understanding of time. Unsynchronized
    992             clocks and rounding problems, due to the different encodings of time between the client and server, are concerns. This includes
    993             the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since
    994             date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived
    995             from the client's clock without correction to the server's clock. Corrections for different time bases between client and
    996             server are at best approximate due to network latency.
     990         <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from the Last-Modified header
     991            field for the same request, the client needs to be aware that this date is interpreted in the server's understanding of time.
     992            Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server, are concerns.
     993            This includes the possibility of race conditions if the document has changed between the time it was first requested and the
     994            If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since
     995            date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between
     996            client and server are at best approximate due to network latency.
    997997         </li>
    998998      </ul>
    … …  
    10151015  <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    10161016</pre><p id="rfc.section.6.4.p.5">If any of the entity-tags match the entity-tag of the representation that would have been returned in the response to a similar
    1017          GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists
     1017         GET request (without the If-None-Match header field) on that resource, or if "*" is given and any current representation exists
    10181018         for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied
    10191019         in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the representations
    … …  
    10231023      </p>
    10241024      <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then
    1025          the If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
     1025         the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    10261026      </p>
    10271027      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
    … …  
    10411041      <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used to make a request method conditional. If the representation that would
    10421042         have been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified
    1043          in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header were not present.
     1043         in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header field were not present.
    10441044      </p>
    10451045      <p id="rfc.section.6.5.p.2">If the representation has been modified since the specified time, the server <em class="bcp14">MUST NOT</em> perform the requested operation, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed).
    … …  
    10501050</pre><p id="rfc.section.6.5.p.4">An example of the field is:</p>
    10511051      <div id="rfc.figure.u.16"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1052 </pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status
    1053          code, the If-Unmodified-Since header <em class="bcp14">SHOULD</em> be ignored.
    1054       </p>
    1055       <p id="rfc.section.6.5.p.7">If the specified date is invalid, the header is ignored.</p>
     1052</pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header field) would result in anything other than a 2xx or
     1053         412 status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
     1054      </p>
     1055      <p id="rfc.section.6.5.p.7">If the specified date is invalid, the header field is ignored.</p>
    10561056      <p id="rfc.section.6.5.p.8">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since
    10571057         header fields is undefined by this specification.
    … …  
    13161316         </li>
    13171317      </ul>
    1318       <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    1319       </p>
    1320       <ul>
    1321          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     1318      <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1319      </p>
     1320      <ul>
     1321         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
    13221322      </ul>
    13231323      <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p4-conditional-03</a></h2>
    … …  
    13371337         <li>Use "/" instead of "|" for alternatives.</li>
    13381338         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1339          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     1339         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    13401340      </ul>
    13411341      <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p4-conditional-05</a></h2>

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

    r981 r994  
    231231   A future draft will reorganize the sections to better reflect the content.
    232232   In particular, the sections on resource metadata will be discussed first
    233    and then followed by each conditional request-header, concluding with a
     233   and then followed by each conditional request-header field, concluding with a
    234234   definition of precedence and the expectation of ordering strong validator
    235235   checks before weak validator checks.  It is likely that more content from
    … …  
    573573  <list style="symbols">
    574574     <t>The validator is about to be used by a client in an If-Modified-Since
    575         or If-Unmodified-Since header, because the client
     575        or If-Unmodified-Since header field, because the client
    576576        has a cache entry for the associated representation, and</t>
    577577     <t>That cache entry includes a Date value, which gives the time
    … …  
    640640        unless the risk of a breakdown in semantic transparency that
    641641        could result from using this date in an If-Modified-Since header
    642         would lead to serious problems.</t>
     642        field would lead to serious problems.</t>
    643643  </list>
    644644</t>
    … …  
    764764   appropriate cache validation mechanism, and the specification of any
    765765   validator comparison function more complex than byte-equality would
    766    open up a can of worms. Thus, comparisons of any other headers
     766   open up a can of worms. Thus, comparisons of any other header fields
    767767   (except Last-Modified, for compatibility with HTTP/1.0) are never
    768768   used for purposes of validating a cache entry.
    … …  
    795795   If any of the entity-tags match the entity-tag of the representation that
    796796   would have been returned in the response to a similar GET request
    797    (without the If-Match header) on that resource, or if "*" is given
     797   (without the If-Match header field) on that resource, or if "*" is given
    798798   and any current representation exists for that resource, then the server &MAY;
    799799   perform the requested method as if the If-Match header field did not
    … …  
    810810<t>
    811811   If the request would, without the If-Match header field, result in
    812    anything other than a 2xx or 412 status code, then the If-Match header
     812   anything other than a 2xx or 412 status code, then the If-Match header field
    813813   &MUST; be ignored.
    814814</t>
    … …  
    864864</artwork></figure>
    865865<t>
    866    A GET method with an If-Modified-Since header and no Range header
    867    requests that the representation be transferred only if it has
    868    been modified since the date given by the If-Modified-Since header.
     866   A GET method with an If-Modified-Since header field and no Range header
     867   field requests that the representation be transferred only if it has
     868   been modified since the date given by the If-Modified-Since header field.
    869869   The algorithm for determining this includes the following cases:
    870870  <list style="numbers">
    … …  
    902902    </t><t>
    903903      <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since
    904       header instead of a date taken from the Last-Modified header for
     904      header field instead of a date taken from the Last-Modified header field for
    905905      the same request, the client needs to be aware that this
    906906      date is interpreted in the server's understanding of time.
    … …  
    954954   If any of the entity-tags match the entity-tag of the representation that
    955955   would have been returned in the response to a similar GET request
    956    (without the If-None-Match header) on that resource, or if "*" is
     956   (without the If-None-Match header field) on that resource, or if "*" is
    957957   given and any current representation exists for that resource, then the
    958958   server &MUST-NOT; perform the requested method, unless required to do
    … …  
    975975   If the request would, without the If-None-Match header field, result
    976976   in anything other than a 2xx or 304 status code, then the If-None-Match
    977    header &MUST; be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of
     977   header field &MUST; be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of
    978978   server behavior when both If-Modified-Since and If-None-Match appear
    979979   in the same request.)
    … …  
    10141014   in a 200 response to a GET request on the same resource has not been modified
    10151015   since the time specified in this field, the server &SHOULD; perform the
    1016    requested operation as if the If-Unmodified-Since header were not
     1016   requested operation as if the If-Unmodified-Since header field were not
    10171017   present.
    10181018</t>
    … …  
    10351035<t>
    10361036   If the request normally (i.e., without the If-Unmodified-Since
    1037    header) would result in anything other than a 2xx or 412 status code,
    1038    the If-Unmodified-Since header &SHOULD; be ignored.
    1039 </t>
    1040 <t>
    1041    If the specified date is invalid, the header is ignored.
     1037   header field) would result in anything other than a 2xx or 412 status code,
     1038   the If-Unmodified-Since header field &SHOULD; be ignored.
     1039</t>
     1040<t>
     1041   If the specified date is invalid, the header field is ignored.
    10421042</t>
    10431043<t>
    … …  
    15851585</t>
    15861586<t>
    1587   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     1587  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    15881588  <list style="symbols">
    15891589    <t>
    1590       Reference RFC 3984, and update header registrations for headers defined
     1590      Reference RFC 3984, and update header field registrations for header fields defined
    15911591      in this document.
    15921592    </t>
    … …  
    16281628    <t>
    16291629      Rewrite ABNFs to spell out whitespace rules, factor out
    1630       header value format definitions.
     1630      header field value format definitions.
    16311631    </t>
    16321632  </list>

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

    r981 r994  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: March 5, 2011</td>
     428               <td class="left">Expires: March 11, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">September 1, 2010</td>
     485               <td class="right">September 7, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire on March 5, 2011.</p>
     511      <p>This Internet-Draft will expire on March 11, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    645645         unit defined by HTTP/1.1 is "bytes". Additional specifiers can be defined as described in <a href="#range.specifier.registry" title="Range Specifier Registry">Section&nbsp;2.1</a>.
    646646      </p>
    647       <p id="rfc.section.2.p.4">If a range unit is not understood in a request, a server <em class="bcp14">MUST</em> ignore the whole Range header (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section&nbsp;5.4</a>). If a range unit is not understood in a response, an intermediary <em class="bcp14">SHOULD</em> pass the response to the client; a client <em class="bcp14">MUST</em> fail.
     647      <p id="rfc.section.2.p.4">If a range unit is not understood in a request, a server <em class="bcp14">MUST</em> ignore the whole Range header field (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section&nbsp;5.4</a>). If a range unit is not understood in a response, an intermediary <em class="bcp14">SHOULD</em> pass the response to the client; a client <em class="bcp14">MUST</em> fail.
    648648      </p>
    649649      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="range.specifier.registry" href="#range.specifier.registry">Range Specifier Registry</a></h2>
    … …  
    679679      <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request.
    680680      </p>
    681       <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Ranges">Section&nbsp;4</a>.
    682       </p>
    683       <p id="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> cache 206 (Partial Content) responses. Furthermore, if a response uses a range unit that is not understood by the cache, then
     681      <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified header fields do not match exactly,
     682         see <a href="#combining.byte.ranges" title="Combining Ranges">Section&nbsp;4</a>.
     683      </p>
     684      <p id="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range header fields <em class="bcp14">MUST NOT</em> cache 206 (Partial Content) responses. Furthermore, if a response uses a range unit that is not understood by the cache, then
    684685         it <em class="bcp14">MUST NOT</em> be cached either.
    685686      </p>
    … …  
    721722      </p>
    722723      <div id="rfc.figure.u.6"></div><pre class="text">  Accept-Ranges: bytes
    723 </pre><p id="rfc.section.5.1.p.5">but are not required to do so. Clients <em class="bcp14">MAY</em> generate range requests without having received this header for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
     724</pre><p id="rfc.section.5.1.p.5">but are not required to do so. Clients <em class="bcp14">MAY</em> generate range requests without having received this header field for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
    724725      </p>
    725726      <p id="rfc.section.5.1.p.6">Servers that do not accept any kind of range request for a resource <em class="bcp14">MAY</em> send
    … …  
    752753                             <a href="#header.content-range" class="smpl">other-range-resp-spec</a>
    753754  <a href="#header.content-range" class="smpl">other-range-resp-spec</a>    = *<a href="#notation" class="smpl">CHAR</a>
    754 </pre><p id="rfc.section.5.2.p.4">The header <em class="bcp14">SHOULD</em> indicate the total length of the full representation, unless this length is unknown or difficult to determine. The asterisk
     755</pre><p id="rfc.section.5.2.p.4">The header field <em class="bcp14">SHOULD</em> indicate the total length of the full representation, unless this length is unknown or difficult to determine. The asterisk
    755756         "*" character means that the instance-length is unknown at the time when the response was generated.
    756757      </p>
    … …  
    779780      </ul>
    780781      <p id="rfc.section.5.2.p.9">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to
    781          a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header, and
    782          a Content-Length header showing the number of bytes actually transferred. For example,
     782         a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header field,
     783         and a Content-Length header field showing the number of bytes actually transferred. For example,
    783784      </p>
    784785      <div id="rfc.figure.u.13"></div><pre class="text">  HTTP/1.1 206 Partial Content
    … …  
    805806      <div class="note" id="rfc.section.5.2.p.16">
    806807         <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for
    807             an unsatisfiable Range request-header, since not all servers implement this request-header.
     808            an unsatisfiable Range request-header field, since not all servers implement this request-header field.
    808809         </p>
    809810      </div>
    … …  
    812813      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    813814      <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation in its cache, and wishes to have an up-to-date copy of the entire representation
    814          in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and
    815          If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make
    816          a second request to obtain the entire current representation.
     815         in its cache, it could use the Range request-header field with a conditional GET (using either or both of If-Unmodified-Since
     816         and If-Match.) However, if the condition fails because the representation has been modified, the client would then have to
     817         make a second request to obtain the entire current representation.
    817818      </p>
    818819      <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is "if
    … …  
    821822      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.if-range" class="smpl">If-Range</a>   = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a>
    822823  <a href="#header.if-range" class="smpl">If-Range-v</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    823 </pre><p id="rfc.section.5.3.p.4">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining
    824          no more than two characters.) The If-Range header <em class="bcp14">SHOULD</em> only be used together with a Range header, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header, or if the server does not support the sub-range operation.
    825       </p>
    826       <p id="rfc.section.5.3.p.5">If the entity-tag given in the If-Range header matches the current cache validator for the representation, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
     824</pre><p id="rfc.section.5.3.p.4">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header field. (The server can distinguish between a valid HTTP-date and any form of entity-tag
     825         by examining no more than two characters.) The If-Range header field <em class="bcp14">SHOULD</em> only be used together with a Range header field, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header field, or if the server does not support the sub-range operation.
     826      </p>
     827      <p id="rfc.section.5.3.p.5">If the entity-tag given in the If-Range header field matches the current cache validator for the representation, then the
     828         server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
    827829         not match, then the server <em class="bcp14">SHOULD</em> return the entire representation using a 200 (OK) response.
    828830      </p>
    … …  
    896898  <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = <a href="#range.units" class="smpl">other-range-unit</a> "=" <a href="#range.retrieval.requests" class="smpl">other-range-set</a>
    897899  <a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*<a href="#notation" class="smpl">CHAR</a>
    898 </pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible,
    899          since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large
    900          representations.
    901       </p>
    902       <p id="rfc.section.5.4.2.p.4">If the server supports the Range header and the specified range or ranges are appropriate for the representation: </p>
    903       <ul>
    904          <li>The presence of a Range header in an unconditional GET modifies what is returned if the GET is otherwise successful. In other
    905             words, the response carries a status code of 206 (Partial Content) instead of 200 (OK).
    906          </li>
    907          <li>The presence of a Range header in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match, or
    908             one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition
     900</pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header field. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when
     901         possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval
     902         of large representations.
     903      </p>
     904      <p id="rfc.section.5.4.2.p.4">If the server supports the Range header field and the specified range or ranges are appropriate for the representation: </p>
     905      <ul>
     906         <li>The presence of a Range header field in an unconditional GET modifies what is returned if the GET is otherwise successful.
     907            In other words, the response carries a status code of 206 (Partial Content) instead of 200 (OK).
     908         </li>
     909         <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match,
     910            or one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition
    909911            is true. It does not affect the 304 (Not Modified) response returned if the conditional is false.
    910912         </li>
    911913      </ul>
    912       <p id="rfc.section.5.4.2.p.5">In some cases, it might be more appropriate to use the If-Range header (see <a href="#header.if-range" id="rfc.xref.header.if-range.3" title="If-Range">Section&nbsp;5.3</a>) in addition to the Range header.
     914      <p id="rfc.section.5.4.2.p.5">In some cases, it might be more appropriate to use the If-Range header field (see <a href="#header.if-range" id="rfc.xref.header.if-range.3" title="If-Range">Section&nbsp;5.3</a>) in addition to the Range header field.
    913915      </p>
    914916      <p id="rfc.section.5.4.2.p.6">If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire
    … …  
    12871289      </ul>
    12881290      <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a>&nbsp;<a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p5-range-02</a></h2>
    1289       <p id="rfc.section.D.4.p.1">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    1290       </p>
    1291       <ul>
    1292          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     1291      <p id="rfc.section.D.4.p.1">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1292      </p>
     1293      <ul>
     1294         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    12931295      </ul>
    12941296      <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p5-range-03</a></h2>
    … …  
    13041306         <li>Use "/" instead of "|" for alternatives.</li>
    13051307         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1306          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     1308         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    13071309      </ul>
    13081310      <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p5-range-05</a></h2>

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

    r981 r994  
    334334<t>
    335335  If a range unit is not understood in a request, a server &MUST; ignore
    336   the whole Range header (<xref target="header.range" />).
     336  the whole Range header field (<xref target="header.range"/>).
    337337  If a range unit is not understood in a response, an intermediary
    338338  &SHOULD; pass the response to the client; a client &MUST; fail.
    … …  
    403403<t>
    404404   A cache &MUST-NOT; combine a 206 response with other previously cached
    405    content if the ETag or Last-Modified headers do not match exactly,
     405   content if the ETag or Last-Modified header fields do not match exactly,
    406406   see <xref target="combining.byte.ranges"/>.
    407407</t>
    408408<t>
    409    A cache that does not support the Range and Content-Range headers
     409   A cache that does not support the Range and Content-Range header fields
    410410   &MUST-NOT; cache 206 (Partial Content) responses. Furthermore,
    411411   if a response uses a range unit that is not understood by the cache,
    … …  
    492492<t>
    493493      but are not required to do so. Clients &MAY; generate range
    494       requests without having received this header for the resource
     494      requests without having received this header field for the resource
    495495      involved. Range units are defined in <xref target="range.units"/>.
    496496</t>
    … …  
    546546</artwork></figure>
    547547<t>
    548    The header &SHOULD; indicate the total length of the full representation,
     548   The header field &SHOULD; indicate the total length of the full representation,
    549549   unless this length is unknown or difficult to determine. The asterisk
    550550   "*" character means that the instance-length is unknown at the time
    … …  
    606606   example, a response to a request for a single range, or to a request
    607607   for a set of ranges that overlap without any holes), this content is
    608    transmitted with a Content-Range header, and a Content-Length header
    609    showing the number of bytes actually transferred. For example,
     608   transmitted with a Content-Range header field, and a Content-Length header
     609   field showing the number of bytes actually transferred. For example,
    610610</t>
    611611<figure><artwork type="example">
    … …  
    655655    <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested
    656656    range not satisfiable) response instead of a 200 (OK) response for
    657     an unsatisfiable Range request-header, since not all servers
    658     implement this request-header.
     657    an unsatisfiable Range request-header field, since not all servers
     658    implement this request-header field.
    659659  </t>
    660660</x:note>
    … …  
    669669   If a client has a partial copy of a representation in its cache, and wishes
    670670   to have an up-to-date copy of the entire representation in its cache, it
    671    could use the Range request-header with a conditional GET (using
     671   could use the Range request-header field with a conditional GET (using
    672672   either or both of If-Unmodified-Since and If-Match.) However, if the
    673673   condition fails because the representation has been modified, the client
    … …  
    687687<t>
    688688   If the client has no entity-tag for a representation, but does have a Last-Modified
    689    date, it &MAY; use that date in an If-Range header. (The
     689   date, it &MAY; use that date in an If-Range header field. (The
    690690   server can distinguish between a valid HTTP-date and any form of
    691691   entity-tag by examining no more than two characters.) The If-Range
    692    header &SHOULD; only be used together with a Range header, and &MUST; be
    693    ignored if the request does not include a Range header, or if the
     692   header field &SHOULD; only be used together with a Range header field, and &MUST; be
     693   ignored if the request does not include a Range header field, or if the
    694694   server does not support the sub-range operation.
    695695</t>
    696696<t>
    697    If the entity-tag given in the If-Range header matches the current
     697   If the entity-tag given in the If-Range header field matches the current
    698698   cache validator for the representation, then the server &SHOULD; provide the
    699699   specified sub-range of the representation using a 206 (Partial Content)
    … …  
    840840</artwork></figure>
    841841<t>
    842    A server &MAY; ignore the Range header. However, HTTP/1.1 origin
     842   A server &MAY; ignore the Range header field. However, HTTP/1.1 origin
    843843   servers and intermediate caches ought to support byte ranges when
    844844   possible, since Range supports efficient recovery from partially
    … …  
    847847</t>
    848848<t>
    849    If the server supports the Range header and the specified range or
     849   If the server supports the Range header field and the specified range or
    850850   ranges are appropriate for the representation:
    851851  <list style="symbols">
    852      <t>The presence of a Range header in an unconditional GET modifies
     852     <t>The presence of a Range header field in an unconditional GET modifies
    853853        what is returned if the GET is otherwise successful. In other
    854854        words, the response carries a status code of 206 (Partial
    855855        Content) instead of 200 (OK).</t>
    856856
    857      <t>The presence of a Range header in a conditional GET (a request
     857     <t>The presence of a Range header field in a conditional GET (a request
    858858        using one or both of If-Modified-Since and If-None-Match, or
    859859        one or both of If-Unmodified-Since and If-Match) modifies what
    … …  
    865865<t>
    866866   In some cases, it might be more appropriate to use the If-Range
    867    header (see <xref target="header.if-range"/>) in addition to the Range header.
     867   header field (see <xref target="header.if-range"/>) in addition to the Range
     868   header field.
    868869</t>
    869870<t>
    … …  
    14981499<section title="Since draft-ietf-httpbis-p5-range-02" anchor="changes.since.02">
    14991500<t>
    1500   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     1501  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    15011502  <list style="symbols">
    15021503    <t>
    1503       Reference RFC 3984, and update header registrations for headers defined
     1504      Reference RFC 3984, and update header field registrations for headers defined
    15041505      in this document.
    15051506    </t>
    … …  
    15351536    <t>
    15361537      Rewrite ABNFs to spell out whitespace rules, factor out
    1537       header value format definitions.
     1538      header field value format definitions.
    15381539    </t>
    15391540  </list>

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

    r981 r994  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: March 5, 2011</td>
     430               <td class="left">Expires: March 11, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">September 1, 2010</td>
     491               <td class="right">September 7, 2010</td>
    492492            </tr>
    493493         </tbody>
    … …  
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire on March 5, 2011.</p>
     517      <p>This Internet-Draft will expire on March 11, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    563563               <li class="tocline1">2.6&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li>
    564564               <li class="tocline1">2.7&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
    565                <li class="tocline1">2.8&nbsp;&nbsp;&nbsp;<a href="#combining.headers">Combining Responses</a></li>
     565               <li class="tocline1">2.8&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Responses</a></li>
    566566            </ul>
    567567         </li>
    … …  
    724724         <li>The request method is understood by the cache and defined as being cacheable, and</li>
    725725         <li>the response status code is understood by the cache, and</li>
    726          <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers, and
     726         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response header fields, and
    727727         </li>
    728728         <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a> does not appear in the response, if the cache is shared, and
    729729         </li>
    730          <li>the "Authorization" header (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section&nbsp;2.6</a>), and
     730         <li>the "Authorization" header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section&nbsp;2.6</a>), and
    731731         </li>
    732732         <li>the response either:
    733733            <ul>
    734                <li>contains an Expires header (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
     734               <li>contains an Expires header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
    735735               </li>
    736736               <li>contains a max-age response cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), or
    … …  
    752752      </p>
    753753      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></h3>
    754       <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header)
    755          can store the response, but <em class="bcp14">MUST</em> treat it as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses can be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
    756       </p>
    757       <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
     754      <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header
     755         field) can store the response, but <em class="bcp14">MUST</em> treat it as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses can be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
     756      </p>
     757      <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range header fields <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
    758758      </p>
    759759      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
    … …  
    764764         </li>
    765765         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    766          <li>selecting request-headers nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>), and
     766         <li>selecting request-header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>), and
    767767         </li>
    768768         <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>), and
    … …  
    786786      <p id="rfc.section.2.2.p.4">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.5</a>.
    787787      </p>
    788       <p id="rfc.section.2.2.p.5">Caches <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header) when more than one suitable response is stored. They can also
    789          forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
     788      <p id="rfc.section.2.2.p.5">Caches <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field) when more than one suitable response is stored. They
     789         can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to
     790         use.
    790791      </p>
    791792      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
    … …  
    794795      </p>
    795796      <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    796          using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
     797         using either the Expires header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
    797798         is not likely to change in a semantically significant way before the expiration time is reached.
    798799      </p>
    … …  
    801802         requests.
    802803      </p>
    803       <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other header values
     804      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other heade field values
    804805         (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific
    805806         algorithms, but does impose worst-case constraints on their results.
    … …  
    824825         <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
    825826         </li>
    826          <li>If the Expires response header (<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, or
     827         <li>If the Expires 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
    827828         </li>
    828829         <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>.
    … …  
    834835         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for response status codes that do not explicitly allow it.
    835836      </p>
    836       <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, the cache <em class="bcp14">SHOULD</em> attach a Warning header with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is
    837          not already present.
    838       </p>
    839       <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
     837      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, the cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
     838         is not already present.
     839      </p>
     840      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
    840841      </p>
    841842      <div class="note" id="rfc.section.2.3.1.1.p.4">
    … …  
    846847      </div>
    847848      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
    848       <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The
    849          Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin
     849      <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age response-header field to convey the estimated age of the response message when obtained from a cache.
     850         The Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin
    850851         server. In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the
    851852         path from the origin server, plus the amount of time it has been in transit along network paths.
    … …  
    855856      </p>
    856857      <ul class="empty">
    857          <li>The term "age_value" denotes the value of the Age header (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
     858         <li>The term "age_value" denotes the value of the Age header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
    858859         </li>
    859860      </ul>
    … …  
    861862      </p>
    862863      <ul class="empty">
    863          <li>HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
    864             was generated. The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
    865             See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the definition of the Date header, and for requirements regarding responses without a Date response header.
     864         <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
     865            response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic
     866            operations. See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    866867         </li>
    867868      </ul>
    … …  
    913914         path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    914915      </p>
    915       <p id="rfc.section.2.3.3.p.4">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected.
     916      <p id="rfc.section.2.3.3.p.4">Stale responses <em class="bcp14">SHOULD</em> have a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected.
    916917      </p>
    917918      <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
    918          forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers). A cache <em class="bcp14">SHOULD NOT</em> attempt to validate a response simply because that response became stale in transit.
     919         forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields).
     920         A cache <em class="bcp14">SHOULD NOT</em> attempt to validate a response simply because that response became stale in transit.
    919921      </p>
    920922      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
    … …  
    923925         update it. This process is known as "validating" or "revalidating" the stored response.
    924926      </p>
    925       <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header whose value is that of the Last-Modified header from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
    926       </p>
    927       <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header whose value is that of the ETag header(s) from all responses stored for the requested URI, if
    928          present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
     927      <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
     928      </p>
     929      <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested
     930         URI, if present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
    929931         response.
    930932      </p>
    931       <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.8</a>.
     933      <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.responses" title="Combining Responses">Section&nbsp;2.8</a>.
    932934      </p>
    933935      <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
    … …  
    939941      <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
    940942      </p>
    941       <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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 headers (if present):
     943      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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 header fields (if present):
    942944      </p>
    943945      <ul>
    … …  
    946948         <li>POST</li>
    947949      </ul>
    948       <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed 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 4.3</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.
     950      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header field <em class="bcp14">MUST NOT</em> be performed 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 4.3</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.
    949951      </p>
    950952      <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>).
    … …  
    957959      </p>
    958960      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2>
    959       <p id="rfc.section.2.6.p.1">Shared caches <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header (<a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
     961      <p id="rfc.section.2.6.p.1">Shared caches <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
    960962      </p>
    961963      <p id="rfc.section.2.6.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
    … …  
    966968      </p>
    967969      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
    968       <p id="rfc.section.2.7.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-headers nominated by the Vary header match in both the original request
    969          (i.e., that associated with the stored response), and the presented request.
    970       </p>
    971       <p id="rfc.section.2.7.p.2">The selecting request-headers from two requests are defined to match if and only if those in the first request can be transformed
    972          to those in the second request by applying any of the following:
    973       </p>
    974       <ul>
    975          <li>adding or removing whitespace, where allowed in the header's syntax</li>
     970      <p id="rfc.section.2.7.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-header fields nominated by the Vary header field match in both the original
     971         request (i.e., that associated with the stored response), and the presented request.
     972      </p>
     973      <p id="rfc.section.2.7.p.2">The selecting request-header fields from two requests are defined to match if and only if those in the first request can be
     974         transformed to those in the second request by applying any of the following:
     975      </p>
     976      <ul>
     977         <li>adding or removing whitespace, where allowed in the header field's syntax</li>
    976978         <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
    977979         </li>
    978          <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification
     980         <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
    979981            (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
    980982         </li>
    … …  
    986988         by the origin server.
    987989      </p>
    988       <p id="rfc.section.2.7.p.5">The stored response with matching selecting request-headers is known as the selected response.</p>
     990      <p id="rfc.section.2.7.p.5">The stored response with matching selecting request-header fields is known as the selected response.</p>
    989991      <p id="rfc.section.2.7.p.6">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>.
    990992      </p>
    991       <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
     993      <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="combining.responses" href="#combining.responses">Combining Responses</a></h2>
    992994      <p id="rfc.section.2.8.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"),
    993995         it needs to created an updated response by combining the stored response with the new one, so that the updated response can
    … …  
    9981000      <p id="rfc.section.2.8.p.3">If the new response's status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
    9991001      </p>
    1000       <p id="rfc.section.2.8.p.4">The stored response headers are used as those of the updated response, except that </p>
    1001       <ul>
    1002          <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted.
    1003          </li>
    1004          <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained.
    1005          </li>
    1006          <li>any other headers provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding headers from the stored response.
    1007          </li>
    1008       </ul>
    1009       <p id="rfc.section.2.8.p.5">The updated response headers <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of
     1002      <p id="rfc.section.2.8.p.4">The stored response header fields are used as those of the updated response, except that </p>
     1003      <ul>
     1004         <li>any stored Warning header fields with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted.
     1005         </li>
     1006         <li>any stored Warning header fields with warn-code 2xx <em class="bcp14">MUST</em> be retained.
     1007         </li>
     1008         <li>any other header fields provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding header fields from the stored response.
     1009         </li>
     1010      </ul>
     1011      <p id="rfc.section.2.8.p.5">The updated response header fields <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of
    10101012         a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
    10111013      </p>
    … …  
    10251027      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    10261028</pre><p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows,
    1027          it <em class="bcp14">MUST</em> transmit an Age header with a field-value of 2147483648 (2<sup>31</sup>). Caches <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.
     1029         it <em class="bcp14">MUST</em> transmit an Age header field with a field-value of 2147483648 (2<sup>31</sup>). Caches <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.
    10281030      </p>
    10291031      <p id="rfc.section.3.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
    … …  
    11071109      </p>
    11081110      <ul class="empty">
    1109          <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request headers, nor the request representation.
     1111         <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request header fields, nor the request representation.
    11101112         </li>
    11111113      </ul>
    … …  
    11431145         </li>
    11441146         <li>If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated
    1145             with the listed response headers. That is, the specified field-names(s) <em class="bcp14">MUST NOT</em> be stored by a shared cache, whereas the remainder of the response message <em class="bcp14">MAY</em> be.
     1147            with the listed response header fields. That is, the specified field-names(s) <em class="bcp14">MUST NOT</em> be stored by a shared cache, whereas the remainder of the response message <em class="bcp14">MAY</em> be.
    11461148         </li>
    11471149         <li> <b>Note:</b> This usage of the word private only controls where the response can be stored; it cannot ensure the privacy of the message
    … …  
    11581160         </li>
    11591161         <li>If the no-cache response directive specifies one or more field-names, this requirement is limited to the field-values associated
    1160             with the listed response headers. That is, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful validation on the origin server. This allows an origin
     1162            with the listed response header fields. That is, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful validation on the origin server. This allows an origin
    11611163            server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
    11621164         </li>
    … …  
    12051207      <ul class="empty">
    12061208         <li>The s-maxage response directive indicates that, in shared caches, the maximum age specified by this directive overrides the
    1207             maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics
    1208             of the proxy-revalidate response directive.
     1209            maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the
     1210            semantics of the proxy-revalidate response directive.
    12091211         </li>
    12101212      </ul>
    … …  
    12121214      </p>
    12131215      <ul class="empty">
    1214          <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response headers, nor the response representation.
     1216         <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response header fields, nor the response representation.
    12151217         </li>
    12161218      </ul>
    … …  
    13051307      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span>  <a href="#header.vary" class="smpl">Vary</a>   = "Vary" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.vary" class="smpl">Vary-v</a>
    13061308  <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
    1307 </pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>
     1309</pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-header fields.</p>
    13081310      <p id="rfc.section.3.5.p.6">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
    13091311         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
    … …  
    13111313         the user agent with useful information about the dimensions over which the response varies at the time of the response.
    13121314      </p>
    1313       <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
    1314          of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
    1315          response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server.
     1315      <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-header fields (e.g., the network
     1316         address of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether
     1317         this response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server.
    13161318      </p>
    13171319      <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
    … …  
    13281330         code, distinguishes these responses from true failures.
    13291331      </p>
    1330       <p id="rfc.section.3.6.p.3">Warning headers can in general be applied to any message, however some warn-codes are specific to caches and can only be applied
    1331          to response messages.
     1332      <p id="rfc.section.3.6.p.3">Warning header fields can in general be applied to any message, however some warn-codes are specific to caches and can only
     1333         be applied to response messages.
    13321334      </p>
    13331335      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.warning" class="smpl">Warning</a>    = "Warning" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.warning" class="smpl">Warning-v</a>
    … …  
    13401342  <a href="#header.warning" class="smpl">warn-agent</a> = ( <a href="#abnf.dependencies" class="smpl">uri-host</a> [ ":" <a href="#abnf.dependencies" class="smpl">port</a> ] ) / <a href="#abnf.dependencies" class="smpl">pseudonym</a>
    13411343                  ; the name or pseudonym of the server adding
    1342                   ; the Warning header, for use in debugging
     1344                  ; the Warning header field, for use in debugging
    13431345  <a href="#header.warning" class="smpl">warn-text</a>  = <a href="#core.rules" class="smpl">quoted-string</a>
    13441346  <a href="#header.warning" class="smpl">warn-date</a>  = <a href="#notation" class="smpl">DQUOTE</a> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> <a href="#notation" class="smpl">DQUOTE</a>
    … …  
    13481350      <p id="rfc.section.3.6.p.6">When this occurs, the user agent <em class="bcp14">SHOULD</em> inform the user of as many of them as possible, in the order that they appear in the response.
    13491351      </p>
    1350       <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning headers <em class="bcp14">SHOULD</em> be added after any existing Warning headers.
     1352      <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning header fields <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning header fields <em class="bcp14">SHOULD</em> be added after any existing Warning headers fields.
    13511353      </p>
    13521354      <p id="rfc.section.3.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
    … …  
    13601362         </li>
    13611363      </ul>
    1362       <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning headers to a receiver whose version is HTTP/1.0 or lower, then
    1363          the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header in the message.
     1364      <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,
     1365         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.
    13641366      </p>
    13651367      <p id="rfc.section.3.6.p.10">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from
    13661368         the Date 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
    1367          header fields.) If all of the warning-values are deleted for this reason, the Warning header <em class="bcp14">MUST</em> be deleted as well.
     1369         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.
    13681370      </p>
    13691371      <p id="rfc.section.3.6.p.11">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description
    … …  
    16771679      <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.5</a>)
    16781680      </p>
    1679       <p id="rfc.section.A.p.4">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
     1681      <p id="rfc.section.A.p.4">Do not mention RFC 2047 encoding and multiple languages in Warning header fields anymore, as these aspects never were implemented.
    16801682         (<a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>)
    16811683      </p>
    … …  
    17961798      </ul>
    17971799      <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;<a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p6-cache-02</a></h2>
    1798       <p id="rfc.section.C.4.p.1">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    1799       </p>
    1800       <ul>
    1801          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     1800      <p id="rfc.section.C.4.p.1">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1801      </p>
     1802      <ul>
     1803         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
    18021804      </ul>
    18031805      <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p6-cache-03</a></h2>
    … …  
    18131815         <li>Use "/" instead of "|" for alternatives.</li>
    18141816         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1815          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     1817         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    18161818      </ul>
    18171819      <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p6-cache-05</a></h2>
    … …  
    18411843      <p id="rfc.section.C.8.p.2">Affected issues: </p>
    18421844      <ul>
    1843          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>&gt;: Vary and non-existant headers
     1845         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>&gt;: WVary and non-existant headers"
    18441846         </li>
    18451847      </ul>

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

    r981 r994  
    439439      <t>the "no-store" cache directive (see <xref
    440440      target="header.cache-control" />) does not appear in request or response
    441       headers, and</t>
     441      header fields, and</t>
    442442      <t>the "private" cache response directive (see <xref
    443443      target="cache-response-directive" /> does not appear in the response, if
    444444      the cache is shared, and</t>
    445       <t>the "Authorization" header (see &header-authorization;) does not
     445      <t>the "Authorization" header field (see &header-authorization;) does not
    446446      appear in the request, if the cache is shared, unless the response
    447447      explicitly allows it (see <xref target="caching.authenticated.responses"
    … …  
    449449      <t>the response either:
    450450         <list style="symbols">
    451             <t>contains an Expires header (see <xref target="header.expires"
     451            <t>contains an Expires header field (see <xref target="header.expires"
    452452            />), or</t>
    453453            <t>contains a max-age response cache directive (see <xref
    … …  
    482482<t>
    483483   A cache that receives an incomplete response (for example, with fewer bytes
    484    of data than specified in a Content-Length header) can store the response,
     484   of data than specified in a Content-Length header field) can store the response,
    485485   but &MUST; treat it as a partial response &partial;. Partial responses can
    486486   be combined as described in &combining-byte-ranges;; the result might be a
    … …  
    490490</t>
    491491<t>
    492    A cache that does not support the Range and Content-Range headers
     492   A cache that does not support the Range and Content-Range header fields
    493493   &MUST-NOT; store incomplete or partial responses.
    494494</t>
    … …  
    508508      <t>the request method associated with the stored response allows it to
    509509      be used for the presented request, and</t>
    510       <t>selecting request-headers nominated by the stored response (if any)
     510      <t>selecting request-header fields nominated by the stored response (if any)
    511511      match those presented (see <xref target="caching.negotiated.responses"
    512512      />), and</t>
    … …  
    543543<t>
    544544   Caches &MUST; use the most recent response (as determined by the Date
    545    header) when more than one suitable response is stored. They can also
     545   header field) when more than one suitable response is stored. They can also
    546546   forward a request with "Cache-Control: max-age=0" or "Cache-Control:
    547547   no-cache" to disambiguate which response to use.
    … …  
    558558   The primary mechanism for determining freshness is for an origin server to
    559559   provide an explicit expiration time in the future, using either the Expires
    560    header (<xref target="header.expires" />) or the max-age response cache
     560   header field (<xref target="header.expires" />) or the max-age response cache
    561561   directive (<xref target="cache-response-directive" />). Generally, origin
    562562   servers will assign future explicit expiration times to responses in the
    … …  
    573573   Since origin servers do not always provide explicit expiration times, HTTP
    574574   caches &MAY; assign heuristic expiration times when explicit times are not
    575    specified, employing algorithms that use other header values (such as the
     575   specified, employing algorithms that use other heade field values (such as the
    576576   Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1
    577577   specification does not provide specific algorithms, but does impose
    … …  
    619619      <t>If the max-age response cache directive (<xref
    620620      target="cache-response-directive" />) is present, use its value, or</t>
    621       <t>If the Expires response header (<xref target="header.expires" />) is
    622       present, use its value minus the value of the Date response header,
     621      <t>If the Expires response header field (<xref target="header.expires" />) is
     622      present, use its value minus the value of the Date response header field,
    623623      or</t>
    624624      <t>Otherwise, no explicit expiration time is present in the response. A
    … …  
    643643<t>
    644644   When a heuristic is used to calculate freshness lifetime, the cache
    645    &SHOULD; attach a Warning header with a 113 warn-code to the response if
     645   &SHOULD; attach a Warning header field with a 113 warn-code to the response if
    646646   its current_age is more than 24 hours and such a warning is not already
    647647   present.
    648648</t>
    649649<t>
    650    Also, if the response has a Last-Modified header (&header-last-modified;),
     650   Also, if the response has a Last-Modified header field (&header-last-modified;),
    651651   the heuristic expiration value &SHOULD; be no more than some fraction of
    652652   the interval since that time. A typical setting of this fraction might be
    … …  
    668668<section anchor="age.calculations" title="Calculating Age">
    669669<t>
    670    HTTP/1.1 uses the Age response-header to convey the estimated age of the
     670   HTTP/1.1 uses the Age response-header field to convey the estimated age of the
    671671   response message when obtained from a cache. The Age field value is the
    672672   cache's estimate of the amount of time since the response was generated or
    … …  
    683683   <list>
    684684      <t>
    685          The term "age_value" denotes the value of the Age header (<xref
     685         The term "age_value" denotes the value of the Age header field (<xref
    686686         target="header.age"/>), in a form appropriate for arithmetic
    687687         operation; or 0, if not available.
    … …  
    693693   <list>
    694694      <t>
    695          HTTP/1.1 requires origin servers to send a Date header, if possible,
     695         HTTP/1.1 requires origin servers to send a Date header field, if possible,
    696696         with every response, giving the time at which the response was
    697697         generated. The term "date_value" denotes the value of the Date
    698          header, in a form appropriate for arithmetic operations. See
    699          &header-date; for the definition of the Date header, and for
    700          requirements regarding responses without a Date response header.
     698         header field, in a form appropriate for arithmetic operations. See
     699         &header-date; for the definition of the Date header field, and for
     700         requirements regarding responses without it.
    701701      </t>
    702702   </list>
    … …  
    788788</t>
    789789<t>
    790    Stale responses &SHOULD; have a Warning header with the 110 warn-code (see
     790   Stale responses &SHOULD; have a Warning header field with the 110 warn-code (see
    791791   <xref target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be
    792792   sent on stale responses if the cache is disconnected.
    … …  
    797797   requesting client, and the received response is no longer fresh, the cache
    798798   &SHOULD; forward it to the requesting client without adding a new Warning
    799    (but without removing any existing Warning headers). A cache &SHOULD-NOT;
     799   (but without removing any existing Warning header fields). A cache &SHOULD-NOT;
    800800   attempt to validate a response simply because that response became stale in
    801801   transit.
    … …  
    816816<t>
    817817   When sending such a conditional request, the cache &SHOULD; add an
    818    If-Modified-Since header whose value is that of the Last-Modified header
    819    from the selected (see <xref target="caching.negotiated.responses"/>)
     818   If-Modified-Since header field whose value is that of the Last-Modified header
     819   field from the selected (see <xref target="caching.negotiated.responses"/>)
    820820   stored response, if available.
    821821</t>
    822822<t>
    823    Additionally, the cache &SHOULD; add an If-None-Match header whose value is
    824    that of the ETag header(s) from all responses stored for the requested URI,
     823   Additionally, the cache &SHOULD; add an If-None-Match header field whose value is
     824   that of the ETag header field(s) from all responses stored for the requested URI,
    825825   if present. However, if any of the stored responses contains only partial
    826826   content, its entity-tag &SHOULD-NOT; be included in the If-None-Match
    … …  
    830830<t>
    831831   A 304 (Not Modified) response status code indicates that the stored
    832    response can be updated and reused; see <xref target="combining.headers"/>.
     832   response can be updated and reused; see <xref target="combining.responses"/>.
    833833</t>
    834834<t>
    … …  
    856856   The following HTTP methods &MUST; cause a cache to invalidate the effective
    857857   Request URI (&effective-request-uri;) as well as the URI(s) in the Location
    858    and Content-Location headers (if present):
     858   and Content-Location header fields (if present):
    859859   <list style="symbols">
    860860      <t>PUT</t>
    … …  
    864864</t>
    865865<t>
    866    An invalidation based on a URI from a Location or Content-Location header
     866   An invalidation based on a URI from a Location or Content-Location header field
    867867   &MUST-NOT; be performed if the host part of that URI differs from the host
    868868   part in the effective request URI (&effective-request-uri;). This helps
    … …  
    891891<t>
    892892   Shared caches &MUST-NOT; use a cached response to a request with an
    893    Authorization header (&header-authorization;) to satisfy any subsequent
     893   Authorization header field (&header-authorization;) to satisfy any subsequent
    894894   request unless a cache directive that allows such responses to be stored is
    895895   present in the response.
    … …  
    917917   When a cache receives a request that can be satisfied by a stored response
    918918   that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT;
    919    use that response unless all of the selecting request-headers nominated by
    920    the Vary header match in both the original request (i.e., that associated
     919   use that response unless all of the selecting request-header fields nominated by
     920   the Vary header field match in both the original request (i.e., that associated
    921921   with the stored response), and the presented request.
    922922</t>
    923923<t>
    924    The selecting request-headers from two requests are defined to match if and
     924   The selecting request-header fields from two requests are defined to match if and
    925925   only if those in the first request can be transformed to those in the
    926926   second request by applying any of the following:
    927927   <list style="symbols">
    928928      <t>
    929          adding or removing whitespace, where allowed in the header's syntax
     929         adding or removing whitespace, where allowed in the header field's syntax
    930930      </t>
    931931      <t>
    … …  
    934934      </t>
    935935      <t>
    936          normalizing both header values in a way that is known to have
    937          identical semantics, according to the header's specification (e.g.,
     936         normalizing both header field values in a way that is known to have
     937         identical semantics, according to the header field's specification (e.g.,
    938938         re-ordering field values when order is not significant;
    939939         case-normalization, where values are defined to be case-insensitive)
    … …  
    952952</t>
    953953<t>
    954    The stored response with matching selecting request-headers is known as the
     954   The stored response with matching selecting request-header fields is known as the
    955955   selected response.
    956956</t>
    … …  
    962962</section>
    963963
    964 <section anchor="combining.headers" title="Combining Responses">
     964<section anchor="combining.responses" title="Combining Responses">
    965965<t>
    966966   When a cache receives a 304 (Not Modified) response or a 206 (Partial
    … …  
    984984</t>
    985985<t>
    986    The stored response headers are used as those of the updated response,
     986   The stored response header fields are used as those of the updated response,
    987987   except that
    988988   <list style="symbols">
    989       <t>any stored Warning headers with warn-code 1xx (see <xref
     989      <t>any stored Warning header fields with warn-code 1xx (see <xref
    990990      target="header.warning" />) &MUST; be deleted.</t>
    991       <t>any stored Warning headers with warn-code 2xx &MUST; be retained.</t>
    992       <t>any other headers provided in the new response &MUST; replace all
    993       instances of the corresponding headers from the stored response.</t>
    994    </list>
    995 </t>
    996 <t>
    997    The updated response headers &MUST; be used to replace those of the stored
     991      <t>any stored Warning header fields with warn-code 2xx &MUST; be retained.</t>
     992      <t>any other header fields provided in the new response &MUST; replace all
     993      instances of the corresponding header fields from the stored response.</t>
     994   </list>
     995</t>
     996<t>
     997   The updated response header fields &MUST; be used to replace those of the stored
    998998   response in cache (unless the stored response is removed from cache). In
    999999   the case of a 206 response, the combined representation &MAY; be stored.
    … …  
    10351035   If a cache receives a value larger than the largest positive integer it can
    10361036   represent, or if any of its age calculations overflows, it &MUST; transmit
    1037    an Age header with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches
     1037   an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches
    10381038   &SHOULD; use an arithmetic type of at least 31 bits of range.
    10391039</t>
    … …  
    11791179      <t>The no-transform request directive indicates that an intermediate
    11801180      cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or
    1181       Content-Type request headers, nor the request representation.</t>
     1181      Content-Type request header fields, nor the request representation.</t>
    11821182   </list>
    11831183</t>
    … …  
    12381238      <t>If the private response directive specifies one or more field-names,
    12391239      this requirement is limited to the field-values associated with the
    1240       listed response headers. That is, the specified field-names(s)
     1240      listed response header fields. That is, the specified field-names(s)
    12411241      &MUST-NOT; be stored by a shared cache, whereas the remainder of the
    12421242      response message &MAY; be.</t>
    … …  
    12611261      <t>If the no-cache response directive specifies one or more field-names,
    12621262      this requirement is limited to the field-values associated with the
    1263       listed response headers. That is, the specified field-name(s) &MUST-NOT;
     1263      listed response header fields. That is, the specified field-name(s) &MUST-NOT;
    12641264      be sent in the response to a subsequent request without successful
    12651265      validation on the origin server. This allows an origin server to prevent
    … …  
    13371337      <t>The s-maxage response directive indicates that, in shared caches, the
    13381338      maximum age specified by this directive overrides the maximum age
    1339       specified by either the max-age directive or the Expires header. The
     1339      specified by either the max-age directive or the Expires header field. The
    13401340      s-maxage directive also implies the semantics of the proxy-revalidate
    13411341      response directive.</t>
    … …  
    13491349      <t>The no-transform response directive indicates that an intermediate
    13501350      cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or
    1351       Content-Type response headers, nor the response representation.</t>
     1351      Content-Type response header fields, nor the response representation.</t>
    13521352   </list>
    13531353</t>
    … …  
    15401540<t>
    15411541   The set of header fields named by the Vary field value is known as the
    1542    selecting request-headers.
     1542   selecting request-header fields.
    15431543</t>
    15441544<t>
    … …  
    15541554<t>
    15551555   A Vary field value of "*" signals that unspecified parameters not limited
    1556    to the request-headers (e.g., the network address of the client), play a
     1556   to the request-header fields (e.g., the network address of the client), play a
    15571557   role in the selection of the response representation; therefore, a cache
    15581558   cannot determine whether this response is appropriate. The "*" value
    … …  
    15881588</t>
    15891589<t>
    1590    Warning headers can in general be applied to any message, however some
     1590   Warning header fields can in general be applied to any message, however some
    15911591   warn-codes are specific to caches and can only be applied to response
    15921592   messages.
    … …  
    16021602  <x:ref>warn-agent</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
    16031603                  ; the name or pseudonym of the server adding
    1604                   ; the Warning header, for use in debugging
     1604                  ; the Warning header field, for use in debugging
    16051605  <x:ref>warn-text</x:ref>  = <x:ref>quoted-string</x:ref>
    16061606  <x:ref>warn-date</x:ref>  = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref>
    … …  
    16161616</t>
    16171617<t>
    1618    Systems that generate multiple Warning headers &SHOULD; order them with
    1619    this user agent behavior in mind. New Warning headers &SHOULD; be added
    1620    after any existing Warning headers.
     1618   Systems that generate multiple Warning header fields &SHOULD; order them with
     1619   this user agent behavior in mind. New Warning header fields &SHOULD; be added
     1620   after any existing Warning headers fields.
    16211621</t>
    16221622<t>
    … …  
    16361636</t>
    16371637<t>
    1638    If an implementation sends a message with one or more Warning headers to a
     1638   If an implementation sends a message with one or more Warning header fields to a
    16391639   receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include
    1640    in each warning-value a warn-date that matches the Date header in the
     1640   in each warning-value a warn-date that matches the Date header field in the
    16411641   message.
    16421642</t>
    … …  
    16471647   storing, forwarding, or using it. (preventing the consequences of naive
    16481648   caching of Warning header fields.) If all of the warning-values are deleted
    1649    for this reason, the Warning header &MUST; be deleted as well.
     1649   for this reason, the Warning header field &MUST; be deleted as well.
    16501650</t>
    16511651<t>
    … …  
    22742274</t>
    22752275<t>
    2276   Do not mention RFC 2047 encoding and multiple languages in Warning headers
     2276  Do not mention RFC 2047 encoding and multiple languages in Warning header fields
    22772277  anymore, as these aspects never were implemented.
    22782278  (<xref target="header.warning" />)
    … …  
    24172417<section anchor="changes.since.02" title="Since draft-ietf-httpbis-p6-cache-02">
    24182418<t>
    2419   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />):
     2419  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />):
    24202420  <list style="symbols">
    2421     <t>Reference RFC 3984, and update header registrations for headers defined in this
     2421    <t>Reference RFC 3984, and update header field registrations for header fields defined in this
    24222422      document.</t>
    24232423  </list>
    … …  
    24482448    <t>
    24492449      Rewrite ABNFs to spell out whitespace rules, factor out
    2450       header value format definitions.
     2450      header field value format definitions.
    24512451    </t>
    24522452  </list>
    … …  
    24962496    <t>
    24972497      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>:
    2498       Vary and non-existant headers
     2498      WVary and non-existant headers"
    24992499    </t>
    25002500  </list>

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

    r981 r994  
    393393      <meta name="dct.creator" content="Reschke, J. F.">
    394394      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    395       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     395      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    396396      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    397397      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    424424            </tr>
    425425            <tr>
    426                <td class="left">Expires: March 5, 2011</td>
     426               <td class="left">Expires: March 11, 2011</td>
    427427               <td class="right">HP</td>
    428428            </tr>
    … …  
    477477            <tr>
    478478               <td class="left"></td>
    479                <td class="right">September 1, 2010</td>
     479               <td class="right">September 7, 2010</td>
    480480            </tr>
    481481         </tbody>
    … …  
    503503         in progress”.
    504504      </p>
    505       <p>This Internet-Draft will expire on March 5, 2011.</p>
     505      <p>This Internet-Draft will expire on March 11, 2011.</p>
    506506      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    507507      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    643643      <p id="rfc.section.3.1.p.5"> </p>
    644644      <ol>
    645          <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate
    646             the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy <em class="bcp14">MUST</em> always revalidate it before re-using it.
    647          </li>
    648          <li>If the response includes the "must-revalidate" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But if the response is stale, all caches <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate
    649             the new request.
     645         <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-header fields from the new request to allow the origin server
     646            to authenticate the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy <em class="bcp14">MUST</em> always revalidate it before re-using it.
     647         </li>
     648         <li>If the response includes the "must-revalidate" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But if the response is stale, all caches <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-header fields from the new request to allow the origin server
     649            to authenticate the new request.
    650650         </li>
    651651         <li>If the response includes the "public" cache-control directive, it <em class="bcp14">MAY</em> be returned in reply to any subsequent request.
    … …  
    904904      </ul>
    905905      <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;<a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p7-auth-02</a></h2>
    906       <p id="rfc.section.B.4.p.1">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     906      <p id="rfc.section.B.4.p.1">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    907907      </p>
    908908      <ul>
    909          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     909         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
    910910      </ul>
    911911      <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p7-auth-03</a></h2>
    … …  
    916916         <li>Use "/" instead of "|" for alternatives.</li>
    917917         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    918          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     918         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    919919      </ul>
    920920      <h2 id="rfc.section.B.7"><a href="#rfc.section.B.7">B.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p7-auth-05</a></h2>

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

    r981 r994  
    375375         subsequent request. But (if the specified maximum age has
    376376         passed) a proxy cache &MUST; first revalidate it with the origin
    377          server, using the request-headers from the new request to allow
     377         server, using the request-header fields from the new request to allow
    378378         the origin server to authenticate the new request. (This is the
    379379         defined behavior for s-maxage.) If the response includes "s-maxage=0",
    … …  
    385385         subsequent request. But if the response is stale, all caches
    386386         &MUST; first revalidate it with the origin server, using the
    387          request-headers from the new request to allow the origin server
     387         request-header fields from the new request to allow the origin server
    388388         to authenticate the new request.</t>
    389389
    … …  
    904904<section title="Since draft-ietf-httpbis-p7-auth-02" anchor="changes.since.02">
    905905<t>
    906   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     906  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    907907  <list style="symbols">
    908908    <t>
    909       Reference RFC 3984, and update header registrations for headers defined
     909      Reference RFC 3984, and update header field registrations for header fields defined
    910910      in this document.
    911911    </t>
    … …  
    932932    <t>
    933933      Rewrite ABNFs to spell out whitespace rules, factor out
    934       header value format definitions.
     934      header field value format definitions.
    935935    </t>
    936936  </list>
Note: See TracChangeset for help on using the changeset viewer.