Changeset 994
- Timestamp:
- 07/09/10 11:46:12 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r992 r994 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 6">406 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: March 1 0, 2011</td>437 <td class="left">Expires: March 11, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">September 6, 2010</td>490 <td class="right">September 7, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on March 1 0, 2011.</p>518 <p>This Internet-Draft will expire on March 11, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 608 608 </li> 609 609 <li class="tocline1">7.1.3 <a href="#persistent.proxy">Proxy Servers</a><ul class="toc"> 610 <li class="tocline1">7.1.3.1 <a href="#end-to-end.and.hop-by-hop.header s">End-to-end and Hop-by-hop Headers</a></li>611 <li class="tocline1">7.1.3.2 <a href="#non-modifiable.header s">Non-modifiable Headers</a></li>610 <li class="tocline1">7.1.3.1 <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 <a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li> 612 612 </ul> 613 613 </li> … … 1188 1188 </p> 1189 1189 <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 Appendix1191 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. 1192 1192 </p> 1193 1193 </div> … … 1723 1723 </p> 1724 1724 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <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 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 weight1725 <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 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 1726 1726 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 1727 1727 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. … … 1768 1768 </p> 1769 1769 <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <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-token1771 "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". 1772 1772 </p> 1773 1773 <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 than1775 tha t request, it <em class="bcp14">SHOULD</em> send a Connection headerincluding 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 the1778 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. 1779 1779 </p> 1780 1780 <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 B.2</a> for more information on backward compatibility with HTTP/1.0 clients. … … 1796 1796 to. Each persistent connection applies to only one transport link. 1797 1797 </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> <a id="end-to-end.and.hop-by-hop.header s" 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 header s into two categories: </p>1802 <ul> 1803 <li>End-to-end header s, which are transmitted to the ultimate recipient of a request or response. End-to-end headers in responses1804 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 s, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded1807 by proxies.1808 </li> 1809 </ul> 1810 <p id="rfc.section.7.1.3.1.p.2">The following HTTP/1.1 header s 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> <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> 1811 1811 <ul> 1812 1812 <li>Connection</li> … … 1819 1819 <li>Upgrade</li> 1820 1820 </ul> 1821 <p id="rfc.section.7.1.3.1.p.3">All other header s 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 header s <em class="bcp14">MUST</em> be listed in a Connection header(<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 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> <a id="non-modifiable.header s" 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 header s. A transparent1826 proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that headerrequires 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 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> <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. 1827 1827 </p> 1828 1828 <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: … … 1839 1839 <li>Expires</li> 1840 1840 </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 headerin 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. 1842 1842 </p> 1843 1843 <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: … … 1851 1851 </p> 1852 1852 <div class="note" id="rfc.section.7.1.3.2.p.7"> 1853 <p> <b>Warning:</b> Unnecessary modification of end-to-end header s might cause authentication failures if stronger authentication mechanisms are1854 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. 1855 1855 </p> 1856 1856 </div> … … 1895 1895 <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> 1896 1896 <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 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 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. 1898 1898 </p> 1899 1899 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 1900 1900 <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 header s) before the client sends the request body. In some cases, it might either1902 be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking1903 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. 1904 1904 </p> 1905 1905 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> … … 1961 1961 <ol> 1962 1962 <li>Initiate a new connection to the server</li> 1963 <li>Transmit the request-header s</li>1963 <li>Transmit the request-header fields</li> 1964 1964 <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), 1965 1965 or to a constant value of 5 seconds if the round-trip time is not available. … … 2003 2003 and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections. 2004 2004 </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> 2006 2006 <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> 2007 2007 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> … … 2012 2012 header field might not be sent if there are no parameters associated with that connection option. 2013 2013 </p> 2014 <p id="rfc.section.9.1.p.5">Message header s 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. 2015 2015 </p> 2016 2016 <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 … … 2024 2024 <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. 2025 2025 </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 the2026 <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 2027 2027 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 B.2</a>. 2028 2028 </p> … … 2074 2074 then it is optional. A client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request. 2075 2075 </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 means2076 <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 2077 2077 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload 2078 2078 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic … … 2191 2191 </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. 2192 2192 </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> 2194 2194 <div id="rfc.iref.u.5"></div> 2195 2195 <div id="rfc.iref.h.14"></div> … … 2866 2866 <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. 2867 2867 </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. 2870 2870 </p> 2871 2871 <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 … … 2884 2884 <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. 2885 2885 </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. 2887 2887 </li> 2888 2888 </ul> … … 2919 2919 <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 2920 2920 <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a> <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 9.4</a>)is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 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 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 4.1.2</a>) are among the most important changes defined by this specification. 2922 2922 </p> 2923 2923 <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 … … 2931 2931 </p> 2932 2932 <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. 2938 2938 </li> 2939 2939 <li>Servers <em class="bcp14">MUST</em> accept absolute URIs. … … 2954 2954 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 9.1</a>. 2955 2955 </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>. 2957 2958 </p> 2958 2959 <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 3260 3261 <li>Get rid of prose rules that span multiple lines.</li> 3261 3262 <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> 3263 3264 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 3264 3265 <li>Rewrite prose rule "token" in terms of "tchar", rewrite prose rule "TEXT".</li> … … 3272 3273 </li> 3273 3274 </ul> 3274 <p id="rfc.section.D.4.p.2">Ongoing work on IANA Message Header Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):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 (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 3276 </p> 3277 <ul> 3278 <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li> 3278 3279 </ul> 3279 3280 <p id="rfc.section.D.4.p.3">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): … … 3319 3320 <li>Only reference RFC 5234's core rules.</li> 3320 3321 <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> 3322 3323 </ul> 3323 3324 <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a> <a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p1-messaging-05</a></h2> … … 3354 3355 <ul> 3355 3356 <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 (defined3357 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). 3358 3359 </li> 3359 3360 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r992 r994 1199 1199 <x:note> 1200 1200 <t> 1201 <x:h>Note:</x:h> The "Set-Cookie" header as implemented in1201 <x:h>Note:</x:h> The "Set-Cookie" header field as implemented in 1202 1202 practice (as opposed to how it is specified in <xref target="RFC2109"/>) 1203 1203 can occur multiple times, but does not use the list syntax, and thus cannot 1204 1204 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 in1205 for details.) Also note that the Set-Cookie2 header field specified in 1206 1206 <xref target="RFC2965"/> does not share this problem. 1207 1207 </t> … … 2263 2263 <x:anchor-alias value="qvalue"/> 2264 2264 <t> 2265 Both transfer codings (TE request header , <xref target="header.te"/>)2265 Both transfer codings (TE request header field, <xref target="header.te"/>) 2266 2266 and content negotiation (&content.negotiation;) use short "floating point" 2267 2267 numbers to indicate the relative importance ("weight") of various … … 2362 2362 <t> 2363 2363 An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to 2364 maintain a persistent connection unless a Connection header including2364 maintain a persistent connection unless a Connection header field including 2365 2365 the connection-token "close" was sent in the request. If the server 2366 2366 chooses to close the connection immediately after sending the 2367 response, it &SHOULD; send a Connection header including the2367 response, it &SHOULD; send a Connection header field including the 2368 2368 connection-token "close". 2369 2369 </t> … … 2371 2371 An HTTP/1.1 client &MAY; expect a connection to remain open, but would 2372 2372 decide to keep it open based on whether the response from a server 2373 contains a Connection header with the connection-token close. In case2373 contains a Connection header field with the connection-token close. In case 2374 2374 the client does not want to maintain a connection for more than that 2375 request, it &SHOULD; send a Connection header including the2375 request, it &SHOULD; send a Connection header field including the 2376 2376 connection-token close. 2377 2377 </t> 2378 2378 <t> 2379 2379 If either the client or the server sends the close token in the 2380 Connection header , that request becomes the last one for the2380 Connection header field, that request becomes the last one for the 2381 2381 connection. 2382 2382 </t> … … 2435 2435 A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection 2436 2436 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 2438 2438 implemented by many HTTP/1.0 clients). 2439 2439 </t> 2440 2440 2441 <section title="End-to-end and Hop-by-hop Header s" 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"> 2442 2442 <!--<t> 2443 2443 <cref anchor="TODO-end-to-end" source="jre"> … … 2448 2448 <t> 2449 2449 For the purpose of defining the behavior of caches and non-caching 2450 proxies, we divide HTTP header s into two categories:2450 proxies, we divide HTTP header fields into two categories: 2451 2451 <list style="symbols"> 2452 <t>End-to-end header s, which are transmitted to the ultimate2453 recipient of a request or response. End-to-end header s in2452 <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 2454 2454 responses MUST be stored as part of a cache entry and &MUST; be 2455 2455 transmitted in any response formed from a cache entry.</t> 2456 2456 2457 <t>Hop-by-hop header s, which are meaningful only for a single2457 <t>Hop-by-hop header fields, which are meaningful only for a single 2458 2458 transport-level connection, and are not stored by caches or 2459 2459 forwarded by proxies.</t> … … 2461 2461 </t> 2462 2462 <t> 2463 The following HTTP/1.1 header s are hop-by-hop headers:2463 The following HTTP/1.1 header fields are hop-by-hop header fields: 2464 2464 <list style="symbols"> 2465 2465 <t>Connection</t> … … 2474 2474 </t> 2475 2475 <t> 2476 All other header s defined by HTTP/1.1 are end-to-end headers.2477 </t> 2478 <t> 2479 Other hop-by-hop header s &MUST; be listed in a Connection header2476 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 2480 2480 (<xref target="header.connection"/>). 2481 2481 </t> 2482 2482 </section> 2483 2483 2484 <section title="Non-modifiable Header s" anchor="non-modifiable.headers">2484 <section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields"> 2485 2485 <!--<t> 2486 2486 <cref anchor="TODO-non-mod-headers" source="jre"> … … 2491 2491 <t> 2492 2492 Some features of HTTP/1.1, such as Digest Authentication, depend on the 2493 value of certain end-to-end header s. A transparent proxy &SHOULD-NOT;2494 modify an end-to-end header unless the definition of that headerrequires2493 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 2495 2495 or specifically allows that. 2496 2496 </t> … … 2515 2515 <t> 2516 2516 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 to2518 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. 2519 2519 </t> 2520 2520 <t> … … 2536 2536 <x:note> 2537 2537 <t> 2538 <x:h>Warning:</x:h> Unnecessary modification of end-to-end header s might2538 <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might 2539 2539 cause authentication failures if stronger authentication 2540 2540 mechanisms are introduced in later versions of HTTP. Such … … 2640 2640 using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and 2641 2641 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; 2643 2643 close the connection. 2644 2644 </t> … … 2650 2650 allow a client that is sending a request message with a request body 2651 2651 to determine if the origin server is willing to accept the request 2652 (based on the request header s) before the client sends the request2652 (based on the request header fields) before the client sends the request 2653 2653 body. In some cases, it might either be inappropriate or highly 2654 2654 inefficient for the client to send the body if the server will reject … … 2771 2771 </t> 2772 2772 <t> 2773 Transmit the request-header s2773 Transmit the request-header fields 2774 2774 </t> 2775 2775 <t> … … 2864 2864 </t> 2865 2865 <t> 2866 The Connection header 's value has the following grammar:2866 The Connection header field's value has the following grammar: 2867 2867 </t> 2868 2868 <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"/> … … 2882 2882 </t> 2883 2883 <t> 2884 Message header s listed in the Connection header&MUST-NOT; include2885 end-to-end header s, 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. 2886 2886 </t> 2887 2887 <t> … … 2909 2909 <t> 2910 2910 A system receiving an HTTP/1.0 (or lower-version) message that 2911 includes a Connection header &MUST;, for each connection-token in this2911 includes a Connection header field &MUST;, for each connection-token in this 2912 2912 field, remove and ignore any header field(s) from the message with 2913 2913 the same name as the connection-token. This protects against mistaken … … 3015 3015 </t> 3016 3016 <t> 3017 The HTTP-date sent in a Date header &SHOULD-NOT; represent a date and3017 The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and 3018 3018 time subsequent to the generation of the message. It &SHOULD; represent 3019 3019 the best available approximation of the date and time of message … … 3239 3239 <t> 3240 3240 Many older HTTP/1.0 applications do not understand the Transfer-Encoding 3241 header .3241 header field. 3242 3242 </t> 3243 3243 </section> … … 4686 4686 <t> 4687 4687 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, 4689 4689 recognize a single LF as a line terminator and ignore the leading CR. 4690 4690 </t> … … 4718 4718 of an age or expiration time.</t> 4719 4719 4720 <t>If an HTTP header incorrectly carries a date value with a time4720 <t>If an HTTP header field incorrectly carries a date value with a time 4721 4721 zone other than GMT, it &MUST; be converted into GMT using the 4722 4722 most conservative possible conversion.</t> … … 4784 4784 <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"> 4785 4785 <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"/>)is4786 The requirements that clients and servers support the Host request-header 4787 field (<xref target="header.host"/>), report an error if it is 4788 4788 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) 4789 4789 are among the most important changes defined by this … … 4807 4807 requirements: 4808 4808 <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> 4812 4812 4813 4813 <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> 4815 4815 4816 4816 <t>Servers &MUST; accept absolute URIs.</t> … … 4847 4847 <t> 4848 4848 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"/>. 4850 4850 </t> 4851 4851 </section> … … 5273 5273 <t> 5274 5274 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. 5276 5276 </t> 5277 5277 <t> … … 5300 5300 </t> 5301 5301 <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"/>): 5303 5303 <list style="symbols"> 5304 5304 <t> 5305 Reference RFC 3984, and update header registrations for headers defined5305 Reference RFC 3984, and update header field registrations for headers defined 5306 5306 in this document. 5307 5307 </t> … … 5393 5393 <t> 5394 5394 Rewrite ABNFs to spell out whitespace rules, factor out 5395 header value format definitions.5395 header field value format definitions. 5396 5396 </t> 5397 5397 </list> … … 5464 5464 <t> 5465 5465 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). 5467 5467 </t> 5468 5468 </list> -
draft-ietf-httpbis/latest/p2-semantics.html
r981 r994 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 1">405 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <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 "HTTP/1.1" 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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: March 5, 2011</td>436 <td class="left">Expires: March 11, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">September 1, 2010</td>489 <td class="right">September 7, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </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> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 917 917 </li> 918 918 <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 payload919 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 922 922 is a representation of the target resource. 923 923 </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 response924 <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 925 925 asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion 926 926 cannot be trusted unless it can be verified by other means (not defined by HTTP). … … 1005 1005 <div id="rfc.iref.h.1"></div> 1006 1006 <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 header s 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 the1007 <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 1008 1008 representation implied by the request without transferring the representation body. This method is often used for testing 1009 1009 hypertext links for validity, accessibility, and recent modification. … … 1033 1033 </p> 1034 1034 <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 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 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. 1038 1038 </p> 1039 1039 <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 … … 1051 1051 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1052 1052 </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. 1054 1055 </p> 1055 1056 <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. … … 1106 1107 <p id="rfc.section.8.p.1">Each Status-Code is described below, including any metadata required in the response.</p> 1107 1108 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <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 header s, and is1109 terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any1110 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. 1111 1112 </p> 1112 1113 <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 … … 1361 1362 <div id="rfc.iref.s.24"></div> 1362 1363 <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a> <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. 1364 1365 </p> 1365 1366 <div id="rfc.iref.48"></div> … … 1367 1368 <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1368 1369 <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 header s sent in the request.1370 not acceptable according to the accept header fields sent in the request. 1370 1371 </p> 1371 1372 <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 … … 1374 1375 </p> 1375 1376 <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 header s 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 headers1378 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. 1379 1380 </p> 1380 1381 </div> … … 1490 1491 <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> 1491 1492 <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. 1493 1494 </p> 1494 1495 <div class="note" id="rfc.section.8.5.4.p.2"> … … 1551 1552 </p> 1552 1553 <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> 1556 1557 <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. 1557 1558 </p> … … 1568 1569 <div id="rfc.figure.u.16"></div><pre class="text"> From: webmaster@example.org 1569 1570 </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 receiving1571 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 1571 1572 end. 1572 1573 </p> … … 1596 1597 </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> 1597 1598 <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> 1599 1600 <li>With 305 Use Proxy.</li> 1600 1601 </ul> … … 1629 1630 URI was obtained (the "referrer", although the header field is misspelled.). 1630 1631 </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 controlling1632 <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 1633 1634 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 1634 1635 </p> … … 1673 1674 </pre><p id="rfc.section.9.8.p.4">Example:</p> 1674 1675 <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>). 1676 1677 </p> 1677 1678 <div class="note" id="rfc.section.9.8.p.7"> … … 2098 2099 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. 2099 2100 </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. 2103 2105 </p> 2104 2106 <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 … … 2112 2114 has no better mechanism. 2113 2115 </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 7.8</a>), expose information that was sent in request header s 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 collect2115 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 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. 2116 2118 </p> 2117 2119 <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> … … 2128 2130 </p> 2129 2131 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <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 header s in responses that are generated under control of said organizations2132 <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 2131 2133 to make sure that they do not attempt to invalidate resources over which they have no authority. 2132 2134 </p> … … 2252 2254 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 8.3.6</a>) 2253 2255 </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 requirement2255 on the contents of the Allow header and remove requirement on clients to always trust the headervalue. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 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 symbol2258 "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 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. 2259 2261 (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.4</a>) 2260 2262 </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 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 correctly2264 in the description of the Via headerin <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 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 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 9.8</a>) 2265 2267 </p> 2266 2268 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2422 2424 </p> 2423 2425 <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> 2425 2427 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 2426 2428 <li>Copy definition of delta-seconds from Part6 instead of referencing it.</li> … … 2444 2446 </li> 2445 2447 </ul> 2446 <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):2448 <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 2447 2449 </p> 2448 2450 <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> 2450 2452 </ul> 2451 2453 <p id="rfc.section.C.4.p.3">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): … … 2482 2484 <li>Use "/" instead of "|" for alternatives.</li> 2483 2485 <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> 2485 2487 </ul> 2486 2488 <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a> <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 22 22 <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 23 <!ENTITY auth "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 <!ENTITY c aching-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'/>"> 25 25 <!ENTITY content-negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 26 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 78 78 <!ENTITY p6-explicit "<xref target='Part6' x:rel='#calculating.freshness.lifetime' 79 79 xmlns: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'/>">82 80 ]> 83 81 <?rfc toc="yes" ?> … … 692 690 <t>If the response status code is 204, 206, or 304 and the request method was GET 693 691 or HEAD, the response payload is a partial representation of the target 694 (see &c aching-combining-headers;).</t>695 <t>If the response has a Content-Location header , and that URI is the same692 (see &combining-responses;).</t> 693 <t>If the response has a Content-Location header field, and that URI is the same 696 694 as the effective request URI, the response payload is a representation of the 697 695 target resource.</t> 698 <t>If the response has a Content-Location header , and that URI is not the696 <t>If the response has a Content-Location header field, and that URI is not the 699 697 same as the effective request URI, then the response asserts that its 700 698 payload is a representation of the resource identified by the … … 874 872 The HEAD method is identical to GET except that the server &MUST-NOT; 875 873 return a message-body in the response. The metadata contained 876 in the HTTP header s in response to a HEAD request &SHOULD; be identical874 in the HTTP header fields in response to a HEAD request &SHOULD; be identical 877 875 to the information sent in response to a GET request. This method can 878 876 be used for obtaining metadata about the representation implied by the … … 932 930 &SHOULD; be 201 (Created) and contain a representation which describes the 933 931 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"/>). 935 933 </t> 936 934 <t> 937 935 Responses to POST requests are only cacheable when they 938 936 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 940 938 (see &header-content-location;) whose value is the effective 941 939 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests. … … 971 969 error response &SHOULD; be given that reflects the nature of the problem. 972 970 The recipient of the representation &MUST-NOT; ignore any Content-* 973 header s (headers starting with the prefix "Content-") that it does971 header fields (headers starting with the prefix "Content-") that it does 974 972 not understand or implement 975 973 and &MUST; return a 501 (Not Implemented) response in such cases. … … 1095 1093 <t> 1096 1094 This class of status code indicates a provisional response, 1097 consisting only of the Status-Line and optional header s, and is1098 terminated by an empty line. There are no required header s for this1095 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 1099 1097 class of status code. Since HTTP/1.0 did not define any 1xx status 1100 1098 codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client … … 1619 1617 The method specified in the Request-Line is not allowed for the target 1620 1618 resource. The response &MUST; include an 1621 Allow header containing a list of valid methods for the requested1619 Allow header field containing a list of valid methods for the requested 1622 1620 resource. 1623 1621 </t> … … 1630 1628 The resource identified by the request is only capable of generating 1631 1629 response representations which have content characteristics not acceptable 1632 according to the accept header s sent in the request.1630 according to the accept header fields sent in the request. 1633 1631 </t> 1634 1632 <t> … … 1645 1643 <t> 1646 1644 <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are 1647 not acceptable according to the accept header s sent in the1645 not acceptable according to the accept header fields sent in the 1648 1646 request. In some cases, this might even be preferable to sending a 1649 406 response. User agents are encouraged to inspect the header s of1647 406 response. User agents are encouraged to inspect the header fields of 1650 1648 an incoming response to determine if it is acceptable. 1651 1649 </t> … … 1872 1870 is that this is a temporary condition which will be alleviated after 1873 1871 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; 1875 1873 handle the response as it would for a 500 response. 1876 1874 </t> … … 2001 1999 return a 417 (Expectation Failed) status code if it receives a request 2002 2000 with an expectation that it cannot meet. However, the Expect 2003 request-header itself is end-to-end; it &MUST; be forwarded if the2001 request-header field itself is end-to-end; it &MUST; be forwarded if the 2004 2002 request is forwarded. 2005 2003 </t> 2006 2004 <t> 2007 2005 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 2008 Expect header .2006 Expect header field. 2009 2007 </t> 2010 2008 <t> … … 2043 2041 of this field is that the request is being performed on behalf of the 2044 2042 person given, who accepts responsibility for the method performed. In 2045 particular, robot agents &SHOULD; include this header so that the2043 particular, robot agents &SHOULD; include this header field so that the 2046 2044 person responsible for running the robot can be contacted if problems 2047 2045 occur on the receiving end. … … 2099 2097 <list style="symbols"> 2100 2098 <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> 2102 2100 <t>With 305 Use Proxy.</t> 2103 2101 </list> … … 2169 2167 </t> 2170 2168 <t> 2171 The Referer header allows servers to generate lists of back-links to2169 The Referer header field allows servers to generate lists of back-links to 2172 2170 resources for interest, logging, optimized caching, etc. It also allows 2173 2171 obsolete or mistyped links to be traced for maintenance. Some servers use … … 2267 2265 <t> 2268 2266 If the response is being forwarded through a proxy, the proxy 2269 application &MUST-NOT; modify the Server response-header . Instead, it2267 application &MUST-NOT; modify the Server response-header field. Instead, it 2270 2268 &MUST; include a Via field (as described in &header-via;). 2271 2269 </t> … … 2686 2684 </t> 2687 2685 <t> 2688 The Referer header allows reading patterns to be studied and reverse2686 The Referer header field allows reading patterns to be studied and reverse 2689 2687 links drawn. Although it can be very useful, its power can be abused 2690 2688 if user details are not separated from the information contained in 2691 2689 the Referer. Even when the personal information has been removed, the 2692 Referer header might indicate a private document's URI whose2690 Referer header field might indicate a private document's URI whose 2693 2691 publication would be inappropriate. 2694 2692 </t> … … 2715 2713 <t> 2716 2714 Some methods, like TRACE (<xref target="TRACE"/>), expose information 2717 that was sent in request header s within the body of their response.2715 that was sent in request header fields within the body of their response. 2718 2716 Clients &SHOULD; be careful with sensitive information, like Cookies, 2719 Authorization credentials and other header s that might be used to2717 Authorization credentials and other header fields that might be used to 2720 2718 collect data from the client. 2721 2719 </t> … … 2750 2748 If a single server supports multiple organizations that do not trust 2751 2749 one another, then it &MUST; check the values of Location and Content-Location 2752 header s in responses that are generated under control of2750 header fields in responses that are generated under control of 2753 2751 said organizations to make sure that they do not attempt to 2754 2752 invalidate resources over which they have no authority. … … 3284 3282 </t> 3285 3283 <t> 3286 Reclassify Allow header as response header, removing the option to3284 Reclassify "Allow" as response header field, removing the option to 3287 3285 specify it in a PUT request. 3288 Relax the server requirement on the contents of the Allow header and3289 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. 3290 3288 (<xref target="header.allow"/>) 3291 3289 </t> 3292 3290 <t> 3293 Correct syntax of Location header to allow URI references (including3291 Correct syntax of Location header field to allow URI references (including 3294 3292 relative references and fragments), as referred symbol "absoluteURI" wasn't 3295 3293 what was expected, and add some clarifications as to when use of fragments … … 3298 3296 </t> 3299 3297 <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. 3301 3299 (<xref target="header.referer"/>) 3302 3300 </t> 3303 3301 <t> 3304 In the description of the Server header , the Via field3302 In the description of the Server header field, the Via field 3305 3303 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;. 3307 3305 (<xref target="header.server"/>) 3308 3306 </t> … … 3511 3509 <t> 3512 3510 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. 3514 3512 </t> 3515 3513 <t> … … 3558 3556 </t> 3559 3557 <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"/>): 3561 3559 <list style="symbols"> 3562 3560 <t> 3563 Reference RFC 3984, and update header registrations for headers defined3561 Reference RFC 3984, and update header field registrations for headers defined 3564 3562 in this document. 3565 3563 </t> … … 3631 3629 <t> 3632 3630 Rewrite ABNFs to spell out whitespace rules, factor out 3633 header value format definitions.3631 header field value format definitions. 3634 3632 </t> 3635 3633 </list> -
draft-ietf-httpbis/latest/p3-payload.html
r987 r994 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 3">404 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: March 7, 2011</td>430 <td class="left">Expires: March 11, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 485 485 <tr> 486 486 <td class="left"></td> 487 <td class="right">September 3, 2010</td>487 <td class="right">September 7, 2010</td> 488 488 </tr> 489 489 </tbody> … … 511 511 in progress”. 512 512 </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> 514 514 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 515 515 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 589 589 </li> 590 590 <li class="tocline0">8. <a href="#security.considerations">Security Considerations</a><ul class="toc"> 591 <li class="tocline1">8.1 <a href="#privacy.issues.connected.to.accept.header s">Privacy Issues Connected to Accept Headers</a></li>591 <li class="tocline1">8.1 <a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li> 592 592 </ul> 593 593 </li> … … 706 706 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. 707 707 </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 value710 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. 711 711 </p> 712 712 <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>. 713 713 </p> 714 714 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <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 should716 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. 717 717 </p> 718 718 <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 … … 751 751 <ul class="empty"> 752 752 <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. 754 754 </li> 755 755 </ul> … … 996 996 <div id="rfc.iref.h.1"></div> 997 997 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <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 header s999 can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request1000 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. 1001 1001 </p> 1002 1002 <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> … … 1115 1115 mentioned. 1116 1116 </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. 1119 1120 </p> 1120 1121 <div id="rfc.iref.a.3"></div> … … 1151 1152 </ol> 1152 1153 <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. 1154 1155 </p> 1155 1156 <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, … … 1193 1194 </p> 1194 1195 </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 linguistic1196 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header s" title="Privacy Issues Connected to Accept Headers">Section 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 8.1</a>. 1197 1198 </p> 1198 1199 <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 … … 1319 1320 but this does not change how the digest is computed as defined in the preceding paragraph. 1320 1321 </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 header s (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding1322 headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the1323 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. 1325 1326 </p> 1326 1327 <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. … … 1487 1488 make some suggestions for reducing security risks. 1488 1489 </p> 1489 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="privacy.issues.connected.to.accept.header s" 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 header1491 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular1492 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option1493 t o configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration1494 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 header s 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 any1498 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> <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. 1499 1500 </p> 1500 1501 <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 … … 1504 1505 also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to 1505 1506 be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could 1506 filter the accept header s 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. 1507 1508 </p> 1508 1509 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> … … 1757 1758 experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification. 1758 1759 </p> 1759 <p id="rfc.section.B.p.2">A number of other header s, 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>). 1760 1761 </p> 1761 1762 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> … … 1763 1764 </p> 1764 1765 <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 header s, and also the potentially undesirable effect of potentially breaking relative1766 links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 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 6.7</a>) 1767 1768 </p> 1768 1769 <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 A.5</a>) … … 1901 1902 </li> 1902 1903 </ul> 1903 <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):1904 <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 1904 1905 </p> 1905 1906 <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> 1907 1908 </ul> 1908 1909 <h2 id="rfc.section.E.5"><a href="#rfc.section.E.5">E.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h2> … … 1932 1933 <li>Use "/" instead of "|" for alternatives.</li> 1933 1934 <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> 1935 1936 </ul> 1936 1937 <h2 id="rfc.section.E.7"><a href="#rfc.section.E.7">E.7</a> <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 398 398 <t> 399 399 HTTP uses charset in two contexts: within an Accept-Charset request 400 header (in which the charset value is an unquoted token) and as the401 value of a parameter in a Content-Type header (within a request or400 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 402 402 response), in which case the parameter value of the charset parameter 403 403 can be quoted. … … 410 410 <section title="Missing Charset" anchor="missing.charset"> 411 411 <t> 412 Some HTTP/1.0 software has interpreted a Content-Type header without412 Some HTTP/1.0 software has interpreted a Content-Type header field without 413 413 charset parameter incorrectly to mean "recipient should guess". 414 414 Senders wishing to defeat this behavior &MAY; include a charset … … 478 478 The default (identity) encoding; the use of no transformation 479 479 whatsoever. This content-coding is used only in the Accept-Encoding 480 header , and &SHOULD-NOT; be used in the Content-Encoding481 header .480 header field, and &SHOULD-NOT; be used in the Content-Encoding 481 header field. 482 482 </t></list> 483 483 </t> … … 979 979 <t> 980 980 The "Accept" request-header field can be used by user agents to specify 981 response media types that are acceptable. Accept header s can be used to981 response media types that are acceptable. Accept header fields can be used to 982 982 indicate that the request is specifically limited to a small set of desired 983 983 types, as in the case of a request for an in-line image. … … 1133 1133 </t> 1134 1134 <t> 1135 If no Accept-Charset header is present, the default is that any1136 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, 1137 1137 and if the server cannot send a response which is acceptable 1138 according to the Accept-Charset header , then the server &SHOULD; send1138 according to the Accept-Charset header field, then the server &SHOULD; send 1139 1139 an error response with the 406 (Not Acceptable) status code, though 1140 1140 the sending of an unacceptable response is also allowed. … … 1201 1201 If an Accept-Encoding field is present in a request, and if the 1202 1202 server cannot send a response which is acceptable according to the 1203 Accept-Encoding header , then the server &SHOULD; send an error response1203 Accept-Encoding header field, then the server &SHOULD; send an error response 1204 1204 with the 406 (Not Acceptable) status code. 1205 1205 </t> … … 1279 1279 <t> 1280 1280 It might be contrary to the privacy expectations of the user to send 1281 an Accept-Language header with the complete linguistic preferences of1281 an Accept-Language header field with the complete linguistic preferences of 1282 1282 the user in every request. For a discussion of this issue, see 1283 <xref target="privacy.issues.connected.to.accept.header s"/>.1283 <xref target="privacy.issues.connected.to.accept.header.fields"/>. 1284 1284 </t> 1285 1285 <t> … … 1541 1541 There are several consequences of this. The payload for composite 1542 1542 types &MAY; contain many body-parts, each with its own MIME and HTTP 1543 header s (including Content-MD5, Content-Transfer-Encoding, and1544 Content-Encoding header s). If a body-part has a Content-Transfer-Encoding1545 or Content-Encoding header , it is assumed that the content1543 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 1546 1546 of the body-part has had the encoding applied, and the body-part is 1547 1547 included in the Content-MD5 digest as is -- i.e., after the … … 1730 1730 </t> 1731 1731 1732 <section title="Privacy Issues Connected to Accept Header s" anchor="privacy.issues.connected.to.accept.headers">1733 <t> 1734 Accept request-headers can reveal information about the user to all1735 servers which are accessed. The Accept-Language header in particular1732 <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 1736 1736 can reveal information the user would consider to be of a private 1737 1737 nature, because the understanding of particular languages is often 1738 1738 strongly correlated to the membership of a particular ethnic group. 1739 1739 User agents which offer the option to configure the contents of an 1740 Accept-Language header to be sent in every request are strongly1740 Accept-Language header field to be sent in every request are strongly 1741 1741 encouraged to let the configuration process include a message which 1742 1742 makes the user aware of the loss of privacy involved. … … 1744 1744 <t> 1745 1745 An approach that limits the loss of privacy would be for a user agent 1746 to omit the sending of Accept-Language header s by default, and to ask1747 the user whether or not to start sending Accept-Language header s to a1746 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 1748 1748 server if it detects, by looking for any Vary response-header fields 1749 1749 generated by the server, that such sending could improve the quality … … 1762 1762 privacy, user agents ought to be conservative in offering accept 1763 1763 header configuration options to end users. As an extreme privacy 1764 measure, proxies could filter the accept header s in relayed requests.1764 measure, proxies could filter the accept header fields in relayed requests. 1765 1765 General purpose user agents which provide a high degree of header 1766 1766 configurability &SHOULD; warn users about the loss of privacy which can … … 2647 2647 </t> 2648 2648 <t> 2649 A number of other header s, such as Content-Disposition and Title,2649 A number of other header fields, such as Content-Disposition and Title, 2650 2650 from SMTP and MIME are also often implemented (see <xref target="RFC2076"/>). 2651 2651 </t> … … 2660 2660 Remove base URI setting semantics for Content-Location due to poor 2661 2661 implementation support, which was caused by too many broken servers emitting 2662 bogus Content-Location header s, and also the potentially undesirable effect2662 bogus Content-Location header fields, and also the potentially undesirable effect 2663 2663 of potentially breaking relative links in content-negotiated resources. 2664 2664 (<xref target="header.content-location"/>) … … 2855 2855 </t> 2856 2856 <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"/>): 2858 2858 <list style="symbols"> 2859 2859 <t> 2860 Reference RFC 3984, and update header registrations for headers defined2860 Reference RFC 3984, and update header field registrations for headers defined 2861 2861 in this document. 2862 2862 </t> … … 2917 2917 <t> 2918 2918 Rewrite ABNFs to spell out whitespace rules, factor out 2919 header value format definitions.2919 header field value format definitions. 2920 2920 </t> 2921 2921 </list> -
draft-ietf-httpbis/latest/p4-conditional.html
r981 r994 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <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 "HTTP/1.1" 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."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: March 5, 2011</td>428 <td class="left">Expires: March 11, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">September 1, 2010</td>485 <td class="right">September 7, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </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> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 598 598 <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 599 599 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 definition600 resource metadata will be discussed first and then followed by each conditional request-header field, concluding with a definition 601 601 of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more 602 602 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 … … 802 802 <p id="rfc.section.4.p.11">or </p> 803 803 <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 has805 a cache entry for the associated representation, and804 <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 806 806 </li> 807 807 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> … … 841 841 </li> 842 842 <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. 844 844 </li> 845 845 </ul> … … 912 912 <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 913 913 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 header s (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) 915 915 are never used for purposes of validating a cache entry. 916 916 </p> … … 929 929 <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 930 930 </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 that932 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. 933 933 </p> 934 934 <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, … … 936 936 </p> 937 937 <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. 939 939 </p> 940 940 <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. … … 962 962 </pre><p id="rfc.section.6.3.p.3">An example of the field is:</p> 963 963 <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 if965 it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes the966 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: 967 967 </p> 968 968 <ol> … … 988 988 field whenever possible. 989 989 </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 for991 the same request, the client needs to be aware that this date is interpreted in the server's understanding of time. Unsynchronized992 clocks and rounding problems, due to the different encodings of time between the client and server, are concerns. This includes993 the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since994 date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived995 from the client's clock without correction to the server's clock. Corrections for different time bases between client and996 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. 997 997 </li> 998 998 </ul> … … 1015 1015 <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 1016 1016 </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 exists1017 GET request (without the If-None-Match header field) on that resource, or if "*" is given and any current representation exists 1018 1018 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 1019 1019 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 … … 1023 1023 </p> 1024 1024 <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 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 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 1026 1026 </p> 1027 1027 <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. … … 1041 1041 <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 1042 1042 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. 1044 1044 </p> 1045 1045 <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). … … 1050 1050 </pre><p id="rfc.section.6.5.p.4">An example of the field is:</p> 1051 1051 <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 status1053 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> 1056 1056 <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 1057 1057 header fields is undefined by this specification. … … 1316 1316 </li> 1317 1317 </ul> 1318 <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):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 (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 1319 </p> 1320 <ul> 1321 <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li> 1322 1322 </ul> 1323 1323 <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p4-conditional-03</a></h2> … … 1337 1337 <li>Use "/" instead of "|" for alternatives.</li> 1338 1338 <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> 1340 1340 </ul> 1341 1341 <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a> <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 231 231 A future draft will reorganize the sections to better reflect the content. 232 232 In particular, the sections on resource metadata will be discussed first 233 and then followed by each conditional request-header , concluding with a233 and then followed by each conditional request-header field, concluding with a 234 234 definition of precedence and the expectation of ordering strong validator 235 235 checks before weak validator checks. It is likely that more content from … … 573 573 <list style="symbols"> 574 574 <t>The validator is about to be used by a client in an If-Modified-Since 575 or If-Unmodified-Since header , because the client575 or If-Unmodified-Since header field, because the client 576 576 has a cache entry for the associated representation, and</t> 577 577 <t>That cache entry includes a Date value, which gives the time … … 640 640 unless the risk of a breakdown in semantic transparency that 641 641 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> 643 643 </list> 644 644 </t> … … 764 764 appropriate cache validation mechanism, and the specification of any 765 765 validator comparison function more complex than byte-equality would 766 open up a can of worms. Thus, comparisons of any other header s766 open up a can of worms. Thus, comparisons of any other header fields 767 767 (except Last-Modified, for compatibility with HTTP/1.0) are never 768 768 used for purposes of validating a cache entry. … … 795 795 If any of the entity-tags match the entity-tag of the representation that 796 796 would have been returned in the response to a similar GET request 797 (without the If-Match header ) on that resource, or if "*" is given797 (without the If-Match header field) on that resource, or if "*" is given 798 798 and any current representation exists for that resource, then the server &MAY; 799 799 perform the requested method as if the If-Match header field did not … … 810 810 <t> 811 811 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 813 813 &MUST; be ignored. 814 814 </t> … … 864 864 </artwork></figure> 865 865 <t> 866 A GET method with an If-Modified-Since header and no Range header867 requests that the representation be transferred only if it has868 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. 869 869 The algorithm for determining this includes the following cases: 870 870 <list style="numbers"> … … 902 902 </t><t> 903 903 <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 headerfor904 header field instead of a date taken from the Last-Modified header field for 905 905 the same request, the client needs to be aware that this 906 906 date is interpreted in the server's understanding of time. … … 954 954 If any of the entity-tags match the entity-tag of the representation that 955 955 would have been returned in the response to a similar GET request 956 (without the If-None-Match header ) on that resource, or if "*" is956 (without the If-None-Match header field) on that resource, or if "*" is 957 957 given and any current representation exists for that resource, then the 958 958 server &MUST-NOT; perform the requested method, unless required to do … … 975 975 If the request would, without the If-None-Match header field, result 976 976 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 of977 header field &MUST; be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of 978 978 server behavior when both If-Modified-Since and If-None-Match appear 979 979 in the same request.) … … 1014 1014 in a 200 response to a GET request on the same resource has not been modified 1015 1015 since the time specified in this field, the server &SHOULD; perform the 1016 requested operation as if the If-Unmodified-Since header were not1016 requested operation as if the If-Unmodified-Since header field were not 1017 1017 present. 1018 1018 </t> … … 1035 1035 <t> 1036 1036 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. 1042 1042 </t> 1043 1043 <t> … … 1585 1585 </t> 1586 1586 <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"/>): 1588 1588 <list style="symbols"> 1589 1589 <t> 1590 Reference RFC 3984, and update header registrations for headers defined1590 Reference RFC 3984, and update header field registrations for header fields defined 1591 1591 in this document. 1592 1592 </t> … … 1628 1628 <t> 1629 1629 Rewrite ABNFs to spell out whitespace rules, factor out 1630 header value format definitions.1630 header field value format definitions. 1631 1631 </t> 1632 1632 </list> -
draft-ietf-httpbis/latest/p5-range.html
r981 r994 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: March 5, 2011</td>428 <td class="left">Expires: March 11, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">September 1, 2010</td>485 <td class="right">September 7, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </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> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 645 645 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 2.1</a>. 646 646 </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 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 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. 648 648 </p> 649 649 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="range.specifier.registry" href="#range.specifier.registry">Range Specifier Registry</a></h2> … … 679 679 <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. 680 680 </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 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 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 684 685 it <em class="bcp14">MUST NOT</em> be cached either. 685 686 </p> … … 721 722 </p> 722 723 <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 f or the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section 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 2</a>. 724 725 </p> 725 726 <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 … … 752 753 <a href="#header.content-range" class="smpl">other-range-resp-spec</a> 753 754 <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 asterisk755 </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 755 756 "*" character means that the instance-length is unknown at the time when the response was generated. 756 757 </p> … … 779 780 </ul> 780 781 <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 , and782 a Content-Length headershowing 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, 783 784 </p> 784 785 <div id="rfc.figure.u.13"></div><pre class="text"> HTTP/1.1 206 Partial Content … … 805 806 <div class="note" id="rfc.section.5.2.p.16"> 806 807 <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. 808 809 </p> 809 810 </div> … … 812 813 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.if-range" href="#header.if-range">If-Range</a></h2> 813 814 <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 and815 If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make816 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. 817 818 </p> 818 819 <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 … … 821 822 <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> 822 823 <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 827 829 not match, then the server <em class="bcp14">SHOULD</em> return the entire representation using a 200 (OK) response. 828 830 </p> … … 896 898 <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> 897 899 <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 large900 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 other905 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, or908 o ne or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition900 </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 909 911 is true. It does not affect the 304 (Not Modified) response returned if the conditional is false. 910 912 </li> 911 913 </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 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 5.3</a>) in addition to the Range header field. 913 915 </p> 914 916 <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 … … 1287 1289 </ul> 1288 1290 <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a> <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 (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):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 (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 1292 </p> 1293 <ul> 1294 <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li> 1293 1295 </ul> 1294 1296 <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p5-range-03</a></h2> … … 1304 1306 <li>Use "/" instead of "|" for alternatives.</li> 1305 1307 <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> 1307 1309 </ul> 1308 1310 <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a> <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 334 334 <t> 335 335 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"/>). 337 337 If a range unit is not understood in a response, an intermediary 338 338 &SHOULD; pass the response to the client; a client &MUST; fail. … … 403 403 <t> 404 404 A cache &MUST-NOT; combine a 206 response with other previously cached 405 content if the ETag or Last-Modified header s do not match exactly,405 content if the ETag or Last-Modified header fields do not match exactly, 406 406 see <xref target="combining.byte.ranges"/>. 407 407 </t> 408 408 <t> 409 A cache that does not support the Range and Content-Range header s409 A cache that does not support the Range and Content-Range header fields 410 410 &MUST-NOT; cache 206 (Partial Content) responses. Furthermore, 411 411 if a response uses a range unit that is not understood by the cache, … … 492 492 <t> 493 493 but are not required to do so. Clients &MAY; generate range 494 requests without having received this header f or the resource494 requests without having received this header field for the resource 495 495 involved. Range units are defined in <xref target="range.units"/>. 496 496 </t> … … 546 546 </artwork></figure> 547 547 <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, 549 549 unless this length is unknown or difficult to determine. The asterisk 550 550 "*" character means that the instance-length is unknown at the time … … 606 606 example, a response to a request for a single range, or to a request 607 607 for a set of ranges that overlap without any holes), this content is 608 transmitted with a Content-Range header , and a Content-Length header609 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, 610 610 </t> 611 611 <figure><artwork type="example"> … … 655 655 <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested 656 656 range not satisfiable) response instead of a 200 (OK) response for 657 an unsatisfiable Range request-header , since not all servers658 implement this request-header .657 an unsatisfiable Range request-header field, since not all servers 658 implement this request-header field. 659 659 </t> 660 660 </x:note> … … 669 669 If a client has a partial copy of a representation in its cache, and wishes 670 670 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 (using671 could use the Range request-header field with a conditional GET (using 672 672 either or both of If-Unmodified-Since and If-Match.) However, if the 673 673 condition fails because the representation has been modified, the client … … 687 687 <t> 688 688 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 . (The689 date, it &MAY; use that date in an If-Range header field. (The 690 690 server can distinguish between a valid HTTP-date and any form of 691 691 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; be693 ignored if the request does not include a Range header , or if the692 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 694 694 server does not support the sub-range operation. 695 695 </t> 696 696 <t> 697 If the entity-tag given in the If-Range header matches the current697 If the entity-tag given in the If-Range header field matches the current 698 698 cache validator for the representation, then the server &SHOULD; provide the 699 699 specified sub-range of the representation using a 206 (Partial Content) … … 840 840 </artwork></figure> 841 841 <t> 842 A server &MAY; ignore the Range header . However, HTTP/1.1 origin842 A server &MAY; ignore the Range header field. However, HTTP/1.1 origin 843 843 servers and intermediate caches ought to support byte ranges when 844 844 possible, since Range supports efficient recovery from partially … … 847 847 </t> 848 848 <t> 849 If the server supports the Range header and the specified range or849 If the server supports the Range header field and the specified range or 850 850 ranges are appropriate for the representation: 851 851 <list style="symbols"> 852 <t>The presence of a Range header in an unconditional GET modifies852 <t>The presence of a Range header field in an unconditional GET modifies 853 853 what is returned if the GET is otherwise successful. In other 854 854 words, the response carries a status code of 206 (Partial 855 855 Content) instead of 200 (OK).</t> 856 856 857 <t>The presence of a Range header in a conditional GET (a request857 <t>The presence of a Range header field in a conditional GET (a request 858 858 using one or both of If-Modified-Since and If-None-Match, or 859 859 one or both of If-Unmodified-Since and If-Match) modifies what … … 865 865 <t> 866 866 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. 868 869 </t> 869 870 <t> … … 1498 1499 <section title="Since draft-ietf-httpbis-p5-range-02" anchor="changes.since.02"> 1499 1500 <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"/>): 1501 1502 <list style="symbols"> 1502 1503 <t> 1503 Reference RFC 3984, and update header registrations for headers defined1504 Reference RFC 3984, and update header field registrations for headers defined 1504 1505 in this document. 1505 1506 </t> … … 1535 1536 <t> 1536 1537 Rewrite ABNFs to spell out whitespace rules, factor out 1537 header value format definitions.1538 header field value format definitions. 1538 1539 </t> 1539 1540 </list> -
draft-ietf-httpbis/latest/p6-cache.html
r981 r994 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 1">404 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <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 "HTTP/1.1" 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."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: March 5, 2011</td>430 <td class="left">Expires: March 11, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">September 1, 2010</td>491 <td class="right">September 7, 2010</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </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> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 563 563 <li class="tocline1">2.6 <a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li> 564 564 <li class="tocline1">2.7 <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 565 <li class="tocline1">2.8 <a href="#combining. headers">Combining Responses</a></li>565 <li class="tocline1">2.8 <a href="#combining.responses">Combining Responses</a></li> 566 566 </ul> 567 567 </li> … … 724 724 <li>The request method is understood by the cache and defined as being cacheable, and</li> 725 725 <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 3.2</a>) does not appear in request or response header s, and726 <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 3.2</a>) does not appear in request or response header fields, and 727 727 </li> 728 728 <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a> does not appear in the response, if the cache is shared, and 729 729 </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 2.6</a>), and730 <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 2.6</a>), and 731 731 </li> 732 732 <li>the response either: 733 733 <ul> 734 <li>contains an Expires header (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 3.3</a>), or734 <li>contains an Expires header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 3.3</a>), or 735 735 </li> 736 736 <li>contains a max-age response cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>), or … … 752 752 </p> 753 753 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <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 header s <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. 758 758 </p> 759 759 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2> … … 764 764 </li> 765 765 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> 766 <li>selecting request-header s nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>), and766 <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 2.7</a>), and 767 767 </li> 768 768 <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 3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 3.4</a>), and … … 786 786 <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 2.5</a>. 787 787 </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. 790 791 </p> 791 792 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="expiration.model" href="#expiration.model">Freshness Model</a></h2> … … 794 795 </p> 795 796 <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 3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation797 using either the Expires header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation 797 798 is not likely to change in a semantically significant way before the expiration time is reached. 798 799 </p> … … 801 802 requests. 802 803 </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 heade rvalues804 <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 804 805 (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific 805 806 algorithms, but does impose worst-case constraints on their results. … … 824 825 <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) is present, use its value, or 825 826 </li> 826 <li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 3.3</a>) is present, use its value minus the value of the Date response header, or827 <li>If the Expires response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 3.3</a>) is present, use its value minus the value of the Date response header field, or 827 828 </li> 828 829 <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a>. … … 834 835 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. 835 836 </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 is837 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%. 840 841 </p> 841 842 <div class="note" id="rfc.section.2.3.1.1.p.4"> … … 846 847 </div> 847 848 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <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. The849 Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin849 <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 850 851 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 851 852 path from the origin server, plus the amount of time it has been in transit along network paths. … … 855 856 </p> 856 857 <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 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 3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available. 858 859 </li> 859 860 </ul> … … 861 862 </p> 862 863 <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 response864 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. 866 867 </li> 867 868 </ul> … … 913 914 path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>). 914 915 </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 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 3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected. 916 917 </p> 917 918 <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. 919 921 </p> 920 922 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> … … 923 925 update it. This process is known as "validating" or "revalidating" the stored response. 924 926 </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 headerfrom the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 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, if928 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 stored927 <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 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 929 931 response. 930 932 </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 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 2.8</a>. 932 934 </p> 933 935 <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 … … 939 941 <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. 940 942 </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 header s (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): 942 944 </p> 943 945 <ul> … … 946 948 <li>POST</li> 947 949 </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. 949 951 </p> 950 952 <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>). … … 957 959 </p> 958 960 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <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. 960 962 </p> 961 963 <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 3.2.2</a>) have such an effect: must-revalidate, public, s-maxage. … … 966 968 </p> 967 969 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <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 3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-header s nominated by the Vary header match in both the original request969 (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-header s from two requests are defined to match if and only if those in the first request can be transformed972 t o 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 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> 976 978 <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>) 977 979 </li> 978 <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification980 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification 979 981 (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive) 980 982 </li> … … 986 988 by the origin server. 987 989 </p> 988 <p id="rfc.section.2.7.p.5">The stored response with matching selecting request-header s 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> 989 991 <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 2.4</a>. 990 992 </p> 991 <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <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> <a id="combining.responses" href="#combining.responses">Combining Responses</a></h2> 992 994 <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"), 993 995 it needs to created an updated response by combining the stored response with the new one, so that the updated response can … … 998 1000 <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. 999 1001 </p> 1000 <p id="rfc.section.2.8.p.4">The stored response header s are used as those of the updated response, except that </p>1001 <ul> 1002 <li>any stored Warning header s with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>) <em class="bcp14">MUST</em> be deleted.1003 </li> 1004 <li>any stored Warning header s with warn-code 2xx <em class="bcp14">MUST</em> be retained.1005 </li> 1006 <li>any other header s 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 header s <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 of1002 <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 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 1010 1012 a 206 response, the combined representation <em class="bcp14">MAY</em> be stored. 1011 1013 </p> … … 1025 1027 <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> 1026 1028 </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. 1028 1030 </p> 1029 1031 <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 … … 1107 1109 </p> 1108 1110 <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 header s, 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. 1110 1112 </li> 1111 1113 </ul> … … 1143 1145 </li> 1144 1146 <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 header s. 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. 1146 1148 </li> 1147 1149 <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 … … 1158 1160 </li> 1159 1161 <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 header s. 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 origin1162 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 1161 1163 server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. 1162 1164 </li> … … 1205 1207 <ul class="empty"> 1206 1208 <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 semantics1208 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. 1209 1211 </li> 1210 1212 </ul> … … 1212 1214 </p> 1213 1215 <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 header s, 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. 1215 1217 </li> 1216 1218 </ul> … … 1305 1307 <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> 1306 1308 <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-header s.</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> 1308 1310 <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 1309 1311 to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that … … 1311 1313 the user agent with useful information about the dimensions over which the response varies at the time of the response. 1312 1314 </p> 1313 <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-header s (e.g., the network address1314 of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this1315 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. 1316 1318 </p> 1317 1319 <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 … … 1328 1330 code, distinguishes these responses from true failures. 1329 1331 </p> 1330 <p id="rfc.section.3.6.p.3">Warning header s can in general be applied to any message, however some warn-codes are specific to caches and can only be applied1331 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. 1332 1334 </p> 1333 1335 <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> … … 1340 1342 <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> 1341 1343 ; the name or pseudonym of the server adding 1342 ; the Warning header , for use in debugging1344 ; the Warning header field, for use in debugging 1343 1345 <a href="#header.warning" class="smpl">warn-text</a> = <a href="#core.rules" class="smpl">quoted-string</a> 1344 1346 <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> … … 1348 1350 <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. 1349 1351 </p> 1350 <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning header s <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. 1351 1353 </p> 1352 1354 <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 … … 1360 1362 </li> 1361 1363 </ul> 1362 <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning header s to a receiver whose version is HTTP/1.0 or lower, then1363 the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date headerin 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. 1364 1366 </p> 1365 1367 <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 1366 1368 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. 1368 1370 </p> 1369 1371 <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 … … 1677 1679 <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a>) 1678 1680 </p> 1679 <p id="rfc.section.A.p.4">Do not mention RFC 2047 encoding and multiple languages in Warning header s 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. 1680 1682 (<a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 3.6</a>) 1681 1683 </p> … … 1796 1798 </ul> 1797 1799 <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a> <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 (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):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 (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 1801 </p> 1802 <ul> 1803 <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li> 1802 1804 </ul> 1803 1805 <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p6-cache-03</a></h2> … … 1813 1815 <li>Use "/" instead of "|" for alternatives.</li> 1814 1816 <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> 1816 1818 </ul> 1817 1819 <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a> <a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p6-cache-05</a></h2> … … 1841 1843 <p id="rfc.section.C.8.p.2">Affected issues: </p> 1842 1844 <ul> 1843 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>>: Vary and non-existant headers1845 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>>: WVary and non-existant headers" 1844 1846 </li> 1845 1847 </ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r981 r994 439 439 <t>the "no-store" cache directive (see <xref 440 440 target="header.cache-control" />) does not appear in request or response 441 header s, and</t>441 header fields, and</t> 442 442 <t>the "private" cache response directive (see <xref 443 443 target="cache-response-directive" /> does not appear in the response, if 444 444 the cache is shared, and</t> 445 <t>the "Authorization" header (see &header-authorization;) does not445 <t>the "Authorization" header field (see &header-authorization;) does not 446 446 appear in the request, if the cache is shared, unless the response 447 447 explicitly allows it (see <xref target="caching.authenticated.responses" … … 449 449 <t>the response either: 450 450 <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" 452 452 />), or</t> 453 453 <t>contains a max-age response cache directive (see <xref … … 482 482 <t> 483 483 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, 485 485 but &MUST; treat it as a partial response &partial;. Partial responses can 486 486 be combined as described in &combining-byte-ranges;; the result might be a … … 490 490 </t> 491 491 <t> 492 A cache that does not support the Range and Content-Range header s492 A cache that does not support the Range and Content-Range header fields 493 493 &MUST-NOT; store incomplete or partial responses. 494 494 </t> … … 508 508 <t>the request method associated with the stored response allows it to 509 509 be used for the presented request, and</t> 510 <t>selecting request-header s nominated by the stored response (if any)510 <t>selecting request-header fields nominated by the stored response (if any) 511 511 match those presented (see <xref target="caching.negotiated.responses" 512 512 />), and</t> … … 543 543 <t> 544 544 Caches &MUST; use the most recent response (as determined by the Date 545 header ) when more than one suitable response is stored. They can also545 header field) when more than one suitable response is stored. They can also 546 546 forward a request with "Cache-Control: max-age=0" or "Cache-Control: 547 547 no-cache" to disambiguate which response to use. … … 558 558 The primary mechanism for determining freshness is for an origin server to 559 559 provide an explicit expiration time in the future, using either the Expires 560 header (<xref target="header.expires" />) or the max-age response cache560 header field (<xref target="header.expires" />) or the max-age response cache 561 561 directive (<xref target="cache-response-directive" />). Generally, origin 562 562 servers will assign future explicit expiration times to responses in the … … 573 573 Since origin servers do not always provide explicit expiration times, HTTP 574 574 caches &MAY; assign heuristic expiration times when explicit times are not 575 specified, employing algorithms that use other heade rvalues (such as the575 specified, employing algorithms that use other heade field values (such as the 576 576 Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 577 577 specification does not provide specific algorithms, but does impose … … 619 619 <t>If the max-age response cache directive (<xref 620 620 target="cache-response-directive" />) is present, use its value, or</t> 621 <t>If the Expires response header (<xref target="header.expires" />) is622 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, 623 623 or</t> 624 624 <t>Otherwise, no explicit expiration time is present in the response. A … … 643 643 <t> 644 644 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 if645 &SHOULD; attach a Warning header field with a 113 warn-code to the response if 646 646 its current_age is more than 24 hours and such a warning is not already 647 647 present. 648 648 </t> 649 649 <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;), 651 651 the heuristic expiration value &SHOULD; be no more than some fraction of 652 652 the interval since that time. A typical setting of this fraction might be … … 668 668 <section anchor="age.calculations" title="Calculating Age"> 669 669 <t> 670 HTTP/1.1 uses the Age response-header to convey the estimated age of the670 HTTP/1.1 uses the Age response-header field to convey the estimated age of the 671 671 response message when obtained from a cache. The Age field value is the 672 672 cache's estimate of the amount of time since the response was generated or … … 683 683 <list> 684 684 <t> 685 The term "age_value" denotes the value of the Age header (<xref685 The term "age_value" denotes the value of the Age header field (<xref 686 686 target="header.age"/>), in a form appropriate for arithmetic 687 687 operation; or 0, if not available. … … 693 693 <list> 694 694 <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, 696 696 with every response, giving the time at which the response was 697 697 generated. The term "date_value" denotes the value of the Date 698 header , in a form appropriate for arithmetic operations. See699 &header-date; for the definition of the Date header , and for700 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. 701 701 </t> 702 702 </list> … … 788 788 </t> 789 789 <t> 790 Stale responses &SHOULD; have a Warning header with the 110 warn-code (see790 Stale responses &SHOULD; have a Warning header field with the 110 warn-code (see 791 791 <xref target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be 792 792 sent on stale responses if the cache is disconnected. … … 797 797 requesting client, and the received response is no longer fresh, the cache 798 798 &SHOULD; forward it to the requesting client without adding a new Warning 799 (but without removing any existing Warning header s). A cache &SHOULD-NOT;799 (but without removing any existing Warning header fields). A cache &SHOULD-NOT; 800 800 attempt to validate a response simply because that response became stale in 801 801 transit. … … 816 816 <t> 817 817 When sending such a conditional request, the cache &SHOULD; add an 818 If-Modified-Since header whose value is that of the Last-Modified header819 f rom 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"/>) 820 820 stored response, if available. 821 821 </t> 822 822 <t> 823 Additionally, the cache &SHOULD; add an If-None-Match header whose value is824 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, 825 825 if present. However, if any of the stored responses contains only partial 826 826 content, its entity-tag &SHOULD-NOT; be included in the If-None-Match … … 830 830 <t> 831 831 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"/>. 833 833 </t> 834 834 <t> … … 856 856 The following HTTP methods &MUST; cause a cache to invalidate the effective 857 857 Request URI (&effective-request-uri;) as well as the URI(s) in the Location 858 and Content-Location header s (if present):858 and Content-Location header fields (if present): 859 859 <list style="symbols"> 860 860 <t>PUT</t> … … 864 864 </t> 865 865 <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 867 867 &MUST-NOT; be performed if the host part of that URI differs from the host 868 868 part in the effective request URI (&effective-request-uri;). This helps … … 891 891 <t> 892 892 Shared caches &MUST-NOT; use a cached response to a request with an 893 Authorization header (&header-authorization;) to satisfy any subsequent893 Authorization header field (&header-authorization;) to satisfy any subsequent 894 894 request unless a cache directive that allows such responses to be stored is 895 895 present in the response. … … 917 917 When a cache receives a request that can be satisfied by a stored response 918 918 that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT; 919 use that response unless all of the selecting request-header s nominated by920 the Vary header match in both the original request (i.e., that associated919 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 921 921 with the stored response), and the presented request. 922 922 </t> 923 923 <t> 924 The selecting request-header s from two requests are defined to match if and924 The selecting request-header fields from two requests are defined to match if and 925 925 only if those in the first request can be transformed to those in the 926 926 second request by applying any of the following: 927 927 <list style="symbols"> 928 928 <t> 929 adding or removing whitespace, where allowed in the header 's syntax929 adding or removing whitespace, where allowed in the header field's syntax 930 930 </t> 931 931 <t> … … 934 934 </t> 935 935 <t> 936 normalizing both header values in a way that is known to have937 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., 938 938 re-ordering field values when order is not significant; 939 939 case-normalization, where values are defined to be case-insensitive) … … 952 952 </t> 953 953 <t> 954 The stored response with matching selecting request-header s is known as the954 The stored response with matching selecting request-header fields is known as the 955 955 selected response. 956 956 </t> … … 962 962 </section> 963 963 964 <section anchor="combining. headers" title="Combining Responses">964 <section anchor="combining.responses" title="Combining Responses"> 965 965 <t> 966 966 When a cache receives a 304 (Not Modified) response or a 206 (Partial … … 984 984 </t> 985 985 <t> 986 The stored response header s are used as those of the updated response,986 The stored response header fields are used as those of the updated response, 987 987 except that 988 988 <list style="symbols"> 989 <t>any stored Warning header s with warn-code 1xx (see <xref989 <t>any stored Warning header fields with warn-code 1xx (see <xref 990 990 target="header.warning" />) &MUST; be deleted.</t> 991 <t>any stored Warning header s with warn-code 2xx &MUST; be retained.</t>992 <t>any other header s provided in the new response &MUST; replace all993 instances of the corresponding header s from the stored response.</t>994 </list> 995 </t> 996 <t> 997 The updated response header s &MUST; be used to replace those of the stored991 <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 998 998 response in cache (unless the stored response is removed from cache). In 999 999 the case of a 206 response, the combined representation &MAY; be stored. … … 1035 1035 If a cache receives a value larger than the largest positive integer it can 1036 1036 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>). Caches1037 an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches 1038 1038 &SHOULD; use an arithmetic type of at least 31 bits of range. 1039 1039 </t> … … 1179 1179 <t>The no-transform request directive indicates that an intermediate 1180 1180 cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or 1181 Content-Type request header s, nor the request representation.</t>1181 Content-Type request header fields, nor the request representation.</t> 1182 1182 </list> 1183 1183 </t> … … 1238 1238 <t>If the private response directive specifies one or more field-names, 1239 1239 this requirement is limited to the field-values associated with the 1240 listed response header s. That is, the specified field-names(s)1240 listed response header fields. That is, the specified field-names(s) 1241 1241 &MUST-NOT; be stored by a shared cache, whereas the remainder of the 1242 1242 response message &MAY; be.</t> … … 1261 1261 <t>If the no-cache response directive specifies one or more field-names, 1262 1262 this requirement is limited to the field-values associated with the 1263 listed response header s. That is, the specified field-name(s) &MUST-NOT;1263 listed response header fields. That is, the specified field-name(s) &MUST-NOT; 1264 1264 be sent in the response to a subsequent request without successful 1265 1265 validation on the origin server. This allows an origin server to prevent … … 1337 1337 <t>The s-maxage response directive indicates that, in shared caches, the 1338 1338 maximum age specified by this directive overrides the maximum age 1339 specified by either the max-age directive or the Expires header . The1339 specified by either the max-age directive or the Expires header field. The 1340 1340 s-maxage directive also implies the semantics of the proxy-revalidate 1341 1341 response directive.</t> … … 1349 1349 <t>The no-transform response directive indicates that an intermediate 1350 1350 cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or 1351 Content-Type response header s, nor the response representation.</t>1351 Content-Type response header fields, nor the response representation.</t> 1352 1352 </list> 1353 1353 </t> … … 1540 1540 <t> 1541 1541 The set of header fields named by the Vary field value is known as the 1542 selecting request-header s.1542 selecting request-header fields. 1543 1543 </t> 1544 1544 <t> … … 1554 1554 <t> 1555 1555 A Vary field value of "*" signals that unspecified parameters not limited 1556 to the request-header s (e.g., the network address of the client), play a1556 to the request-header fields (e.g., the network address of the client), play a 1557 1557 role in the selection of the response representation; therefore, a cache 1558 1558 cannot determine whether this response is appropriate. The "*" value … … 1588 1588 </t> 1589 1589 <t> 1590 Warning header s can in general be applied to any message, however some1590 Warning header fields can in general be applied to any message, however some 1591 1591 warn-codes are specific to caches and can only be applied to response 1592 1592 messages. … … 1602 1602 <x:ref>warn-agent</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref> 1603 1603 ; the name or pseudonym of the server adding 1604 ; the Warning header , for use in debugging1604 ; the Warning header field, for use in debugging 1605 1605 <x:ref>warn-text</x:ref> = <x:ref>quoted-string</x:ref> 1606 1606 <x:ref>warn-date</x:ref> = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref> … … 1616 1616 </t> 1617 1617 <t> 1618 Systems that generate multiple Warning header s &SHOULD; order them with1619 this user agent behavior in mind. New Warning header s &SHOULD; be added1620 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. 1621 1621 </t> 1622 1622 <t> … … 1636 1636 </t> 1637 1637 <t> 1638 If an implementation sends a message with one or more Warning header s to a1638 If an implementation sends a message with one or more Warning header fields to a 1639 1639 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 the1640 in each warning-value a warn-date that matches the Date header field in the 1641 1641 message. 1642 1642 </t> … … 1647 1647 storing, forwarding, or using it. (preventing the consequences of naive 1648 1648 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. 1650 1650 </t> 1651 1651 <t> … … 2274 2274 </t> 2275 2275 <t> 2276 Do not mention RFC 2047 encoding and multiple languages in Warning header s2276 Do not mention RFC 2047 encoding and multiple languages in Warning header fields 2277 2277 anymore, as these aspects never were implemented. 2278 2278 (<xref target="header.warning" />) … … 2417 2417 <section anchor="changes.since.02" title="Since draft-ietf-httpbis-p6-cache-02"> 2418 2418 <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" />): 2420 2420 <list style="symbols"> 2421 <t>Reference RFC 3984, and update header registrations for headers defined in this2421 <t>Reference RFC 3984, and update header field registrations for header fields defined in this 2422 2422 document.</t> 2423 2423 </list> … … 2448 2448 <t> 2449 2449 Rewrite ABNFs to spell out whitespace rules, factor out 2450 header value format definitions.2450 header field value format definitions. 2451 2451 </t> 2452 2452 </list> … … 2496 2496 <t> 2497 2497 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>: 2498 Vary and non-existant headers2498 WVary and non-existant headers" 2499 2499 </t> 2500 2500 </list> -
draft-ietf-httpbis/latest/p7-auth.html
r981 r994 393 393 <meta name="dct.creator" content="Reschke, J. F."> 394 394 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 395 <meta name="dct.issued" scheme="ISO8601" content="2010-09-0 1">395 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 396 396 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 397 397 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 424 424 </tr> 425 425 <tr> 426 <td class="left">Expires: March 5, 2011</td>426 <td class="left">Expires: March 11, 2011</td> 427 427 <td class="right">HP</td> 428 428 </tr> … … 477 477 <tr> 478 478 <td class="left"></td> 479 <td class="right">September 1, 2010</td>479 <td class="right">September 7, 2010</td> 480 480 </tr> 481 481 </tbody> … … 503 503 in progress”. 504 504 </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> 506 506 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 507 507 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 643 643 <p id="rfc.section.3.1.p.5"> </p> 644 644 <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-header s from the new request to allow the origin server to authenticate646 t he 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 s from the new request to allow the origin server to authenticate649 t he 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. 650 650 </li> 651 651 <li>If the response includes the "public" cache-control directive, it <em class="bcp14">MAY</em> be returned in reply to any subsequent request. … … 904 904 </ul> 905 905 <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a> <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 (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):906 <p id="rfc.section.B.4.p.1">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 907 907 </p> 908 908 <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> 910 910 </ul> 911 911 <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p7-auth-03</a></h2> … … 916 916 <li>Use "/" instead of "|" for alternatives.</li> 917 917 <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> 919 919 </ul> 920 920 <h2 id="rfc.section.B.7"><a href="#rfc.section.B.7">B.7</a> <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 375 375 subsequent request. But (if the specified maximum age has 376 376 passed) a proxy cache &MUST; first revalidate it with the origin 377 server, using the request-header s from the new request to allow377 server, using the request-header fields from the new request to allow 378 378 the origin server to authenticate the new request. (This is the 379 379 defined behavior for s-maxage.) If the response includes "s-maxage=0", … … 385 385 subsequent request. But if the response is stale, all caches 386 386 &MUST; first revalidate it with the origin server, using the 387 request-header s from the new request to allow the origin server387 request-header fields from the new request to allow the origin server 388 388 to authenticate the new request.</t> 389 389 … … 904 904 <section title="Since draft-ietf-httpbis-p7-auth-02" anchor="changes.since.02"> 905 905 <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"/>): 907 907 <list style="symbols"> 908 908 <t> 909 Reference RFC 3984, and update header registrations for headers defined909 Reference RFC 3984, and update header field registrations for header fields defined 910 910 in this document. 911 911 </t> … … 932 932 <t> 933 933 Rewrite ABNFs to spell out whitespace rules, factor out 934 header value format definitions.934 header field value format definitions. 935 935 </t> 936 936 </list>
Note: See TracChangeset
for help on using the changeset viewer.