Ignore:
Timestamp:
Sep 26, 2009, 3:09:09 AM (10 years ago)
Author:
julian.reschke@…
Message:

editorial: enhance readability of header introductions

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

Legend:

Unmodified
Added
Removed

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

    r697 r698  
    400400      <meta name="DC.Creator" content="Reschke, J. F.">
    401401      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    402       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
     402      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
    403403      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    437437         </tr>
    438438         <tr>
    439             <td class="header left">Expires: March 29, 2010</td>
     439            <td class="header left">Expires: March 30, 2010</td>
    440440            <td class="header right">H. Frystyk</td>
    441441         </tr>
    … …  
    486486         <tr>
    487487            <td class="header left"></td>
    488             <td class="header right">September 25, 2009</td>
     488            <td class="header right">September 26, 2009</td>
    489489         </tr>
    490490      </table>
    … …  
    510510      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    511511      </p>
    512       <p>This Internet-Draft will expire in March 29, 2010.</p>
     512      <p>This Internet-Draft will expire in March 30, 2010.</p>
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    514514      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    18431843      <div id="rfc.iref.h.7"></div>
    18441844      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
    1845       <p id="rfc.section.9.2.p.1">The "Content-Length" entity-header field indicates the size of the entity-body, in number of OCTETs, sent to the recipient
    1846          or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
     1845      <p id="rfc.section.9.2.p.1">The "Content-Length" entity-header field indicates the size of the entity-body, in number of OCTETs. In the case of responses
     1846         to the HEAD method, it indicates the size of the entity-body that would have been sent had the request been a GET.
    18471847      </p>
    18481848      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.content-length" class="smpl">Content-Length</a>   = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>
    … …  
    18981898      <div id="rfc.iref.h.10"></div>
    18991899      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    1900       <p id="rfc.section.9.4.p.1">The "Host" request-header field specifies the Internet host and port number of the resource being requested, as obtained from
    1901          the original URI given by the user or referring resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or
    1902          gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on
    1903          a single IP address.
     1900      <p id="rfc.section.9.4.p.1">The "Host" request-header field specifies the Internet host and port number of the resource being requested, allowing the
     1901         origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple
     1902         host names on a single IP address.
     1903      </p>
     1904      <p id="rfc.section.9.4.p.2">The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL obtained from the user or referring
     1905         resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>).
    19041906      </p>
    19051907      <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span>  <a href="#header.host" class="smpl">Host</a>   = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>
    19061908  <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>
    1907 </pre><p id="rfc.section.9.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
     1909</pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
    19081910         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
    19091911      </p>
    19101912      <div id="rfc.figure.u.59"></div><pre class="text">  GET /pub/WWW/ HTTP/1.1
    19111913  Host: www.example.org
    1912 </pre><p id="rfc.section.9.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name
     1914</pre><p id="rfc.section.9.4.p.6">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name
    19131915         for the service being requested, then the Host header field <em class="bcp14">MUST</em> be given with an empty value. An HTTP/1.1 proxy <em class="bcp14">MUST</em> ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being
    19141916         requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
    19151917      </p>
    1916       <p id="rfc.section.9.4.p.6">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.
     1918      <p id="rfc.section.9.4.p.7">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.
    19171919      </p>
    19181920      <div id="rfc.iref.t.2"></div>
    19191921      <div id="rfc.iref.h.11"></div>
    19201922      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    1921       <p id="rfc.section.9.5.p.1">The "TE" request-header field indicates what extension transfer-codings it is willing to accept in the response and whether
    1922          or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers"
    1923          and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
     1923      <p id="rfc.section.9.5.p.1">The "TE" request-header field indicates what extension transfer-codings it is willing to accept in the response, and whether
     1924         or not it is willing to accept trailer fields in a chunked transfer-coding.
     1925      </p>
     1926      <p id="rfc.section.9.5.p.2">Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
     1927         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    19241928      </p>
    19251929      <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span>  <a href="#header.te" class="smpl">TE</a>        = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>
    … …  
    19281932  <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
    19291933  <a href="#header.te" class="smpl">te-ext</a>    = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" ( <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> ) ]
    1930 </pre><p id="rfc.section.9.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
     1934</pre><p id="rfc.section.9.5.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    19311935         as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
    19321936      </p>
    1933       <p id="rfc.section.9.5.p.4">Examples of its use are:</p>
     1937      <p id="rfc.section.9.5.p.5">Examples of its use are:</p>
    19341938      <div id="rfc.figure.u.61"></div><pre class="text">  TE: deflate
    19351939  TE:
    19361940  TE: trailers, deflate;q=0.5
    1937 </pre><p id="rfc.section.9.5.p.6">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
    1938       </p>
    1939       <p id="rfc.section.9.5.p.7">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
     1941</pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
     1942      </p>
     1943      <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    19401944      <ol>
    19411945         <li>
    … …  
    19601964         </li>
    19611965      </ol>
    1962       <p id="rfc.section.9.5.p.8">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
     1966      <p id="rfc.section.9.5.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
    19631967         is always acceptable.
    19641968      </p>
    … …  
    19861990      <div id="rfc.iref.h.13"></div>
    19871991      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    1988       <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what (if any) type of transformation has been applied to the message
    1989          body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the
    1990          transfer-coding is a property of the message, not of the entity.
     1992      <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body.
     1993         It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
     1994         are not.
    19911995      </p>
    19921996      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>
    … …  
    20022006      <div id="rfc.iref.h.14"></div>
    20032007      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2004       <p id="rfc.section.9.8.p.1">The "Upgrade" general-header field allows the client to specify what additional communication protocols it supports and would
    2005          like to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
     2008      <p id="rfc.section.9.8.p.1">The "Upgrade" general-header field allows the client to specify what additional communication protocols it would like to use,
     2009         if the server chooses to switch protocols. Additionally, the server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched
     2010         to.
    20062011      </p>
    20072012      <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>   = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>
    … …  
    26832688      </p>
    26842689      <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling
    2685          the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2690         the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    26862691      </p>
    26872692      <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
    … …  
    27732778      <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    27742779         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    2775          computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
     2780         computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
    27762781      </p>
    27772782      <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0
    … …  
    34443449                     </ul>
    34453450                  </li>
    3446                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.8">A</a>, <a class="iref" href="#rfc.xref.Part3.9">B.3</a><ul class="ind">
     3451                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.4</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.9">A</a>, <a class="iref" href="#rfc.xref.Part3.10">B.3</a><ul class="ind">
     3452                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">9.7</a></li>
    34473453                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li>
    34483454                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li>

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

    r697 r698  
    25542554<t>
    25552555   The "Content-Length" entity-header field indicates the size of the
    2556    entity-body, in number of OCTETs, sent to the recipient or,
    2557    in the case of the HEAD method, the size of the entity-body that
    2558    would have been sent had the request been a GET.
     2556   entity-body, in number of OCTETs. In the case of responses to the HEAD
     2557   method, it indicates the size of the entity-body that would have been sent
     2558   had the request been a GET.
    25592559</t>
    25602560<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/>
    … …  
    26742674<t>
    26752675   The "Host" request-header field specifies the Internet host and port
    2676    number of the resource being requested, as obtained from the original
    2677    URI given by the user or referring resource (generally an http URI,
    2678    as described in <xref target="http.uri"/>). The Host field value &MUST; represent
    2679    the naming authority of the origin server or gateway given by the
    2680    original URL. This allows the origin server or gateway to
    2681    differentiate between internally-ambiguous URLs, such as the root "/"
    2682    URL of a server for multiple host names on a single IP address.
     2676   number of the resource being requested, allowing the origin server or
     2677   gateway to differentiate between internally-ambiguous URLs, such as the root
     2678   "/" URL of a server for multiple host names on a single IP address.
     2679</t>
     2680<t>   
     2681   The Host field value &MUST; represent the naming authority of the origin
     2682   server or gateway given by the original URL obtained from the user or
     2683   referring resource (generally an http URI, as described in
     2684   <xref target="http.uri"/>).
    26832685</t>
    26842686<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/>
    … …  
    27242726<t>
    27252727   The "TE" request-header field indicates what extension transfer-codings
    2726    it is willing to accept in the response and whether or not it is
    2727    willing to accept trailer fields in a chunked transfer-coding. Its
    2728    value may consist of the keyword "trailers" and/or a comma-separated
     2728   it is willing to accept in the response, and whether or not it is
     2729   willing to accept trailer fields in a chunked transfer-coding.
     2730</t>
     2731<t>
     2732   Its value may consist of the keyword "trailers" and/or a comma-separated
    27292733   list of extension transfer-coding names with optional accept
    27302734   parameters (as described in <xref target="transfer.codings"/>).
    … …  
    28382842  <x:anchor-alias value="Transfer-Encoding-v"/>
    28392843<t>
    2840    The "Transfer-Encoding" general-header field indicates what (if any)
    2841    type of transformation has been applied to the message body in order
    2842    to safely transfer it between the sender and the recipient. This
    2843    differs from the content-coding in that the transfer-coding is a
    2844    property of the message, not of the entity.
     2844   The "Transfer-Encoding" general-header field indicates what transfer-codings
     2845   (if any) have been applied to the message body. It differs from
     2846   Content-Encoding (&content-codings;) in that transfer-codings are a property
     2847   of the message (and therefore are removed by intermediaries), whereas
     2848   content-codings are not.
    28452849</t>
    28462850<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/>
    … …  
    28742878<t>
    28752879   The "Upgrade" general-header field allows the client to specify what
    2876    additional communication protocols it supports and would like to use
    2877    if the server finds it appropriate to switch protocols. The server
    2878    &MUST; use the Upgrade header field within a 101 (Switching Protocols)
    2879    response to indicate which protocol(s) are being switched.
     2880   additional communication protocols it would like to use, if the server
     2881   chooses to switch protocols. Additionally, the server &MUST; use the Upgrade
     2882   header field within a 101 (Switching Protocols) response to indicate which
     2883   protocol(s) are being switched to.
    28802884</t>
    28812885<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/><iref primary="true" item="Grammar" subitem="Upgrade-v"/>

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

    r697 r698  
    399399      <meta name="DC.Creator" content="Reschke, J. F.">
    400400      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    401       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
     401      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
    402402      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    403403      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    … …  
    436436         </tr>
    437437         <tr>
    438             <td class="header left">Expires: March 29, 2010</td>
     438            <td class="header left">Expires: March 30, 2010</td>
    439439            <td class="header right">H. Frystyk</td>
    440440         </tr>
    … …  
    485485         <tr>
    486486            <td class="header left"></td>
    487             <td class="header right">September 25, 2009</td>
     487            <td class="header right">September 26, 2009</td>
    488488         </tr>
    489489      </table>
    … …  
    509509      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    510510      </p>
    511       <p>This Internet-Draft will expire in March 29, 2010.</p>
     511      <p>This Internet-Draft will expire in March 30, 2010.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    15041504      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    15051505      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target.
    1506          The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header
    1507          field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response.
     1506         The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
    15081507      </p>
    15091508      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
    … …  
    15661565      <div id="rfc.iref.h.5"></div>
    15671566      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
    1568       <p id="rfc.section.9.4.p.1">The "Location" response-header field is used for the identification of a new resource or to redirect the recipient to a location
    1569          other than the request-target for completion of the request. For 201 (Created) responses, the Location is that of the new
    1570          resource which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single URI.
    1571       </p>
     1567      <p id="rfc.section.9.4.p.1">The "Location" response-header field is used to identify a newly created resource, or to redirect the recipient to a different
     1568         location for completion of the request.
     1569      </p>
     1570      <p id="rfc.section.9.4.p.2">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
     1571         the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
     1572      </p>
     1573      <p id="rfc.section.9.4.p.3">The field value consists of a single URI.</p>
    15721574      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.location" class="smpl">Location</a>       = "Location" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.location" class="smpl">Location-v</a>
    15731575  <a href="#header.location" class="smpl">Location-v</a>     = <a href="#abnf.dependencies" class="smpl">URI</a>
    1574 </pre><p id="rfc.section.9.4.p.3">An example is:</p>
     1576</pre><p id="rfc.section.9.4.p.5">An example is:</p>
    15751577      <div id="rfc.figure.u.18"></div><pre class="text">  Location: http://www.example.org/pub/WWW/People.html
    1576 </pre><p id="rfc.section.9.4.p.5">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p>
     1578</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>
    15771579      <ul>
    15781580         <li>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</li>
    … …  
    15871589      <div id="rfc.iref.h.6"></div>
    15881590      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
    1589       <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be
    1590          useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain.
     1591      <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client
     1592         is attempting to trace a request which appears to be failing or looping in mid-chain.
    15911593      </p>
    15921594      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a>   = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a>
    … …  
    16011603      <div id="rfc.iref.h.7"></div>
    16021604      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    1603       <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the
    1604          resource from which the request-target was obtained (the "referrer", although the header field is misspelled.).
     1605      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the request-target
     1606         was obtained (the "referrer", although the header field is misspelled.).
    16051607      </p>
    16061608      <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.
    … …  
    16241626      <p id="rfc.section.9.7.p.1">The response-header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service
    16251627         is expected to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing
    1626          the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after
    1627          the time of the response.
    1628       </p>
     1628         the redirected request.
     1629      </p>
     1630      <p id="rfc.section.9.7.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
    16291631      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a>   = "Retry-After" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.retry-after" class="smpl">Retry-After-v</a>
    16301632  <a href="#header.retry-after" class="smpl">Retry-After-v</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    16311633</pre><div id="rule.delta-seconds">
    1632          <p id="rfc.section.9.7.p.3">  Time spans are non-negative decimal integers, representing time in seconds.</p>
     1634         <p id="rfc.section.9.7.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
    16331635      </div>
    16341636      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.26"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    1635 </pre><p id="rfc.section.9.7.p.5">Two examples of its use are</p>
     1637</pre><p id="rfc.section.9.7.p.6">Two examples of its use are</p>
    16361638      <div id="rfc.figure.u.24"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
    16371639  Retry-After: 120
    1638 </pre><p id="rfc.section.9.7.p.7">In the latter example, the delay is 2 minutes.</p>
     1640</pre><p id="rfc.section.9.7.p.8">In the latter example, the delay is 2 minutes.</p>
    16391641      <div id="rfc.iref.s.43"></div>
    16401642      <div id="rfc.iref.h.9"></div>
    16411643      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    1642       <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.
    1643          The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance
    1644          for identifying the application.
     1644      <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p>
     1645      <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     1646         identifying the application.
    16451647      </p>
    16461648      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.server" class="smpl">Server</a>         = "Server" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.server" class="smpl">Server-v</a>
    16471649  <a href="#header.server" class="smpl">Server-v</a>       = <a href="#abnf.dependencies" class="smpl">product</a>
    16481650                   *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    1649 </pre><p id="rfc.section.9.8.p.3">Example:</p>
     1651</pre><p id="rfc.section.9.8.p.4">Example:</p>
    16501652      <div id="rfc.figure.u.26"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    1651 </pre><p id="rfc.section.9.8.p.5">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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1653</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.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    16521654      </p>
    16531655      <div class="note">
    … …  
    16621664      <p id="rfc.section.9.9.p.1">The "User-Agent" request-header field contains information about the user agent originating the request. This is for statistical
    16631665         purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses
    1664          to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the
    1665          product tokens are listed in order of their significance for identifying the application.
     1666         to avoid particular user agent limitations.
     1667      </p>
     1668      <p id="rfc.section.9.9.p.2">User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens
     1669         are listed in order of their significance for identifying the application.
    16661670      </p>
    16671671      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a>     = "User-Agent" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.user-agent" class="smpl">User-Agent-v</a>
    16681672  <a href="#header.user-agent" class="smpl">User-Agent-v</a>   = <a href="#abnf.dependencies" class="smpl">product</a>
    16691673                   *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    1670 </pre><p id="rfc.section.9.9.p.3">Example:</p>
     1674</pre><p id="rfc.section.9.9.p.4">Example:</p>
    16711675      <div id="rfc.figure.u.28"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    16721676</pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    … …  
    22902294      </p>
    22912295      <p id="rfc.section.A.2.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly
    2292          in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
     2296         in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
    22932297      </p>
    22942298      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    27192723            </li>
    27202724            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    2721                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.28">A.2</a><ul class="ind">
     2725                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a><ul class="ind">
    27222726                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2</a></li>
    27232727                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li>
    27242728                        <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.23">8.5.6</a></li>
    27252729                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li>
    2726                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a></li>
     2730                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a></li>
    27272731                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">6</a></li>
    27282732                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li>
    2729                         <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.9</a></li>
     2733                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a></li>
    27302734                        <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li>
    27312735                        <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">3</a></li>
    27322736                        <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a></li>
    2733                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">A.2</a></li>
     2737                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a></li>
    27342738                        <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">7.8</a></li>
    27352739                     </ul>

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

    r697 r698  
    18711871   supported by the resource identified by the request-target. The purpose of
    18721872   this field is strictly to inform the recipient of valid methods
    1873    associated with the resource. An Allow header field &MUST; be
    1874    present in a 405 (Method Not Allowed) response.
     1873   associated with the resource.
    18751874</t>
    18761875<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/><iref primary="true" item="Grammar" subitem="Allow-v"/>
    … …  
    20062005  <x:anchor-alias value="Location-v"/>
    20072006<t>
    2008    The "Location" response-header field is used for the identification of a
    2009    new resource or to redirect the recipient to a location other than the
    2010    request-target for completion of the request.  For 201 (Created)
    2011    responses, the Location is that of the new resource which was created
    2012    by the request. For 3xx responses, the location &SHOULD; indicate the
    2013    server's preferred URI for automatic redirection to the resource. The
    2014    field value consists of a single URI.
     2007   The "Location" response-header field is used to identify a newly created
     2008   resource, or to redirect the recipient to a different location for
     2009   completion of the request.
     2010</t>
     2011<t>
     2012   For 201 (Created) responses, the Location is the URI of the new resource
     2013   which was created by the request. For 3xx responses, the location &SHOULD;
     2014   indicate the server's preferred URI for automatic redirection to the
     2015   resource.
     2016</t>
     2017<t>
     2018   The field value consists of a single URI.
    20152019</t>
    20162020<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/><iref primary="true" item="Grammar" subitem="Location-v"/>
    … …  
    20492053<t>
    20502054   The "Max-Forwards" request-header field provides a mechanism with the
    2051    TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) methods to limit the
    2052    number of proxies or gateways that can forward the request to the
    2053    next inbound server. This can be useful when the client is attempting
    2054    to trace a request chain which appears to be failing or looping in
    2055    mid-chain.
     2055   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
     2056   methods to limit the number of times that the request is forwarded by
     2057   proxies or gateways. This can be useful when the client is attempting to
     2058   trace a request which appears to be failing or looping in mid-chain.
    20562059</t>
    20572060<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/><iref primary="true" item="Grammar" subitem="Max-Forwards-v"/>
    … …  
    20852088  <x:anchor-alias value="Referer-v"/>
    20862089<t>
    2087    The "Referer" [sic] request-header field allows the client to specify, for
    2088    the server's benefit, the address (URI) of the resource from which the
    2089    request-target was obtained (the "referrer", although the header field is
    2090    misspelled.).
     2090   The "Referer" [sic] request-header field allows the client to specify the
     2091   URI of the resource from which the request-target was obtained (the
     2092   "referrer", although the header field is misspelled.).
    20912093</t>
    20922094<t>
    … …  
    21312133   be unavailable to the requesting client. This field &MAY; also be used
    21322134   with any 3xx (Redirection) response to indicate the minimum time the
    2133    user-agent is asked wait before issuing the redirected request. The
    2134    value of this field can be either an HTTP-date or an integer number
     2135   user-agent is asked wait before issuing the redirected request.
     2136</t>
     2137<t>
     2138   The value of this field can be either an HTTP-date or an integer number
    21352139   of seconds (in decimal) after the time of the response.
    21362140</t>
    … …  
    21662170<t>
    21672171   The "Server" response-header field contains information about the
    2168    software used by the origin server to handle the request. The field
    2169    can contain multiple product tokens (&product-tokens;) and comments
    2170    identifying the server and any significant subproducts. The product
    2171    tokens are listed in order of their significance for identifying the
    2172    application.
     2172   software used by the origin server to handle the request.
     2173</t>
     2174<t>
     2175   The field can contain multiple product tokens (&product-tokens;) and
     2176   comments (&header-fields;) identifying the server and any significant
     2177   subproducts. The product tokens are listed in order of their significance
     2178   for identifying the application.
    21732179</t>
    21742180<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/><iref primary="true" item="Grammar" subitem="Server-v"/>
    … …  
    22092215   the tracing of protocol violations, and automated recognition of user
    22102216   agents for the sake of tailoring responses to avoid particular user
    2211    agent limitations. User agents &SHOULD; include this field with
    2212    requests. The field can contain multiple product tokens (&product-tokens;)
    2213    and comments identifying the agent and any subproducts which form a
    2214    significant part of the user agent. By convention, the product tokens
    2215    are listed in order of their significance for identifying the
    2216    application.
     2217   agent limitations.
     2218</t>
     2219<t>
     2220   User agents &SHOULD; include this field with requests. The field can contain
     2221   multiple product tokens (&product-tokens;) and comments (&header-fields;)
     2222   identifying the agent and any subproducts which form a significant part of
     2223   the user agent. By convention, the product tokens are listed in order of
     2224   their significance for identifying the application.
    22172225</t>
    22182226<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/><iref primary="true" item="Grammar" subitem="User-Agent-v"/>

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

    r697 r698  
    407407      <meta name="DC.Creator" content="Reschke, J. F.">
    408408      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    409       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
     409      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
    410410      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    411411      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    439439         </tr>
    440440         <tr>
    441             <td class="header left">Expires: March 29, 2010</td>
     441            <td class="header left">Expires: March 30, 2010</td>
    442442            <td class="header right">HP</td>
    443443         </tr>
    … …  
    492492         <tr>
    493493            <td class="header left"></td>
    494             <td class="header right">September 25, 2009</td>
     494            <td class="header right">September 26, 2009</td>
    495495         </tr>
    496496      </table>
    … …  
    516516      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    517517      </p>
    518       <p>This Internet-Draft will expire in March 29, 2010.</p>
     518      <p>This Internet-Draft will expire in March 30, 2010.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    10101010      <div id="rfc.iref.h.1"></div>
    10111011      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
    1012       <p id="rfc.section.5.1.p.1">The "Accept" request-header field can be used to specify certain media types which are acceptable for the response. Accept
    1013          headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of
    1014          a request for an in-line image.
     1012      <p id="rfc.section.5.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers
     1013         can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request
     1014         for an in-line image.
    10151015      </p>
    10161016      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></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>
    … …  
    11121112      <div id="rfc.iref.h.2"></div>
    11131113      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
    1114       <p id="rfc.section.5.2.p.1">The "Accept-Charset" request-header field can be used to indicate what character sets are acceptable for the response. This
    1115          field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
     1114      <p id="rfc.section.5.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.
     1115         This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
    11161116         to a server which is capable of representing documents in those character sets.
    11171117      </p>
    … …  
    11351135      <div id="rfc.iref.h.3"></div>
    11361136      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
    1137       <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) that are acceptable in the response.
     1137      <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
    11381138      </p>
    11391139      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    11861186      <div id="rfc.iref.h.4"></div>
    11871187      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
    1188       <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field is similar to Accept, but restricts the set of natural languages that are preferred
    1189          as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
     1188      <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred
     1189         in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
    11901190      </p>
    11911191      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    12371237      <div id="rfc.iref.h.5"></div>
    12381238      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    1239       <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field is used as a modifier to the media-type. When present, its value indicates what
    1240          additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order
    1241          to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document
    1242          to be compressed without losing the identity of its underlying media type.
     1239      <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field indicates what content-codings have been applied to the entity-body, and thus what
     1240         decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
     1241         is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
    12431242      </p>
    12441243      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
    … …  
    12601259      <div id="rfc.iref.h.6"></div>
    12611260      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
    1262       <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the enclosed entity.
    1263          Note that this might not be equivalent to all the languages used within the entity-body.
     1261      <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the entity. Note
     1262         that this might not be equivalent to all the languages used within the entity-body.
    12641263      </p>
    12651264      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
    … …  
    12861285      <div id="rfc.iref.h.7"></div>
    12871286      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
    1288       <p id="rfc.section.5.7.p.1">The "Content-Location" entity-header field <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location
    1289          separate from the requested resource's URI. A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has
     1287      <p id="rfc.section.5.7.p.1">The "Content-Location" entity-header field is used to supply a URI for the entity in the message when it is accessible from
     1288         a location separate from the requested resource's URI.
     1289      </p>
     1290      <p id="rfc.section.5.7.p.2">A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity, especially in the case where a resource has
    12901291         multiple entities associated with it, and those entities actually have separate locations by which they might be individually
    12911292         accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned.
    … …  
    12951296  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    12961297                    <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1297 </pre><p id="rfc.section.5.7.p.3">The value of Content-Location also defines the base URI for the entity.</p>
    1298       <p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of
     1298</pre><p id="rfc.section.5.7.p.4">The value of Content-Location also defines the base URI for the entity.</p>
     1299      <p id="rfc.section.5.7.p.5">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of
    12991300         the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-target if the desire is to identify the source of that particular entity.
    13001301      </p>
    1301       <p id="rfc.section.5.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond
     1302      <p id="rfc.section.5.7.p.6">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond
    13021303         to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple
    13031304         entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    13041305      </p>
    1305       <p id="rfc.section.5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p>
    1306       <p id="rfc.section.5.7.p.7">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p>
     1306      <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p>
     1307      <p id="rfc.section.5.7.p.8">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p>
    13071308      <div id="rfc.iref.c.10"></div>
    13081309      <div id="rfc.iref.h.8"></div>
    … …  
    13461347      <div id="rfc.iref.h.9"></div>
    13471348      <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
    1348       <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of
    1349          the HEAD method, the media type that would have been sent had the request been a GET.
     1349      <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body. In the case of responses to the HEAD method,
     1350         the media type is that which would have been sent had the request been a GET.
    13501351      </p>
    13511352      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>

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

    r697 r698  
    983983  <x:anchor-alias value="media-range"/>
    984984<t>
    985    The "Accept" request-header field can be used to specify certain media
    986    types which are acceptable for the response. Accept headers can be
    987    used to indicate that the request is specifically limited to a small
    988    set of desired types, as in the case of a request for an in-line
    989    image.
     985   The "Accept" request-header field can be used by user agents to specify
     986   response media types that are acceptable. Accept headers can be used to
     987   indicate that the request is specifically limited to a small set of desired
     988   types, as in the case of a request for an in-line image.
    990989</t>
    991990<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="Accept-v"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
    … …  
    11101109  <x:anchor-alias value="Accept-Charset-v"/>
    11111110<t>
    1112    The "Accept-Charset" request-header field can be used to indicate what
    1113    character sets are acceptable for the response. This field allows
     1111   The "Accept-Charset" request-header field can be used by user agents to
     1112   indicate what response character sets are acceptable. This field allows
    11141113   clients capable of understanding more comprehensive or special-purpose
    1115    character sets to signal that capability to a server which is
    1116    capable of representing documents in those character sets.
     1114   character sets to signal that capability to a server which is capable of
     1115   representing documents in those character sets.
    11171116</t>
    11181117<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/><iref primary="true" item="Grammar" subitem="Accept-Charset-v"/>
    … …  
    11551154  <x:anchor-alias value="codings"/>
    11561155<t>
    1157    The "Accept-Encoding" request-header field is similar to Accept, but
    1158    restricts the content-codings (<xref target="content.codings"/>) that are acceptable in
    1159    the response.
     1156   The "Accept-Encoding" request-header field can be used by user agents to
     1157   indicate what response content-codings (<xref target="content.codings"/>)
     1158   are acceptable in the response.
    11601159</t>
    11611160<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="Accept-Encoding-v"/><iref primary="true" item="Grammar" subitem="codings"/>
    … …  
    12451244  <x:anchor-alias value="language-range"/>
    12461245<t>
    1247    The "Accept-Language" request-header field is similar to Accept, but
    1248    restricts the set of natural languages that are preferred as a
    1249    response to the request. Language tags are defined in <xref target="language.tags"/>.
     1246   The "Accept-Language" request-header field can be used by user agents to
     1247   indicate the set of natural languages that are preferred in the response.
     1248   Language tags are defined in <xref target="language.tags"/>.
    12501249</t>
    12511250<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="Accept-Language-v"/><iref primary="true" item="Grammar" subitem="language-range"/>
    … …  
    13411340  <x:anchor-alias value="Content-Encoding-v"/>
    13421341<t>
    1343    The "Content-Encoding" entity-header field is used as a modifier to the
    1344    media-type. When present, its value indicates what additional content
    1345    codings have been applied to the entity-body, and thus what decoding
    1346    mechanisms must be applied in order to obtain the media-type
    1347    referenced by the Content-Type header field. Content-Encoding is
    1348    primarily used to allow a document to be compressed without losing
    1349    the identity of its underlying media type.
     1342   The "Content-Encoding" entity-header field indicates what content-codings
     1343   have been applied to the entity-body, and thus what decoding mechanisms
     1344   must be applied in order to obtain the media-type referenced by the
     1345   Content-Type header field. Content-Encoding is primarily used to allow a
     1346   document to be compressed without losing the identity of its underlying
     1347   media type.
    13501348</t>
    13511349<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/><iref primary="true" item="Grammar" subitem="Content-Encoding-v"/>
    … …  
    13921390<t>
    13931391   The "Content-Language" entity-header field describes the natural
    1394    language(s) of the intended audience for the enclosed entity. Note
    1395    that this might not be equivalent to all the languages used within
    1396    the entity-body.
     1392   language(s) of the intended audience for the entity. Note that this might
     1393   not be equivalent to all the languages used within the entity-body.
    13971394</t>
    13981395<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/><iref primary="true" item="Grammar" subitem="Content-Language-v"/>
    … …  
    14451442  <x:anchor-alias value="Content-Location-v"/>
    14461443<t>
    1447    The "Content-Location" entity-header field &MAY; be used to supply the
    1448    resource location for the entity enclosed in the message when that
    1449    entity is accessible from a location separate from the requested
    1450    resource's URI. A server &SHOULD; provide a Content-Location for the
    1451    variant corresponding to the response entity; especially in the case
    1452    where a resource has multiple entities associated with it, and those
    1453    entities actually have separate locations by which they might be
    1454    individually accessed, the server &SHOULD; provide a Content-Location
    1455    for the particular variant which is returned.
     1444   The "Content-Location" entity-header field is used to supply a URI for the
     1445   entity in the message when it is accessible from a location separate from
     1446   the requested resource's URI.
     1447</t>
     1448<t>
     1449   A server &SHOULD; provide a Content-Location for the variant corresponding
     1450   to the response entity, especially in the case where a resource has multiple
     1451   entities associated with it, and those entities actually have separate
     1452   locations by which they might be individually accessed, the server &SHOULD;
     1453   provide a Content-Location for the particular variant which is returned.
    14561454</t>
    14571455<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/><iref primary="true" item="Grammar" subitem="Content-Location-v"/>
    … …  
    15741572<t>
    15751573   The "Content-Type" entity-header field indicates the media type of the
    1576    entity-body sent to the recipient or, in the case of the HEAD method,
    1577    the media type that would have been sent had the request been a GET.
     1574   entity-body. In the case of responses to the HEAD method, the media type is
     1575   that which would have been sent had the request been a GET.
    15781576</t>
    15791577<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/><iref primary="true" item="Grammar" subitem="Content-Type-v"/>

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

    r697 r698  
    396396      <meta name="DC.Creator" content="Reschke, J. F.">
    397397      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    398       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
     398      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
    399399      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    400400      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    428428         </tr>
    429429         <tr>
    430             <td class="header left">Expires: March 29, 2010</td>
     430            <td class="header left">Expires: March 30, 2010</td>
    431431            <td class="header right">HP</td>
    432432         </tr>
    … …  
    481481         <tr>
    482482            <td class="header left"></td>
    483             <td class="header right">September 25, 2009</td>
     483            <td class="header right">September 26, 2009</td>
    484484         </tr>
    485485      </table>
    … …  
    505505      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    506506      </p>
    507       <p>This Internet-Draft will expire in March 29, 2010.</p>
     507      <p>This Internet-Draft will expire in March 30, 2010.</p>
    508508      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    509509      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    858858      <div id="rfc.iref.h.1"></div>
    859859      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    860       <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>) for the requested variant. The headers used with entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> of this document, and in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
     860      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>) for the requested variant, which may be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
    861861      </p>
    862862      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span>  <a href="#header.etag" class="smpl">ETag</a>   = "ETag" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.etag" class="smpl">ETag-v</a>
    … …  
    879879      <div id="rfc.iref.h.2"></div>
    880880      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    881       <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used with a method to make it conditional. A client that has one or more entities previously
     881      <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used to make a request method conditional. A client that has one or more entities previously
    882882         obtained from the resource can verify that one of those entities is current by including a list of their associated entity
    883          tags in the If-Match header field. Entity tags are defined in <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead.
    884          It is also used, on updating requests, to prevent inadvertent modification of the wrong version of a resource. As a special
    885          case, the value "*" matches any current entity of the resource.
     883         tags in the If-Match header field.
     884      </p>
     885      <p id="rfc.section.6.2.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used when updating
     886         resources, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches
     887         any current entity of the resource.
    886888      </p>
    887889      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a>   = "If-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-match" class="smpl">If-Match-v</a>
    888890  <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    889 </pre><p id="rfc.section.6.2.p.3">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
     891</pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
    890892         request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
    891893         then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    892894      </p>
    893       <p id="rfc.section.6.2.p.4">If none of the entity tags match, or if "*" is given and no current entity 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,
     895      <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current entity 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,
    894896         such as PUT, from modifying a resource that has changed since the client last retrieved it.
    895897      </p>
    896       <p id="rfc.section.6.2.p.5">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match
     898      <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, then the If-Match
    897899         header <em class="bcp14">MUST</em> be ignored.
    898900      </p>
    899       <p id="rfc.section.6.2.p.6">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.
    900       </p>
    901       <p id="rfc.section.6.2.p.7">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.
     901      <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.
     902      </p>
     903      <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.
    902904         This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without
    903905         their knowledge. Examples:
    … …  
    906908  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    907909  If-Match: *
    908 </pre><p id="rfc.section.6.2.p.9">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields
     910</pre><p id="rfc.section.6.2.p.10">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields
    909911         is undefined by this specification.
    910912      </p>
    … …  
    912914      <div id="rfc.iref.h.3"></div>
    913915      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
    914       <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used with a method to make it conditional: if the requested variant has not
    915          been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (Not
    916          Modified) response will be returned without any message-body.
     916      <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used to make a request method conditional: if the requested variant has not
     917         been modified since the time specified in this field, the server will not return an entity; instead, a 304 (Not Modified)
     918         response will be returned.
    917919      </p>
    918920      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span>  <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>   = "If-Modified-Since" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    935937      <p id="rfc.section.6.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p>
    936938      <dl class="empty">
    937          <dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details.
     939         <dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details.
    938940         </dd>
    939941         <dd> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
    … …  
    959961      <div id="rfc.iref.h.4"></div>
    960962      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2>
    961       <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used with a method to make it conditional. A client that has one or more entities
     963      <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used to make a request method conditional. A client that has one or more entities
    962964         previously obtained from the resource can verify that none of those entities is current by including a list of their associated
    963          entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information
    964          with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying
    965          an existing resource when the client believes that the resource does not exist.
    966       </p>
    967       <p id="rfc.section.6.4.p.2">As a special case, the value "*" matches any current entity of the resource.</p>
     965         entity tags in the If-None-Match header field.
     966      </p>
     967      <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent
     968         a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not
     969         exist.
     970      </p>
     971      <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current entity of the resource.</p>
    968972      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a>   = "If-None-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-none-match" class="smpl">If-None-Match-v</a>
    969973  <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    970 </pre><p id="rfc.section.6.4.p.4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
     974</pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
    971975         request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
    972976         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
    … …  
    974978         that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed).
    975979      </p>
    976       <p id="rfc.section.6.4.p.5">If none of the entity tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
    977       </p>
    978       <p id="rfc.section.6.4.p.6">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the
     980      <p id="rfc.section.6.4.p.6">If none of the entity tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
     981      </p>
     982      <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, then the
    979983         If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    980984      </p>
    981       <p id="rfc.section.6.4.p.7">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.
    982       </p>
    983       <p id="rfc.section.6.4.p.8">Examples:</p>
     985      <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.
     986      </p>
     987      <p id="rfc.section.6.4.p.9">Examples:</p>
    984988      <div id="rfc.figure.u.11"></div><pre class="text">  If-None-Match: "xyzzy"
    985989  If-None-Match: W/"xyzzy"
    … …  
    987991  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
    988992  If-None-Match: *
    989 </pre><p id="rfc.section.6.4.p.10">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header
     993</pre><p id="rfc.section.6.4.p.11">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header
    990994         fields is undefined by this specification.
    991995      </p>
    … …  
    993997      <div id="rfc.iref.h.5"></div>
    994998      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    995       <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used with a method to make it conditional. If the requested resource has
     999      <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 requested resource has
    9961000         not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header were not present.
    9971001      </p>
    … …  
    10641068                  <td>http</td>
    10651069                  <td>standard</td>
    1066                   <td> <a href="#header.if-match" id="rfc.xref.header.if-match.3" title="If-Match">Section&nbsp;6.2</a>
     1070                  <td> <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">Section&nbsp;6.2</a>
    10671071                  </td>
    10681072               </tr>
    … …  
    10781082                  <td>http</td>
    10791083                  <td>standard</td>
    1080                   <td> <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">Section&nbsp;6.4</a>
     1084                  <td> <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">Section&nbsp;6.4</a>
    10811085                  </td>
    10821086               </tr>
    … …  
    11681172      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    11691173      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    1170       <p id="rfc.section.A.1.p.1">Allow weak entity tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.4" title="If-None-Match">6.4</a>).
     1174      <p id="rfc.section.A.1.p.1">Allow weak entity tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">6.4</a>).
    11711175      </p>
    11721176      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    13201324                     <ul class="ind">
    13211325                        <li class="indline1">ETag&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.etag.1">2</a>, <a class="iref" href="#rfc.iref.h.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.etag.2">7.1</a></li>
    1322                         <li class="indline1">If-Match&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc.xref.header.if-match.2">6.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.3">7.1</a></li>
     1326                        <li class="indline1">If-Match&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.2">7.1</a></li>
    13231327                        <li class="indline1">If-Modified-Since&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.if-modified-since.1">7.1</a></li>
    1324                         <li class="indline1">If-None-Match&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc.xref.header.if-none-match.2">6.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.4">A.1</a></li>
     1328                        <li class="indline1">If-None-Match&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.2">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">A.1</a></li>
    13251329                        <li class="indline1">If-Unmodified-Since&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.5"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.if-unmodified-since.1">7.1</a></li>
    13261330                        <li class="indline1">Last-Modified&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.6"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.last-modified.1">7.1</a></li>
    … …  
    13301334            </li>
    13311335            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
    1332                   <li class="indline1">If-Match header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc.xref.header.if-match.2">6.1</a>, <a class="iref" href="#rfc.iref.i.1"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.3">7.1</a></li>
     1336                  <li class="indline1">If-Match header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc.iref.i.1"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.2">7.1</a></li>
    13331337                  <li class="indline1">If-Modified-Since header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.2"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.if-modified-since.1">7.1</a></li>
    1334                   <li class="indline1">If-None-Match header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc.xref.header.if-none-match.2">6.1</a>, <a class="iref" href="#rfc.iref.i.3"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.4">A.1</a></li>
     1338                  <li class="indline1">If-None-Match header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc.iref.i.3"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.2">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">A.1</a></li>
    13351339                  <li class="indline1">If-Unmodified-Since header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.4"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.if-unmodified-since.1">7.1</a></li>
    13361340               </ul>
    … …  
    13491353                     </ul>
    13501354                  </li>
    1351                   <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2</a>, <a class="iref" href="#rfc.xref.Part5.2">4</a>, <a class="iref" href="#rfc.xref.Part5.3">4</a>, <a class="iref" href="#rfc.xref.Part5.4">6.1</a>, <a class="iref" href="#rfc.xref.Part5.5">6.3</a>, <a class="iref" href="#Part5"><b>10.1</b></a><ul class="ind">
    1352                         <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2</a>, <a class="iref" href="#rfc.xref.Part5.4">6.1</a></li>
    1353                         <li class="indline1"><em>Section 5.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.5">6.3</a></li>
     1355                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2</a>, <a class="iref" href="#rfc.xref.Part5.2">4</a>, <a class="iref" href="#rfc.xref.Part5.3">4</a>, <a class="iref" href="#rfc.xref.Part5.4">6.3</a>, <a class="iref" href="#Part5"><b>10.1</b></a><ul class="ind">
     1356                        <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2</a></li>
     1357                        <li class="indline1"><em>Section 5.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.4">6.3</a></li>
    13541358                     </ul>
    13551359                  </li>

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

    r697 r698  
    689689<t>
    690690   The "ETag" response-header field provides the current value of the
    691    entity tag (see <xref target="entity.tags"/>) for the requested variant.
    692    The headers used with entity
    693    tags are described in Sections <xref target="header.if-match" format="counter"/>
    694    and <xref target="header.if-none-match" format="counter"/> of this document,
    695    and in &header-if-range;. The entity tag
    696    &MAY; be used for comparison with other entities from the same resource
     691   entity tag (see <xref target="entity.tags"/>) for the requested variant,
     692   which may be used for comparison with other entities from the same resource
    697693   (see <xref target="weak.and.strong.validators"/>).
    698694</t>
    … …  
    734730  <x:anchor-alias value="If-Match-v"/>
    735731<t>
    736    The "If-Match" request-header field is used with a method to make it
     732   The "If-Match" request-header field is used to make a request method
    737733   conditional. A client that has one or more entities previously
    738734   obtained from the resource can verify that one of those entities is
    739735   current by including a list of their associated entity tags in the
    740    If-Match header field. Entity tags are defined in <xref target="entity.tags"/>. The
    741    purpose of this feature is to allow efficient updates of cached
    742    information with a minimum amount of transaction overhead. It is also
    743    used, on updating requests, to prevent inadvertent modification of
    744    the wrong version of a resource. As a special case, the value "*"
    745    matches any current entity of the resource.
     736   If-Match header field.
     737</t>
     738<t>
     739   This allows efficient updates of cached information with a minimum amount of
     740   transaction overhead. It is also used when updating resources, to prevent
     741   inadvertent modification of the wrong version of a resource. As a special
     742   case, the value "*" matches any current entity of the resource.
    746743</t>
    747744<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/><iref primary="true" item="Grammar" subitem="If-Match-v"/>
    … …  
    803800  <x:anchor-alias value="If-Modified-Since-v"/>
    804801<t>
    805    The "If-Modified-Since" request-header field is used with a method to
    806    make it conditional: if the requested variant has not been modified
    807    since the time specified in this field, an entity will not be
    808    returned from the server; instead, a 304 (Not Modified) response will
    809    be returned without any message-body.
     802   The "If-Modified-Since" request-header field is used to make a request
     803   method conditional: if the requested variant has not been modified since the
     804   time specified in this field, the server will not return an entity; instead,
     805   a 304 (Not Modified) response will be returned.
    810806</t>
    811807<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><iref primary="true" item="Grammar" subitem="If-Modified-Since-v"/>
    … …  
    888884  <x:anchor-alias value="If-None-Match-v"/>
    889885<t>
    890    The "If-None-Match" request-header field is used with a method to make
    891    it conditional. A client that has one or more entities previously
     886   The "If-None-Match" request-header field is used to make a request method
     887   conditional. A client that has one or more entities previously
    892888   obtained from the resource can verify that none of those entities is
    893889   current by including a list of their associated entity tags in the
    894    If-None-Match header field. The purpose of this feature is to allow
    895    efficient updates of cached information with a minimum amount of
     890   If-None-Match header field.
     891</t>
     892<t>
     893   This allows efficient updates of cached information with a minimum amount of
    896894   transaction overhead. It is also used to prevent a method (e.g. PUT)
    897895   from inadvertently modifying an existing resource when the client
    … …  
    965963  <x:anchor-alias value="If-Unmodified-Since-v"/>
    966964<t>
    967    The "If-Unmodified-Since" request-header field is used with a method to
    968    make it conditional. If the requested resource has not been modified
     965   The "If-Unmodified-Since" request-header field is used to make a request
     966   method conditional. If the requested resource has not been modified
    969967   since the time specified in this field, the server &SHOULD; perform the
    970968   requested operation as if the If-Unmodified-Since header were not

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

    r697 r698  
    396396      <meta name="DC.Creator" content="Reschke, J. F.">
    397397      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    398       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
     398      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
    399399      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    400400      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    428428         </tr>
    429429         <tr>
    430             <td class="header left">Expires: March 29, 2010</td>
     430            <td class="header left">Expires: March 30, 2010</td>
    431431            <td class="header right">HP</td>
    432432         </tr>
    … …  
    481481         <tr>
    482482            <td class="header left"></td>
    483             <td class="header right">September 25, 2009</td>
     483            <td class="header right">September 26, 2009</td>
    484484         </tr>
    485485      </table>
    … …  
    505505      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    506506      </p>
    507       <p>This Internet-Draft will expire in March 29, 2010.</p>
     507      <p>This Internet-Draft will expire in March 30, 2010.</p>
    508508      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    509509      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    694694      <div id="rfc.iref.h.1"></div>
    695695      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2>
    696       <p id="rfc.section.5.1.p.1">The "Accept-Ranges" response-header field allows the server to indicate its acceptance of range requests for a resource:</p>
     696      <p id="rfc.section.5.1.p.1">The "Accept-Ranges" response-header field allows a resource to indicate its acceptance of range requests.</p>
    697697      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a>     = "Accept-Ranges" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a>
    698698  <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a>   = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a>
    … …  
    864864      </ul>
    865865      <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a>&nbsp;<a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3>
    866       <p id="rfc.section.5.4.2.p.1">HTTP retrieval requests using conditional or unconditional GET methods <em class="bcp14">MAY</em> request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies
    867          to the entity returned as the result of the request:
     866      <p id="rfc.section.5.4.2.p.1">The "Range" request-header field defines the GET method (conditional or not) to request one or more sub-ranges of the response
     867         entity-body, instead of the entire entity body.
    868868      </p>
    869869      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#range.retrieval.requests" class="smpl">Range</a>   = "Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#range.retrieval.requests" class="smpl">Range-v</a>

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

    r697 r698  
    458458  <x:anchor-alias value="acceptable-ranges"/>
    459459<t>
    460    The "Accept-Ranges" response-header field allows the server to
    461    indicate its acceptance of range requests for a resource:
     460   The "Accept-Ranges" response-header field allows a resource to indicate
     461   its acceptance of range requests.
    462462</t>
    463463<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="Accept-Ranges-v"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
    … …  
    807807  <x:anchor-alias value="other-range-set"/>
    808808<t>
    809    HTTP retrieval requests using conditional or unconditional GET
    810    methods &MAY; request one or more sub-ranges of the entity, instead of
    811    the entire entity, using the Range request header, which applies to
    812    the entity returned as the result of the request:
     809   The "Range" request-header field defines the GET method (conditional or
     810   not) to request one or more sub-ranges of the response entity-body, instead
     811   of the entire entity body.
    813812</t>
    814813<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>

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

    r697 r698  
    398398      <meta name="DC.Creator" content="Reschke, J. F.">
    399399      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    400       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
     400      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
    401401      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    402402      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    430430         </tr>
    431431         <tr>
    432             <td class="header left">Expires: March 29, 2010</td>
     432            <td class="header left">Expires: March 30, 2010</td>
    433433            <td class="header right">HP</td>
    434434         </tr>
    … …  
    487487         <tr>
    488488            <td class="header left"></td>
    489             <td class="header right">September 25, 2009</td>
     489            <td class="header right">September 26, 2009</td>
    490490         </tr>
    491491      </table>
    … …  
    511511      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    512512      </p>
    513       <p>This Internet-Draft will expire in March 29, 2010.</p>
     513      <p>This Internet-Draft will expire in March 30, 2010.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    974974      <div id="rfc.iref.h.2"></div>
    975975      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
    976       <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response (or its validation)
    977          was generated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
     976      <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response was generated or successfully
     977         validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    978978      </p>
    979979      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#header.age" class="smpl">Age</a>   = "Age" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.age" class="smpl">Age-v</a>
    … …  
    992992      <div id="rfc.iref.h.3"></div>
    993993      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
    994       <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
    995          adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive
    996          in a request does not imply that the same directive is to be given in the response.
     994      <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. Such cache directives are unidirectional in that the presence of
     995         a directive in a request does not imply that the same directive is to be given in the response.
    997996      </p>
    998997      <div class="note">
    … …  
    12371236      <div id="rfc.iref.h.6"></div>
    12381237      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
    1239       <p id="rfc.section.3.5.p.1">The "Vary" response-header field's value indicates the set of request-header fields that determines, while the response is
    1240          fresh, whether a cache is permitted to use the response to reply to a subsequent request without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>.
    1241       </p>
    1242       <p id="rfc.section.3.5.p.2">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
     1238      <p id="rfc.section.3.5.p.1">The "Vary" response-header field conveys the set of request-header fields that were used to select the representation.</p>
     1239      <p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisdy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request
     1240         without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>.
     1241      </p>
     1242      <p id="rfc.section.3.5.p.3">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
    12431243         the representation.
    12441244      </p>
    12451245      <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>
    12461246  <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
    1247 </pre><p id="rfc.section.3.5.p.4">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>
    1248       <p id="rfc.section.3.5.p.5">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
     1247</pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>
     1248      <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
    12491249         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
    12501250         resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide
    12511251         the user agent with useful information about the dimensions over which the response varies at the time of the response.
    12521252      </p>
    1253       <p id="rfc.section.3.5.p.6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
     1253      <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address
    12541254         of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
    12551255         response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server; it may only be generated by an origin server.
    12561256      </p>
    1257       <p id="rfc.section.3.5.p.7">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
     1257      <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
    12581258         are case-insensitive.
    12591259      </p>

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

    r697 r698  
    895895  <x:anchor-alias value="age-value"/>
    896896<t>
    897   The "Age" response-header field conveys the sender's estimate of the amount of time since
    898   the response (or its validation) was generated at the origin server. Age values are
    899   calculated as specified in <xref target="age.calculations" />.
     897  The "Age" response-header field conveys the sender's estimate of the amount
     898  of time since the response was generated or successfully validated at the
     899  origin server. Age values are calculated as specified in
     900  <xref target="age.calculations" />.
    900901</t>
    901902<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/><iref primary="true" item="Grammar" subitem="Age-v"/>
    … …  
    933934  <x:anchor-alias value="cache-response-directive"/>
    934935<t>
    935   The "Cache-Control" general-header field is used to specify directives that &MUST; be
    936   obeyed by all caches along the request/response chain. The directives specify behavior
    937   intended to prevent caches from adversely interfering with the request or response. Cache
    938   directives are unidirectional in that the presence of a directive in a request does not
    939   imply that the same directive is to be given in the response.
     936  The "Cache-Control" general-header field is used to specify directives that
     937  &MUST; be obeyed by all caches along the request/response chain. Such cache
     938  directives are unidirectional in that the presence of a directive in a
     939  request does not imply that the same directive is to be given in the
     940  response.
    940941</t>
    941942<x:note>
    … …  
    13321333  <x:anchor-alias value="Vary-v"/>
    13331334<t>
    1334   The "Vary" response-header field's value indicates the set of request-header fields that
     1335  The "Vary" response-header field conveys the set of request-header fields
     1336  that were used to select the representation.
     1337</t>
     1338<t>
     1339  Caches use this information, in part, to determine whether a stored response
     1340  can be used to satisdy a given request; see
     1341  <xref target="caching.negotiated.responses" />.
    13351342  determines, while the response is fresh, whether a cache is permitted to use the
    13361343  response to reply to a subsequent request without validation; see <xref

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

    r697 r698  
    390390      <meta name="DC.Creator" content="Reschke, J. F.">
    391391      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    392       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
     392      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26">
    393393      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    394394      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    427427         </tr>
    428428         <tr>
    429             <td class="header left">Expires: March 29, 2010</td>
     429            <td class="header left">Expires: March 30, 2010</td>
    430430            <td class="header right">H. Frystyk</td>
    431431         </tr>
    … …  
    476476         <tr>
    477477            <td class="header left"></td>
    478             <td class="header right">September 25, 2009</td>
     478            <td class="header right">September 26, 2009</td>
    479479         </tr>
    480480      </table>
    … …  
    500500      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    501501      </p>
    502       <p>This Internet-Draft will expire in March 29, 2010.</p>
     502      <p>This Internet-Draft will expire in March 30, 2010.</p>
    503503      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    504504      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    627627      <div id="rfc.iref.h.1"></div>
    628628      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
    629       <p id="rfc.section.3.1.p.1">A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--does
    630          so by including an "Authorization" request-header field with the request. The field value consists of credentials containing
    631          the authentication information of the user agent for the realm of the resource being requested.
     629      <p id="rfc.section.3.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server -- usually, but not necessary,
     630         after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent
     631         for the realm of the resource being requested.
    632632      </p>
    633633      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span>  <a href="#header.authorization" class="smpl">Authorization</a>   = "Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.authorization" class="smpl">Authorization-v</a>
    … …  
    652652      <div id="rfc.iref.h.2"></div>
    653653      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    654       <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates
    655          the authentication scheme and parameters applicable to the proxy for this request-target.
     654      <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters
     655         applicable to the proxy for this request-target. It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
    656656      </p>
    657657      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a>   = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    666666      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2>
    667667      <p id="rfc.section.3.3.p.1">The "Proxy-Authorization" request-header field allows the client to identify itself (or its user) to a proxy which requires
    668          authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the
    669          user agent for the proxy and/or realm of the resource being requested.
     668         authentication. Its value consists of credentials containing the authentication information of the user agent for the proxy
     669         and/or realm of the resource being requested.
    670670      </p>
    671671      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a>   = "Proxy-Authorization" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    680680      <div id="rfc.iref.h.4"></div>
    681681      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
    682       <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the
    683          authentication scheme(s) and parameters applicable to the request-target.
     682      <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s)
     683         and parameters applicable to the request-target. It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
    684684      </p>
    685685      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>   = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a>

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

    r697 r698  
    342342  <x:anchor-alias value="Authorization-v"/>
    343343<t>
    344    A user agent that wishes to authenticate itself with a server--
    345    usually, but not necessarily, after receiving a 401 response--does
    346    so by including an "Authorization" request-header field with the
    347    request.  The field value consists of credentials
    348    containing the authentication information of the user agent for
    349    the realm of the resource being requested.
     344   The "Authorization" request-header field allows a user agent to authenticate
     345   itself with a server -- usually, but not necessary, after receiving a 401
     346   (Unauthorized) response. Its value consists of credentials containing
     347   information of the user agent for the realm of the resource being
     348   requested.
    350349</t>
    351350<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/><iref primary="true" item="Grammar" subitem="Authorization-v"/>
    … …  
    354353</artwork></figure>
    355354<t>
    356       HTTP access authentication is described in "HTTP Authentication:
    357       Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is
    358       authenticated and a realm specified, the same credentials &SHOULD;
    359       be valid for all other requests within this realm (assuming that
    360       the authentication scheme itself does not require otherwise, such
    361       as credentials that vary according to a challenge value or using
    362       synchronized clocks).
     355   HTTP access authentication is described in "HTTP Authentication:
     356   Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is
     357   authenticated and a realm specified, the same credentials &SHOULD;
     358   be valid for all other requests within this realm (assuming that
     359   the authentication scheme itself does not require otherwise, such
     360   as credentials that vary according to a challenge value or using
     361   synchronized clocks).
    363362</t>
    364363<t>
    … …  
    399398  <x:anchor-alias value="Proxy-Authenticate-v"/>
    400399<t>
    401    The "Proxy-Authenticate" response-header field &MUST; be included as part
    402    of a 407 (Proxy Authentication Required) response. The field value
    403    consists of a challenge that indicates the authentication scheme and
    404    parameters applicable to the proxy for this request-target.
     400   The "Proxy-Authenticate" response-header field consists of a challenge that
     401   indicates the authentication scheme and parameters applicable to the proxy
     402   for this request-target. It &MUST; be included as part
     403   of a 407 (Proxy Authentication Required) response.
    405404</t>
    406405<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><iref primary="true" item="Grammar" subitem="Proxy-Authenticate-v"/>
    … …  
    429428   The "Proxy-Authorization" request-header field allows the client to
    430429   identify itself (or its user) to a proxy which requires
    431    authentication. The Proxy-Authorization field value consists of
     430   authentication. Its value consists of
    432431   credentials containing the authentication information of the user
    433432   agent for the proxy and/or realm of the resource being requested.
    … …  
    458457  <x:anchor-alias value="WWW-Authenticate-v"/>
    459458<t>
    460    The "WWW-Authenticate" response-header field &MUST; be included in 401
    461    (Unauthorized) response messages. The field value consists of at
    462    least one challenge that indicates the authentication scheme(s) and
    463    parameters applicable to the request-target.
     459   The "WWW-Authenticate" response-header field consists of at least one
     460   challenge that indicates the authentication scheme(s) and parameters
     461   applicable to the request-target. It &MUST; be included in 401
     462   (Unauthorized) response messages.
    464463</t>
    465464<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><iref primary="true" item="Grammar" subitem="WWW-Authenticate-v"/>
Note: See TracChangeset for help on using the changeset viewer.