Changeset 1164 for draft-ietf-httpbis


Ignore:
Timestamp:
11/03/11 06:45:43 (10 years ago)
Author:
fielding@…
Message:

update generated HTML

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

Legend:

Unmodified
Added
Removed

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

    r1162 r1164  
    546546                     <li>1.2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">ABNF Extension: #rule</a></li>
    547547                     <li>1.2.2&nbsp;&nbsp;&nbsp;<a href="#basic.rules">Basic Rules</a></li>
    548                      <li>1.2.3&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>
    549548                  </ul>
    550549               </li>
    … …  
    863862</pre><p id="rfc.section.1.2.2.p.14">Producers <em class="bcp14">SHOULD NOT</em> escape characters that do not require escaping (i.e., other than DQUOTE and the backslash character).
    864863      </p>
    865       <h3 id="rfc.section.1.2.3"><a href="#rfc.section.1.2.3">1.2.3</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    866       <p id="rfc.section.1.2.3.p.1">The ABNF rules below are defined in other parts:</p>
    867       <div id="rfc.figure.u.12"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">request-header</a>  = &lt;request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>&gt;
    868   <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>&gt;
    869 </pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>&gt;
    870 </pre><div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    871   <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    872   <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>&gt;
    873 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP-related architecture</a></h1>
     864      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP-related architecture</a></h1>
    874865      <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide
    875866         hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP.
    … …  
    898889         the origin server (O).
    899890      </p>
    900       <div id="rfc.figure.u.15"></div><pre class="drawing">         request   &gt;
     891      <div id="rfc.figure.u.12"></div><pre class="drawing">         request   &gt;
    901892    UA ======================================= O
    902893                                &lt;   response
    … …  
    913904      </p>
    914905      <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
    915       <div id="rfc.figure.u.16"></div>
     906      <div id="rfc.figure.u.13"></div>
    916907      <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
    917908User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
    … …  
    919910Accept: */*
    920911
    921 </pre><div id="rfc.figure.u.17"></div>
     912</pre><div id="rfc.figure.u.14"></div>
    922913      <p>server response:</p><pre class="text">HTTP/1.1 200 OK
    923914Date: Mon, 27 Jul 2009 12:28:53 GMT
    … …  
    948939         gateway, or tunnel, switching behavior based on the nature of each request.
    949940      </p>
    950       <div id="rfc.figure.u.18"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
     941      <div id="rfc.figure.u.15"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
    951942    UA =========== A =========== B =========== C =========== O
    952943               &lt;             &lt;             &lt;             &lt;
    … …  
    1007998         from O (via C) for a request which has not been cached by UA or A.
    1008999      </p>
    1009       <div id="rfc.figure.u.19"></div><pre class="drawing">            &gt;             &gt;
     1000      <div id="rfc.figure.u.16"></div><pre class="drawing">            &gt;             &gt;
    10101001       UA =========== A =========== B - - - - - - C - - - - - - O
    10111002                  &lt;             &lt;
    … …  
    10131004         Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when
    10141005         that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are
    1015          defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1006         defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    10161007      </p>
    10171008      <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
    … …  
    10261017      </p>
    10271018      <p id="rfc.section.2.5.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
    1028       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>
     1019      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#http.version" class="smpl">HTTP-Version</a>   = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>
    10291020  <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive
    10301021</pre><p id="rfc.section.2.5.p.4">The HTTP version number consists of two non-negative decimal integers separated by the "." (period or decimal point) character.
    … …  
    10891080         "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI without a fragment.
    10901081      </p>
    1091       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
     1082      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
    10921083  <a href="#uri" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>&gt;
    10931084  <a href="#uri" class="smpl">relative-part</a> = &lt;relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>&gt;
    … …  
    11131104         data corresponding to a resource for which that server might provide an HTTP interface.
    11141105      </p>
    1115       <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     1106      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    11161107</pre><p id="rfc.section.2.6.1.p.3">The host identifier within an <a href="#uri" class="smpl">authority</a> component is defined in <a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>. If host is provided as an IP literal or IPv4 address, then the HTTP server is any listener on the indicated TCP port at
    11171108         that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might
    … …  
    11491140         TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacy through the use of strong encryption prior to sending the first HTTP request.
    11501141      </p>
    1151       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     1142      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    11521143</pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus are ineligible for shared caching.
    1153          Their default is "private" and might be further constrained via use of the Cache-Control header field.
     1144         Their default is "private" and might be further constrained via use of the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    11541145      </p>
    11551146      <p id="rfc.section.2.6.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
    … …  
    11701161      </p>
    11711162      <p id="rfc.section.2.6.3.p.3">For example, the following three URIs are equivalent:</p>
    1172       <div id="rfc.figure.u.24"></div><pre class="text">   http://example.com:80/~smith/home.html
     1163      <div id="rfc.figure.u.21"></div><pre class="text">   http://example.com:80/~smith/home.html
    11731164   http://EXAMPLE.com/%7Esmith/home.html
    11741165   http://EXAMPLE.com:/%7esmith/home.html
    … …  
    11901181         or invalid request method) and clients are implemented to only expect a response.
    11911182      </p>
    1192       <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.36"></span>  <a href="#http.message" class="smpl">HTTP-message</a>    = <a href="#http.message" class="smpl">start-line</a>
     1183      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.36"></span>  <a href="#http.message" class="smpl">HTTP-message</a>    = <a href="#http.message" class="smpl">start-line</a>
    11931184                    *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
    11941185                    <a href="#core.rules" class="smpl">CRLF</a>
    … …  
    12211212         value.
    12221213      </p>
    1223       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> [ <a href="#header.fields" class="smpl">field-value</a> ] <a href="#rule.whitespace" class="smpl">OWS</a>
     1214      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> [ <a href="#header.fields" class="smpl">field-value</a> ] <a href="#rule.whitespace" class="smpl">OWS</a>
    12241215  <a href="#header.fields" class="smpl">field-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
    12251216  <a href="#header.fields" class="smpl">field-value</a>    = *( <a href="#header.fields" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> )
    … …  
    12611252         </p>
    12621253      </div>
    1263       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
     1254      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
    12641255  <a href="#rule.comment" class="smpl">ctext</a>          = <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    12651256                 ; <a href="#rule.whitespace" class="smpl">OWS</a> / &lt;<a href="#core.rules" class="smpl">VCHAR</a> except "(", ")", and "\"&gt; / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    … …  
    12671258         <p id="rfc.section.3.2.p.12">  The backslash character ("\") can be used as a single-character quoting mechanism within comment constructs:</p>
    12681259      </div>
    1269       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a>    = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
     1260      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a>    = "\" ( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12701261</pre><p id="rfc.section.3.2.p.14">Producers <em class="bcp14">SHOULD NOT</em> escape characters that do not require escaping (i.e., other than the backslash character "\" and the parentheses "(" and ")").
    12711262      </p>
    12721263      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
    12731264      <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p>
    1274       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
     1265      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
    12751266</pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
    12761267         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;9.7</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
    … …  
    13561347      <p id="rfc.section.3.3.p.15">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected
    13571348         number of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an
    1358          error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1349         error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    13591350      </p>
    13601351      <p id="rfc.section.3.3.p.16">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data
    … …  
    13841375               </tr>
    13851376               <tr>
    1386                   <td class="left">Pragma</td>
    1387                   <td class="left"><a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
    1388                </tr>
    1389                <tr>
    13901377                  <td class="left">Trailer</td>
    13911378                  <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;9.6</a></td>
    … …  
    14031390                  <td class="left"><a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a></td>
    14041391               </tr>
    1405                <tr>
    1406                   <td class="left">Warning</td>
    1407                   <td class="left"><a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
    1408                </tr>
    1409                <tr>
    1410                   <td class="left">MIME-Version</td>
    1411                   <td class="left"><a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>
    1412                </tr>
    14131392            </tbody>
    14141393         </table>
    14151394      </div>
    1416       <p id="rfc.section.3.4.p.2">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    1417          or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize
    1418          them to be general-header fields.
    1419       </p>
    14201395      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="request" href="#request">Request</a></h1>
    14211396      <p id="rfc.section.4.p.1">A request message from a client to a server includes, within the first line of that message, the method to be applied to the
    14221397         resource, the identifier of the resource, and the protocol version in use.
    14231398      </p>
    1424       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;4.1</a>
     1399      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;4.1</a>
    14251400                  *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
    14261401                  <a href="#core.rules" class="smpl">CRLF</a>
    … …  
    14301405         The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
    14311406      </p>
    1432       <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
     1407      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request-line" class="smpl">Request-Line</a>   = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>
    14331408</pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h3>
    14341409      <p id="rfc.section.4.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    1435       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
     1410      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    14361411</pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
    14371412      <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request.</p>
    1438       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.48"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
     1413      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span>  <a href="#request-target" class="smpl">request-target</a> = "*"
    14391414                 / <a href="#uri" class="smpl">absolute-URI</a>
    14401415                 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
    … …  
    14441419         This is only allowed for the OPTIONS request method. Thus, the only valid example is
    14451420      </p>
    1446       <div id="rfc.figure.u.34"></div><pre class="text2">OPTIONS * HTTP/1.1
     1421      <div id="rfc.figure.u.31"></div><pre class="text2">OPTIONS * HTTP/1.1
    14471422</pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.2"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
    14481423         and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
    … …  
    14501425         Request-Line would be:
    14511426      </p>
    1452       <div id="rfc.figure.u.35"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     1427      <div id="rfc.figure.u.32"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    14531428</pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    14541429      </p>
    1455       <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1430      <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.3"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    14561431      </p>
    14571432      <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.p.2"></span> The most common form of request-target is that used to identify a resource on an origin server or gateway ("path-absolute
    … …  
    14591434         server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
    14601435      </p>
    1461       <div id="rfc.figure.u.36"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
     1436      <div id="rfc.figure.u.33"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
    14621437Host: www.example.org
    14631438</pre><p id="rfc.section.4.1.2.p.12">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
    … …  
    14661441      <p id="rfc.section.4.1.2.p.13">If a proxy receives an OPTIONS request without any path in the request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
    14671442      </p>
    1468       <div id="rfc.figure.u.37"></div>
     1443      <div id="rfc.figure.u.34"></div>
    14691444      <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
    1470 </pre><div id="rfc.figure.u.38"></div>
     1445</pre><div id="rfc.figure.u.35"></div>
    14711446      <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
    14721447Host: www.example.org:8001
    … …  
    14841459      </div>
    14851460      <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
    1486          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1461         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    14871462      </p>
    14881463      <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets.
    … …  
    15381513      </p>
    15391514      <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
    1540       <div id="rfc.figure.u.39"></div>
     1515      <div id="rfc.figure.u.36"></div>
    15411516      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    15421517Host: www.example.org:8080
    … …  
    15441519         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
    15451520      </p>
    1546       <div id="rfc.figure.u.40"></div>
     1521      <div id="rfc.figure.u.37"></div>
    15471522      <p>Example 2: the effective request URI for the message</p>  <pre class="text">GET * HTTP/1.1
    15481523Host: www.example.org
    … …  
    15541529      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
    15551530      <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
    1556       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.49"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;5.1</a>
     1531      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.49"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;5.1</a>
    15571532                  *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
    15581533                  <a href="#core.rules" class="smpl">CRLF</a>
    … …  
    15631538         CRLF sequence.
    15641539      </p>
    1565       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
     1540      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    15661541</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    15671542      <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
    1568          are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
     1543         are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
    15691544         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    15701545         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
    … …  
    15801555         <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
    15811556      </ul>
    1582       <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
     1557      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    15831558  <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a>  = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    15841559</pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    … …  
    15871562         a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
    15881563      </p>
    1589       <div id="rfc.figure.u.44"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
     1564      <div id="rfc.figure.u.41"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
    15901565</pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
    1591       <div id="rfc.figure.u.45"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
     1566      <div id="rfc.figure.u.42"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    15921567Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    15931568</pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for further information.
    … …  
    15971572         time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar.
    15981573      </p>
    1599       <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
     1574      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
    16001575</pre><div id="preferred.date.format">
    16011576         <p id="rfc.section.6.1.p.8">                    Preferred format:</p>
    16021577      </div>
    1603       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
     1578      <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    16041579  ; fixed length subset of the format defined in
    16051580  ; <a href="http://tools.ietf.org/html/rfc1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>
    … …  
    16441619         <p id="rfc.section.6.1.p.11">                Obsolete formats:</p>
    16451620      </div>
    1646       <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.66"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>
    1647 </pre><div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
     1621      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.66"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>
     1622</pre><div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    16481623  <a href="#obsolete.date.formats" class="smpl">date2</a>        = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a>
    16491624                 ; day-month-year (e.g., 02-Jun-82)
    … …  
    16561631         / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
    16571632         / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
    1658 </pre><div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.68"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
     1633</pre><div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.68"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
    16591634  <a href="#obsolete.date.formats" class="smpl">date3</a>        = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> ))
    16601635                 ; month day (e.g., Jun  2)
    … …  
    16741649         transfer-coding is a property of the message rather than a property of the representation that is being transferred.
    16751650      </p>
    1676       <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>
     1651      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>
    16771652                          / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;6.2.2.1</a>
    16781653                          / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;6.2.2.2</a>
    … …  
    16831658         <p id="rfc.section.6.2.p.3">      Parameters are in the form of attribute/value pairs.</p>
    16841659      </div>
    1685       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
     1660      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
    16861661  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    16871662  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
    … …  
    17011676         for the recipient to verify that it has received the full message.
    17021677      </p>
    1703       <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     1678      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    17041679                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    17051680                   <a href="#chunked.encoding" class="smpl">trailer-part</a>
    … …  
    17451720      </p>
    17461721      <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    1747       <div id="rfc.figure.u.54"></div><pre class="text">  length := 0
     1722      <div id="rfc.figure.u.51"></div><pre class="text">  length := 0
    17481723  read chunk-size, chunk-ext (if any) and CRLF
    17491724  while (chunk-size &gt; 0) {
    … …  
    18061781         <li>Pointer to specification text</li>
    18071782      </ul>
    1808       <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
     1783      <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
    18091784      </p>
    18101785      <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
    … …  
    18171792         By convention, the products are listed in order of their significance for identifying the application.
    18181793      </p>
    1819       <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
     1794      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]
    18201795  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    18211796</pre><p id="rfc.section.6.3.p.3">Examples:</p>
    1822       <div id="rfc.figure.u.56"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     1797      <div id="rfc.figure.u.53"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    18231798  Server: Apache/0.8.4
    18241799</pre><p id="rfc.section.6.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
    18251800      </p>
    18261801      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1827       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1802      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    18281803         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    18291804         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    18301805      </p>
    1831       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.90"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
     1806      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.90"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    18321807                 / ( "1" [ "." 0*3("0") ] )
    18331808</pre><div class="note" id="rfc.section.6.4.p.3">
    … …  
    18891864      <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    18901865      </p>
    1891       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     1866      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    18921867         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    18931868      </p>
    … …  
    19501925         <li>Content-Type</li>
    19511926      </ul>
    1952       <p id="rfc.section.7.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1927      <p id="rfc.section.7.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    19531928      </p>
    19541929      <div class="note" id="rfc.section.7.1.3.2.p.7">
    … …  
    19571932         </p>
    19581933      </div>
    1959       <p id="rfc.section.7.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
     1934      <p id="rfc.section.7.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    19601935      </p>
    19611936      <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    … …  
    19731948      </p>
    19741949      <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    1975          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     1950         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    19761951         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    19771952      </p>
    … …  
    20001975      </p>
    20011976      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2002       <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     1977      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    20031978         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    20041979         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    20071982      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    20081983      <ul>
    2009          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2010          </li>
    2011          <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     1984         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     1985         </li>
     1986         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    20121987         </li>
    20131988      </ul>
    … …  
    20191994      <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    20201995      <ul>
    2021          <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
     1996         <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
    20221997            code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    20231998         </li>
    2024          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue"
    2025             expectation, and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this
    2026             rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
    2027             field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays
    2028             associated with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests
    2029             with any other HTTP-version value.
     1999         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect header field with the "100-continue" expectation,
     2000            and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this
     2001            rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field
     2002            with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated
     2003            with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other
     2004            HTTP-version value.
    20302005         </li>
    20312006         <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request.
    … …  
    20342009            prematurely.
    20352010         </li>
    2036          <li>If an origin server receives a request that does not include an Expect request-header field with the "100-continue" expectation,
    2037             the request includes a request body, and the server responds with a final status code before reading the entire request body
    2038             from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
     2011         <li>If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the
     2012            request includes a request body, and the server responds with a final status code before reading the entire request body from
     2013            the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
    20392014            the client might not reliably receive the response message. However, this requirement is not be construed as preventing a
    20402015            server from defending itself against denial-of-service attacks, or from badly broken client implementations.
    … …  
    20432018      <p id="rfc.section.7.2.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    20442019      <ul>
    2045          <li>If a proxy receives a request that includes an Expect request-header field with the "100-continue" expectation, and the proxy
    2046             either knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop
    2047             server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
     2020         <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either
     2021            knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server,
     2022            it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
    20482023         </li>
    20492024         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code.
    … …  
    20522027         </li>
    20532028         <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    2054             an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding
    2055             of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2029            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
     2030            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    20562031         </li>
    20572032      </ul>
    20582033      <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a>&nbsp;<a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
    2059       <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field
    2060          with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the
    2061          client sees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
     2034      <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect header field with
     2035         the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client
     2036         sees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
    20622037      </p>
    20632038      <ol>
    20642039         <li>Initiate a new connection to the server</li>
    2065          <li>Transmit the request-header fields</li>
     2040         <li>Transmit the request-line, header fields, and the CRLF that indicates the end of header fields.</li>
    20662041         <li>Initialize a variable R to the estimated round-trip time to the server (e.g., based on the time it took to establish the connection),
    20672042            or to a constant value of 5 seconds if the round-trip time is not available.
    … …  
    21022077      <div id="rfc.iref.h.6"></div>
    21032078      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    2104       <p id="rfc.section.9.1.p.1">The "Connection" general-header field allows the sender to specify options that are desired for that particular connection
    2105          and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
     2079      <p id="rfc.section.9.1.p.1">The "Connection" header field allows the sender to specify options that are desired for that particular connection and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
    21062080      </p>
    21072081      <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p>
    2108       <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.connection" class="smpl">Connection</a>       = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>
     2082      <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.connection" class="smpl">Connection</a>       = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>
    21092083  <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
    21102084  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    … …  
    21142088         header field might not be sent if there are no parameters associated with that connection option.
    21152089      </p>
    2116       <p id="rfc.section.9.1.p.5">Message header fields listed in the Connection header field <em class="bcp14">MUST NOT</em> include end-to-end header fields, such as Cache-Control.
     2090      <p id="rfc.section.9.1.p.5">Message header fields listed in the Connection header field <em class="bcp14">MUST NOT</em> include end-to-end header fields, such as Cache-Control (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    21172091      </p>
    21182092      <p id="rfc.section.9.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
    21192093         of the response. For example,
    21202094      </p>
    2121       <div id="rfc.figure.u.59"></div><pre class="text">  Connection: close
     2095      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
    21222096</pre><p id="rfc.section.9.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>) after the current request/response is complete.
    21232097      </p>
    … …  
    21382112         body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
    21392113      </p>
    2140       <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></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>
     2114      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></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>
    21412115  <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    21422116</pre><p id="rfc.section.9.2.p.3">An example is</p>
    2143       <div id="rfc.figure.u.61"></div><pre class="text">  Content-Length: 3495
     2117      <div id="rfc.figure.u.58"></div><pre class="text">  Content-Length: 3495
    21442118</pre><p id="rfc.section.9.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
    21452119         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
    … …  
    21522126      <div id="rfc.iref.h.8"></div>
    21532127      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    2154       <p id="rfc.section.9.3.p.1">The "Date" general-header field represents the date and time at which the message was originated, having the same semantics
    2155          as the Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    2156       </p>
    2157       <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span>  <a href="#header.date" class="smpl">Date</a>   = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>
     2128      <p id="rfc.section.9.3.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
     2129         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     2130      </p>
     2131      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span>  <a href="#header.date" class="smpl">Date</a>   = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>
    21582132  <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>
    21592133</pre><p id="rfc.section.9.3.p.3">An example is</p>
    2160       <div id="rfc.figure.u.63"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
     2134      <div id="rfc.figure.u.60"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    21612135</pre><p id="rfc.section.9.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    21622136      </p>
    … …  
    21892163      <div id="rfc.iref.h.10"></div>
    21902164      <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>
    2191       <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
    2192          origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple
    2193          host names on a single IP address.
     2165      <p id="rfc.section.9.4.p.1">The "Host" header field specifies the Internet host and port number of the resource being requested, allowing the origin server
     2166         or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names
     2167         on a single IP address.
    21942168      </p>
    21952169      <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
    21962170         resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>).
    21972171      </p>
    2198       <div id="rfc.figure.u.64"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></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>
     2172      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></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>
    21992173  <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>
    22002174</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
    22012175         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
    22022176      </p>
    2203       <div id="rfc.figure.u.65"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
     2177      <div id="rfc.figure.u.62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    22042178Host: www.example.org
    22052179</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
    … …  
    22122186      <div id="rfc.iref.h.11"></div>
    22132187      <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>
    2214       <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
    2215          or not it is willing to accept trailer fields in a chunked transfer-coding.
     2188      <p id="rfc.section.9.5.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not
     2189         it is willing to accept trailer fields in a chunked transfer-coding.
    22162190      </p>
    22172191      <p id="rfc.section.9.5.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    22182192         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    22192193      </p>
    2220       <div id="rfc.figure.u.66"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></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>
     2194      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></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>
    22212195  <a href="#header.te" class="smpl">TE-v</a>      = #<a href="#header.te" class="smpl">t-codings</a>
    22222196  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] )
    … …  
    22272201      </p>
    22282202      <p id="rfc.section.9.5.p.5">Examples of its use are:</p>
    2229       <div id="rfc.figure.u.67"></div><pre class="text">  TE: deflate
     2203      <div id="rfc.figure.u.64"></div><pre class="text">  TE: deflate
    22302204  TE:
    22312205  TE: trailers, deflate;q=0.5
    … …  
    22612235      <div id="rfc.iref.h.12"></div>
    22622236      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
    2263       <p id="rfc.section.9.6.p.1">The "Trailer" general-header field indicates that the given set of header fields is present in the trailer of a message encoded
    2264          with chunked transfer-coding.
    2265       </p>
    2266       <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span>  <a href="#header.trailer" class="smpl">Trailer</a>   = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>
     2237      <p id="rfc.section.9.6.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
     2238         chunked transfer-coding.
     2239      </p>
     2240      <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span>  <a href="#header.trailer" class="smpl">Trailer</a>   = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>
    22672241  <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    22682242</pre><p id="rfc.section.9.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
    … …  
    22812255      <div id="rfc.iref.h.13"></div>
    22822256      <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>
    2283       <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.
    2284          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.7"><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
     2257      <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
     2258         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.5"><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
    22852259         are not.
    22862260      </p>
    2287       <div id="rfc.figure.u.69"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>
     2261      <div id="rfc.figure.u.66"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>
    22882262                        <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a>
    22892263  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    22902264</pre><p id="rfc.section.9.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>. An example is:
    22912265      </p>
    2292       <div id="rfc.figure.u.70"></div><pre class="text">  Transfer-Encoding: chunked
     2266      <div id="rfc.figure.u.67"></div><pre class="text">  Transfer-Encoding: chunked
    22932267</pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    22942268      </p>
    … …  
    22972271      <div id="rfc.iref.h.14"></div>
    22982272      <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>
    2299       <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,
    2300          if the server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    2301       </p>
    2302       <div id="rfc.figure.u.71"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></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>
     2273      <p id="rfc.section.9.8.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
     2274         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
     2275      </p>
     2276      <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.109"></span><span id="rfc.iref.g.110"></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>
    23032277  <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a>
    23042278</pre><p id="rfc.section.9.8.p.3">For example,</p>
    2305       <div id="rfc.figure.u.72"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     2279      <div id="rfc.figure.u.69"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    23062280</pre><p id="rfc.section.9.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
    23072281         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    … …  
    23192293      </p>
    23202294      <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2321          is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2295         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    23222296      </p>
    23232297      <p id="rfc.section.9.8.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    … …  
    23532327      <div id="rfc.iref.h.15"></div>
    23542328      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    2355       <p id="rfc.section.9.9.p.1">The "Via" general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
     2329      <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
    23562330         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
    23572331         of all senders along the request/response chain.
    23582332      </p>
    2359       <div id="rfc.figure.u.73"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span>  <a href="#header.via" class="smpl">Via</a>               = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>
     2333      <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.111"></span><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span>  <a href="#header.via" class="smpl">Via</a>               = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>
    23602334  <a href="#header.via" class="smpl">Via-v</a>             = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a>
    23612335                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    … …  
    23822356         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    23832357      </p>
    2384       <div id="rfc.figure.u.74"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2358      <div id="rfc.figure.u.71"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    23852359</pre><p id="rfc.section.9.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    23862360      </p>
    … …  
    23882362         For example,
    23892363      </p>
    2390       <div id="rfc.figure.u.75"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2364      <div id="rfc.figure.u.72"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    23912365</pre><p id="rfc.section.9.9.p.12">could be collapsed to</p>
    2392       <div id="rfc.figure.u.76"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2366      <div id="rfc.figure.u.73"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    23932367</pre><p id="rfc.section.9.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    23942368         by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    … …  
    29792953      </p>
    29802954      <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that
    2981          not labeling the representation is preferred over labeling the representation 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>.
     2955         not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    29822956      </p>
    29832957      <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>
    … …  
    30283002      <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30293003      <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3>
    3030       <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification.
     3004      <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification.
    30313005      </p>
    30323006      <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
    … …  
    30403014      </p>
    30413015      <ul>
    3042          <li>Both clients and servers <em class="bcp14">MUST</em> support the Host request-header field.
     3016         <li>Both clients and servers <em class="bcp14">MUST</em> support the Host header field.
    30433017         </li>
    30443018         <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header field.
    30453019         </li>
    3046          <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header field.
     3020         <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host header field.
    30473021         </li>
    30483022         <li>Servers <em class="bcp14">MUST</em> accept absolute URIs.
    … …  
    30953069      </p>
    30963070      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    3097       <div id="rfc.figure.u.77"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    3098 
    3099 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
     3071      <div id="rfc.figure.u.74"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
     3072
    31003073<a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF
    31013074<a href="#header.connection" class="smpl">Connection</a> = "Connection:" OWS Connection-v
    … …  
    31183091<a href="#header.host" class="smpl">Host-v</a> = uri-host [ ":" port ]
    31193092
    3120 <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = &lt;MIME-Version, defined in [Part3], Appendix A.1&gt;
    31213093<a href="#method" class="smpl">Method</a> = token
    31223094
    31233095<a href="#rule.whitespace" class="smpl">OWS</a> = *( [ obs-fold ] WSP )
    3124 
    3125 <a href="#abnf.dependencies" class="smpl">Pragma</a> = &lt;Pragma, defined in [Part6], Section 3.4&gt;
    31263096
    31273097<a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP )
    … …  
    31503120 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
    31513121 ] )
    3152 
    3153 <a href="#abnf.dependencies" class="smpl">Warning</a> = &lt;Warning, defined in [Part6], Section 3.6&gt;
    31543122
    31553123<a href="#uri" class="smpl">absolute-URI</a> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;
    … …  
    32463214<a href="#header.via" class="smpl">received-protocol</a> = [ protocol-name "/" ] protocol-version
    32473215<a href="#uri" class="smpl">relative-part</a> = &lt;relative-part, defined in [RFC3986], Section 4.2&gt;
    3248 <a href="#abnf.dependencies" class="smpl">request-header</a> = &lt;request-header, defined in [Part2], Section 3&gt;
    32493216<a href="#request-target" class="smpl">request-target</a> = "*" / absolute-URI / ( path-absolute [ "?" query ] )
    32503217 / authority
    3251 <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in [Part2], Section 5&gt;
    32523218<a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT
    32533219<a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT
    … …  
    32783244
    32793245<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    3280 </pre> <div id="rfc.figure.u.78"></div>
    3281       <p>ABNF diagnostics:</p><pre class="inline">; Cache-Control defined but not used
    3282 ; Chunked-Body defined but not used
     3246</pre> <div id="rfc.figure.u.75"></div>
     3247      <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used
    32833248; Connection defined but not used
    32843249; Content-Length defined but not used
    … …  
    32863251; HTTP-message defined but not used
    32873252; Host defined but not used
    3288 ; MIME-Version defined but not used
    3289 ; Pragma defined but not used
    32903253; Request defined but not used
    32913254; Response defined but not used
    … …  
    32963259; Upgrade defined but not used
    32973260; Via defined but not used
    3298 ; Warning defined but not used
    32993261; http-URI defined but not used
    33003262; https-URI defined but not used
    33013263; partial-URI defined but not used
    3302 ; request-header defined but not used
    3303 ; response-header defined but not used
    33043264; special defined but not used
    33053265</pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
    … …  
    38363796            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38373797                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li>
    3838                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.2.3</a>, <a href="#rfc.xref.Part2.2">1.2.3</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">4.1.2</a>, <a href="#rfc.xref.Part2.5">5.1.1</a>, <a href="#rfc.xref.Part2.6">7.1.2.2</a>, <a href="#rfc.xref.Part2.7">7.1.4</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a>, <a href="#rfc.xref.Part2.12">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul>
    3839                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.2.3</a></li>
    3840                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2.3</a></li>
    3841                         <li><em>Section 7.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">7.1.2.2</a>, <a href="#rfc.xref.Part2.7">7.1.4</a></li>
    3842                         <li><em>Section 7.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a></li>
    3843                         <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">5.1.1</a></li>
    3844                         <li><em>Section 8.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">7.2.3</a></li>
    3845                         <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">7.2.3</a></li>
    3846                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">9.8</a></li>
    3847                         <li><em>Section 8.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.2</a></li>
    3848                         <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a></li>
     3798                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">4.1.2</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">5.1.1</a>, <a href="#rfc.xref.Part2.4">7.1.2.2</a>, <a href="#rfc.xref.Part2.5">7.1.4</a>, <a href="#rfc.xref.Part2.6">7.2.3</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">9.8</a>, <a href="#Part2"><b>13.1</b></a><ul>
     3799                        <li><em>Section 7.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">7.1.2.2</a>, <a href="#rfc.xref.Part2.5">7.1.4</a></li>
     3800                        <li><em>Section 7.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">4.1.2</a></li>
     3801                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">5.1.1</a></li>
     3802                        <li><em>Section 8.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">7.2.3</a></li>
     3803                        <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">7.2.3</a></li>
     3804                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">9.8</a></li>
     3805                        <li><em>Section 8.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4.1.2</a></li>
     3806                        <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a></li>
    38493807                     </ul>
    38503808                  </li>
    3851                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a>, <a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.5">6.4</a>, <a href="#rfc.xref.Part3.6">7.1.3.2</a>, <a href="#rfc.xref.Part3.7">9.7</a>, <a href="#Part3"><b>13.1</b></a>, <a href="#rfc.xref.Part3.8">A</a><ul>
    3852                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.7">9.7</a></li>
    3853                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.5">6.4</a></li>
     3809                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.3">6.4</a>, <a href="#rfc.xref.Part3.4">7.1.3.2</a>, <a href="#rfc.xref.Part3.5">9.7</a>, <a href="#Part3"><b>13.1</b></a>, <a href="#rfc.xref.Part3.6">A</a><ul>
     3810                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.5">9.7</a></li>
     3811                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">6.4</a></li>
    38543812                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
    3855                         <li><em>Appendix A.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a></li>
    38563813                     </ul>
    38573814                  </li>
    3858                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.3">1.2.3</a>, <a href="#rfc.xref.Part6.4">2.4</a>, <a href="#rfc.xref.Part6.5">3.3</a>, <a href="#rfc.xref.Part6.6">3.4</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a>, <a href="#Part6"><b>13.1</b></a><ul>
    3859                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.4</a></li>
    3860                         <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">3.3</a></li>
    3861                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1.2.3</a>, <a href="#rfc.xref.Part6.2">1.2.3</a>, <a href="#rfc.xref.Part6.6">3.4</a></li>
    3862                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">1.2.3</a>, <a href="#rfc.xref.Part6.7">3.4</a>, <a href="#rfc.xref.Part6.8">7.1.3.2</a></li>
     3815                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.6.2</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">7.1.3.2</a>, <a href="#rfc.xref.Part6.5">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul>
     3816                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a></li>
     3817                        <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.3</a></li>
     3818                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.6.2</a>, <a href="#rfc.xref.Part6.5">9.1</a></li>
     3819                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">7.1.3.2</a></li>
    38633820                     </ul>
    38643821                  </li>

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

    r1162 r1164  
    411411      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    414       <meta name="description" 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.">
     413      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
     414      <meta name="description" 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.">
    415415   </head>
    416416   <body>
    … …  
    502502         systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the
    503503         seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part
    504          2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and
    505          response-header fields.
     504         2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and
     505         response header fields.
    506506      </p>
    507507      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
    … …  
    709709      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    710710         errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections will
    711          be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, general
    712          header fields, methods, request modifiers, response status, and resource metadata. The current mess reflects how widely dispersed
    713          these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
     711         be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, methods,
     712         request modifying header fields, response status, status modifying header fields, and resource metadata. The current mess
     713         reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    714714      </p>
    715715      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
    … …  
    861861      </p>
    862862      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1>
    863       <p id="rfc.section.3.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself,
     863      <p id="rfc.section.3.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself,
    864864         to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language
    865865         method invocation.
    … …  
    953953         </table>
    954954      </div>
    955       <p id="rfc.section.3.p.2">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    956          or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
    957       </p>
    958955      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1>
    959956      <p id="rfc.section.4.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request.</p>
    … …  
    12161213      </p>
    12171214      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
    1218       <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
     1215      <p id="rfc.section.5.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    12191216         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    12201217      </p>
    … …  
    12231220            <thead>
    12241221               <tr>
    1225                   <th>Method Name</th>
     1222                  <th>Header Field Name</th>
    12261223                  <th>Defined in...</th>
    12271224               </tr>
    … …  
    12711268         </table>
    12721269      </div>
    1273       <p id="rfc.section.5.p.2">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    1274          or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header
    1275          fields.
    1276       </p>
    12771270      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    12781271      <p id="rfc.section.6.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
    … …  
    13561349         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
    13571350      </p>
    1358       <p id="rfc.section.7.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
     1351      <p id="rfc.section.7.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
    13591352      </p>
    13601353      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="GET" href="#GET">GET</a></h2>
    … …  
    18691862      <div id="rfc.iref.s.31"></div>
    18701863      <h3 id="rfc.section.8.4.13"><a href="#rfc.section.8.4.13">8.4.13</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h3>
    1871       <p id="rfc.section.8.4.13.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server, as
    1872          defined in <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.16"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     1864      <p id="rfc.section.8.4.13.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server, as defined
     1865         in <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.16"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    18731866      </p>
    18741867      <div id="rfc.iref.52"></div>
    … …  
    18981891      <div id="rfc.iref.s.35"></div>
    18991892      <h3 id="rfc.section.8.4.17"><a href="#rfc.section.8.4.17">8.4.17</a>&nbsp;<a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h3>
    1900       <p id="rfc.section.8.4.17.p.1">The request included a Range request-header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.12"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. See <a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.13"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
     1893      <p id="rfc.section.8.4.17.p.1">The request included a Range header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.12"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. See <a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.13"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
    19011894      </p>
    19021895      <div id="rfc.iref.56"></div>
    19031896      <div id="rfc.iref.s.36"></div>
    19041897      <h3 id="rfc.section.8.4.18"><a href="#rfc.section.8.4.18">8.4.18</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
    1905       <p id="rfc.section.8.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
     1898      <p id="rfc.section.8.4.18.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
    19061899         not be met by the next-hop server.
    19071900      </p>
    … …  
    19731966      <div id="rfc.iref.h.2"></div>
    19741967      <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>
    1975       <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of
    1976          this field is strictly to inform the recipient of valid request methods associated with the resource.
     1968      <p id="rfc.section.9.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field
     1969         is strictly to inform the recipient of valid request methods associated with the resource.
    19771970      </p>
    19781971      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></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>
    … …  
    19871980      <div id="rfc.iref.h.3"></div>
    19881981      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
    1989       <p id="rfc.section.9.2.p.1">The "Expect" request-header field is used to indicate that particular server behaviors are required by the client.</p>
     1982      <p id="rfc.section.9.2.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>
    19901983      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#header.expect" class="smpl">Expect</a>       = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a>
    19911984  <a href="#header.expect" class="smpl">Expect-v</a>     = 1#<a href="#header.expect" class="smpl">expectation</a>
    … …  
    20051998      </p>
    20061999      <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the
    2007          Expect request-header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
     2000         Expect header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
    20082001      </p>
    20092002      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    … …  
    20132006      <div id="rfc.iref.h.4"></div>
    20142007      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
    2015       <p id="rfc.section.9.3.p.1">The "From" request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
     2008      <p id="rfc.section.9.3.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
    20162009      </p>
    20172010      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.from" class="smpl">From</a>    = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a>
    … …  
    20352028      <div id="rfc.iref.h.5"></div>
    20362029      <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>
    2037       <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
    2038          location for completion of the request.
     2030      <p id="rfc.section.9.4.p.1">The "Location" header field is used to identify a newly created resource, or to redirect the recipient to a different location
     2031         for completion of the request.
    20392032      </p>
    20402033      <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,
    … …  
    20672060      <div id="rfc.iref.h.6"></div>
    20682061      <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>
    2069       <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
     2062      <p id="rfc.section.9.5.p.1">The "Max-Forwards" 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
    20702063         is attempting to trace a request which appears to be failing or looping in mid-chain.
    20712064      </p>
    … …  
    20802073      <div id="rfc.iref.h.7"></div>
    20812074      <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>
    2082       <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 effective request
    2083          URI was obtained (the "referrer", although the header field is misspelled.).
     2075      <p id="rfc.section.9.6.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI
     2076         was obtained (the "referrer", although the header field is misspelled.).
    20842077      </p>
    20852078      <p id="rfc.section.9.6.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
    … …  
    21002093      <div id="rfc.iref.h.8"></div>
    21012094      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
    2102       <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
    2103          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
     2095      <p id="rfc.section.9.7.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
     2096         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
    21042097         the redirected request.
    21052098      </p>
    … …  
    21182111      <div id="rfc.iref.h.9"></div>
    21192112      <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>
    2120       <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>
     2113      <p id="rfc.section.9.8.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    21212114      <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.33"><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.34"><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
    21222115         identifying the application.
    … …  
    21272120</pre><p id="rfc.section.9.8.p.4">Example:</p>
    21282121      <div id="rfc.figure.u.28"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2129 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     2122</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 header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    21302123      </p>
    21312124      <div class="note" id="rfc.section.9.8.p.7">
    … …  
    21382131      <div id="rfc.iref.h.10"></div>
    21392132      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>
    2140       <p id="rfc.section.9.9.p.1">The "User-Agent" request-header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
     2133      <p id="rfc.section.9.9.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
    21412134      </p>
    21422135      <p id="rfc.section.9.9.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular

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

    r1162 r1164  
    10201020         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    10211021      </ol>
    1022       <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent
    1023          capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header fields or within extension
    1024          header fields not defined by this specification.
     1022      <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
     1023         and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
     1024         within extension header fields not defined by this specification.
    10251025      </p>
    10261026      <div class="note" id="rfc.section.5.1.p.5">
    … …  
    10541054      <div id="rfc.iref.h.1"></div>
    10551055      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
    1056       <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept header
    1057          fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of
    1058          a request for an in-line image.
     1056      <p id="rfc.section.6.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields
     1057         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
     1058         for an in-line image.
    10591059      </p>
    10601060      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
    … …  
    11551155      <div id="rfc.iref.h.2"></div>
    11561156      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
    1157       <p id="rfc.section.6.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.
    1158          This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
     1157      <p id="rfc.section.6.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what response character sets are acceptable. This
     1158         field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
    11591159         to a server which is capable of representing documents in those character sets.
    11601160      </p>
    … …  
    11791179      <div id="rfc.iref.h.3"></div>
    11801180      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
    1181       <p id="rfc.section.6.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.
     1181      <p id="rfc.section.6.3.p.1">The "Accept-Encoding" 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.
    11821182      </p>
    11831183      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    12301230      <div id="rfc.iref.h.4"></div>
    12311231      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
    1232       <p id="rfc.section.6.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
     1232      <p id="rfc.section.6.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred
    12331233         in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
    12341234      </p>
    … …  
    15461546      </p>
    15471547      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    1548       <p id="rfc.section.8.1.p.1">Accept request-headers fields can reveal information about the user to all servers which are accessed. The Accept-Language
    1549          header field in particular can reveal information the user would consider to be of a private nature, because the understanding
    1550          of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
     1548      <p id="rfc.section.8.1.p.1">Accept headers fields can reveal information about the user to all servers which are accessed. The Accept-Language header
     1549         field in particular can reveal information the user would consider to be of a private nature, because the understanding of
     1550         particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
    15511551         the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
    15521552         to let the configuration process include a message which makes the user aware of the loss of privacy involved.
    … …  
    15541554      <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
    15551555         by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
    1556          looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service.
     1556         looking for any Vary header fields generated by the server, that such sending could improve the quality of service.
    15571557      </p>
    15581558      <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
    … …  
    17621762      <div id="rfc.iref.h.10"></div>
    17631763      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="mime-version" href="#mime-version">MIME-Version</a></h2>
    1764       <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the
    1765          message. Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as
    1766          defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME
     1764      <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message.
     1765         Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME
    17671766         environments.
    17681767      </p>

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

    r1162 r1164  
    605605      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    606606         errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on
    607          resource metadata will be discussed first and then followed by each conditional request-header field, concluding with a definition
     607         resource metadata will be discussed first and then followed by each conditional request header field, concluding with a definition
    608608         of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more
    609609         content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements
    … …  
    708708      <div id="rfc.iref.s.2"></div>
    709709      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h2>
    710       <p id="rfc.section.3.2.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This
    711          response code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent
    712          the requested method from being applied to a resource other than the one intended.
     710      <p id="rfc.section.3.2.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server. This response
     711         code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent the requested
     712         method from being applied to a resource other than the one intended.
    713713      </p>
    714714      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="weak.and.strong.validators" href="#weak.and.strong.validators">Weak and Strong Validators</a></h1>
    … …  
    904904      <div id="rfc.iref.h.1"></div>
    905905      <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>
    906       <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 one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating
     906      <p id="rfc.section.6.1.p.1">The "ETag" header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating
    907907         between representations of the same resource that vary over time or via content negotiation (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
    908908      </p>
    … …  
    925925      <div id="rfc.iref.h.2"></div>
    926926      <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>
    927       <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 representations
    928          previously obtained from the resource can verify that one of those representations is current by including a list of their
    929          associated entity-tags in the If-Match header field.
     927      <p id="rfc.section.6.2.p.1">The "If-Match" header field is used to make a request method conditional. A client that has one or more representations previously
     928         obtained from the resource can verify that one of those representations is current by including a list of their associated
     929         entity-tags in the If-Match header field.
    930930      </p>
    931931      <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
    … …  
    960960      <div id="rfc.iref.h.3"></div>
    961961      <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>
    962       <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used to make a request method conditional by date: if the representation that
    963          would have been transferred in a 200 response to a GET request has not been modified since the time specified in this field,
    964          then do not perform the method; instead, respond as detailed below.
     962      <p id="rfc.section.6.3.p.1">The "If-Modified-Since" header field is used to make a request method conditional by date: if the representation that would
     963         have been transferred in a 200 response to a GET request has not been modified since the time specified in this field, then
     964         do not perform the method; instead, respond as detailed below.
    965965      </p>
    966966      <div id="rfc.figure.u.11"></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>
    … …  
    986986      <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>
    987987      <ul class="empty">
    988          <li> <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.
     988         <li> <b>Note:</b> The Range 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.
    989989         </li>
    990990         <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
    … …  
    10101010      <div id="rfc.iref.h.4"></div>
    10111011      <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>
    1012       <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 representations
     1012      <p id="rfc.section.6.4.p.1">The "If-None-Match" header field is used to make a request method conditional. A client that has one or more representations
    10131013         previously obtained from the resource can verify that none of those representations is current by including a list of their
    10141014         associated entity-tags in the If-None-Match header field.
    … …  
    10461046      <div id="rfc.iref.h.5"></div>
    10471047      <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>
    1048       <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used to make a request method conditional. If the representation that would
    1049          have been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified
    1050          in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header field were not present.
     1048      <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" header field is used to make a request method conditional. If the representation that would have
     1049         been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified in
     1050         this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header field were not present.
    10511051      </p>
    10521052      <p id="rfc.section.6.5.p.2">If the representation has been modified since the specified time, the server <em class="bcp14">MUST NOT</em> perform the requested operation, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed).

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

    r1162 r1164  
    695695      <div id="rfc.iref.s.2"></div>
    696696      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h2>
    697       <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> return a response with this status code if a request included a Range request-header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section&nbsp;5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request
    698          did not include an If-Range request-header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current
     697      <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> return a response with this status code if a request included a Range header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section&nbsp;5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request
     698         did not include an If-Range header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current
    699699         length of the selected resource.)
    700700      </p>
    … …  
    722722      <div id="rfc.iref.h.1"></div>
    723723      <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>
    724       <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>
     724      <p id="rfc.section.5.1.p.1">The "Accept-Ranges" header field allows a resource to indicate its acceptance of range requests.</p>
    725725      <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>
    726726  <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a>   = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a>
    … …  
    807807         the full representation).
    808808      </p>
    809       <p id="rfc.section.5.2.p.15">If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header
    810          field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected
     809      <p id="rfc.section.5.2.p.15">If the server receives a request (other than one including an If-Range header field) with an unsatisfiable Range header field
     810         (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected
    811811         resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section&nbsp;3.2</a>).
    812812      </p>
    813813      <div class="note" id="rfc.section.5.2.p.16">
    814814         <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for
    815             an unsatisfiable Range request-header field, since not all servers implement this request-header field.
     815            an unsatisfiable Range header field, since not all servers implement this header field.
    816816         </p>
    817817      </div>
    … …  
    820820      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    821821      <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation in its cache, and wishes to have an up-to-date copy of the entire representation
    822          in its cache, it could use the Range request-header field with a conditional GET (using either or both of If-Unmodified-Since
    823          and If-Match.) However, if the condition fails because the representation has been modified, the client would then have to
    824          make a second request to obtain the entire current representation.
    825       </p>
    826       <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is "if
    827          the representation is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation".
     822         in its cache, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and
     823         If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make
     824         a second request to obtain the entire current representation.
     825      </p>
     826      <p id="rfc.section.5.3.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is "if the representation
     827         is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation".
    828828      </p>
    829829      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.if-range" class="smpl">If-Range</a>   = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a>
    … …  
    897897      </ul>
    898898      <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>
    899       <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
    900          representation body, instead of the entire representation body.
     899      <p id="rfc.section.5.4.2.p.1">The "Range" header field defines the GET method (conditional or not) to request one or more sub-ranges of the response representation
     900         body, instead of the entire representation body.
    901901      </p>
    902902      <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/p6-cache.html

    r1162 r1164  
    783783         </li>
    784784         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    785          <li>selecting request-header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>), and
     785         <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>), and
    786786         </li>
    787787         <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>), and
    … …  
    868868      </div>
    869869      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
    870       <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age response-header field to convey the estimated age of the response message when obtained from a cache.
    871          The Age field value is the cache's estimate of the amount of time since the response was generated or validated by the origin
    872          server. In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the
    873          path from the origin server, plus the amount of time it has been in transit along network paths.
     870      <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age header field to convey the estimated age of the response message when obtained from a cache. The Age
     871         field value is the cache's estimate of the amount of time since the response was generated or validated by the origin server.
     872         In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path
     873         from the origin server, plus the amount of time it has been in transit along network paths.
    874874      </p>
    875875      <p id="rfc.section.2.3.2.p.2">The following data is used for the age calculation:</p>
    … …  
    990990      </p>
    991991      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
    992       <p id="rfc.section.2.7.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting request-header fields nominated by the Vary header field match in both the original
     992      <p id="rfc.section.2.7.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
    993993         request (i.e., that associated with the stored response), and the presented request.
    994994      </p>
    995       <p id="rfc.section.2.7.p.2">The selecting request-header fields from two requests are defined to match if and only if those in the first request can be
    996          transformed to those in the second request by applying any of the following:
     995      <p id="rfc.section.2.7.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed
     996         to those in the second request by applying any of the following:
    997997      </p>
    998998      <ul>
    999999         <li>adding or removing whitespace, where allowed in the header field's syntax</li>
    1000          <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
     1000         <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
    10011001         </li>
    10021002         <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
    … …  
    10101010         by the origin server.
    10111011      </p>
    1012       <p id="rfc.section.2.7.p.5">The stored response with matching selecting request-header fields is known as the selected response.</p>
     1012      <p id="rfc.section.2.7.p.5">The stored response with matching selecting header fields is known as the selected response.</p>
    10131013      <p id="rfc.section.2.7.p.6">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>.
    10141014      </p>
    … …  
    10401040      <div id="rfc.iref.h.2"></div>
    10411041      <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>
    1042       <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
     1042      <p id="rfc.section.3.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully
    10431043         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>.
    10441044      </p>
    … …  
    10581058      <div id="rfc.iref.h.3"></div>
    10591059      <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>
    1060       <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives for caches along the request/response chain. Such cache
    1061          directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to
    1062          be given in the response.
     1060      <p id="rfc.section.3.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives
     1061         are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given
     1062         in the response.
    10631063      </p>
    10641064      <p id="rfc.section.3.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;3.2.3</a> for information about how Cache-Control directives defined elsewhere are handled.
    … …  
    13031303      <div id="rfc.iref.h.5"></div>
    13041304      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
    1305       <p id="rfc.section.3.4.p.1">The "Pragma" general-header field is used to include implementation-specific directives that might apply to any recipient
    1306          along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however,
    1307          some systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives.
     1305      <p id="rfc.section.3.4.p.1">The "Pragma" header field is used to include implementation-specific directives that might apply to any recipient along the
     1306         request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some
     1307         systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives.
    13081308      </p>
    13091309      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.pragma" class="smpl">Pragma</a>            = "Pragma" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.pragma" class="smpl">Pragma-v</a>
    … …  
    13151315      </p>
    13161316      <div class="note" id="rfc.section.3.4.p.4">
    1317          <p> <b>Note:</b> Because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable
    1318             replacement for "Cache-Control: no-cache" in a response.
     1317         <p> <b>Note:</b> Because the meaning of "Pragma: no-cache" as a header field is not actually specified, it does not provide a reliable replacement
     1318            for "Cache-Control: no-cache" in a response.
    13191319         </p>
    13201320      </div>
    … …  
    13231323      <div id="rfc.iref.h.6"></div>
    13241324      <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>
    1325       <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>
     1325      <p id="rfc.section.3.5.p.1">The "Vary" header field conveys the set of header fields that were used to select the representation.</p>
    13261326      <p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisfy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request
    13271327         without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>.
    … …  
    13321332      <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>
    13331333  <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
    1334 </pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-header fields.</p>
     1334</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 header fields.</p>
    13351335      <p id="rfc.section.3.5.p.6">A server <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
    13361336         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
    … …  
    13381338         the user agent with useful information about the dimensions over which the response varies at the time of the response.
    13391339      </p>
    1340       <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-header fields (e.g., the network
    1341          address of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether
    1342          this response is appropriate. A proxy <em class="bcp14">MUST NOT</em> generate the "*" value.
    1343       </p>
    1344       <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
    1345          are case-insensitive.
     1340      <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the header fields (e.g., the network address
     1341         of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
     1342         response is appropriate. A proxy <em class="bcp14">MUST NOT</em> generate the "*" value.
     1343      </p>
     1344      <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard header fields defined by this specification. Field names are
     1345         case-insensitive.
    13461346      </p>
    13471347      <div id="rfc.iref.w.1"></div>
    13481348      <div id="rfc.iref.h.7"></div>
    13491349      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
    1350       <p id="rfc.section.3.6.p.1">The "Warning" general-header field is used to carry additional information about the status or transformation of a message
    1351          that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
    1352          by caching operations or transformations applied to the payload of the message.
     1350      <p id="rfc.section.3.6.p.1">The "Warning" header field is used to carry additional information about the status or transformation of a message that might
     1351         not be reflected in the message. This information is typically used to warn about possible incorrectness introduced by caching
     1352         operations or transformations applied to the payload of the message.
    13531353      </p>
    13541354      <p id="rfc.section.3.6.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status

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

    r1162 r1164  
    711711      <div id="rfc.iref.h.1"></div>
    712712      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
    713       <p id="rfc.section.4.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server — usually, but not necessarily,
     713      <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with a server — usually, but not necessarily,
    714714         after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent
    715715         for the realm of the resource being requested.
    … …  
    724724      <p id="rfc.section.4.1.p.5"> </p>
    725725      <ol>
    726          <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-header fields from the new request to allow the origin server
    727             to authenticate the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy <em class="bcp14">MUST</em> always revalidate it before re-using it.
    728          </li>
    729          <li>If the response includes the "must-revalidate" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But if the response is stale, all caches <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-header fields from the new request to allow the origin server
    730             to authenticate the new request.
     726         <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the header fields from the new request to allow the origin server to authenticate
     727            the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy <em class="bcp14">MUST</em> always revalidate it before re-using it.
     728         </li>
     729         <li>If the response includes the "must-revalidate" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But if the response is stale, all caches <em class="bcp14">MUST</em> first revalidate it with the origin server, using the header fields from the new request to allow the origin server to authenticate
     730            the new request.
    731731         </li>
    732732         <li>If the response includes the "public" cache-control directive, it <em class="bcp14">MAY</em> be returned in reply to any subsequent request.
    … …  
    736736      <div id="rfc.iref.h.2"></div>
    737737      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    738       <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters
    739          applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
     738      <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of a challenge that indicates the authentication scheme and parameters applicable
     739         to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
    740740      </p>
    741741      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a>   = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    749749      <div id="rfc.iref.h.3"></div>
    750750      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2>
    751       <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" request-header field allows the client to identify itself (or its user) to a proxy which requires
    752          authentication. Its value consists of credentials containing the authentication information of the user agent for the proxy
    753          and/or realm of the resource being requested.
     751      <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy which requires authentication.
     752         Its value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of
     753         the resource being requested.
    754754      </p>
    755755      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a>   = "Proxy-Authorization" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    764764      <div id="rfc.iref.h.4"></div>
    765765      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
    766       <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s)
    767          and parameters applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
     766      <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
     767         applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
    768768      </p>
    769769      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></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>
Note: See TracChangeset for help on using the changeset viewer.