Changeset 395


Ignore:
Timestamp:
Nov 14, 2008, 11:49:55 PM (11 years ago)
Author:
fielding@…
Message:

Deprecate line folding, addresses #77.
Require that invalid whitespace around field-names be rejected, addresses #30.
Make non-ASCII content obsolete and opaque in header fields
and reason phrase, addresses #63, #74, #94, #111.

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

Legend:

Unmodified
Added
Removed

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

    r392 r395  
    476476         <tr>
    477477            <td class="header left"></td>
    478             <td class="header right">November 15, 2008</td>
     478            <td class="header right">November 14, 2008</td>
    479479         </tr>
    480480      </table>
    … …  
    707707      <div id="rfc.iref.g.11"></div>
    708708      <div id="rfc.iref.g.12"></div>
    709       <div id="rfc.iref.g.13"></div>
    710709      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    711710      <div id="core.rules">
    712          <p id="rfc.section.1.2.p.1">                          This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CHAR (any <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character, excluding NUL), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
    713             HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space) and
    714             WSP (white space).
     711         <p id="rfc.section.1.2.p.1">                        This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
     712            (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character), and WSP (white space).
    715713         </p>
    716714      </div>
    … …  
    737735      </div>
    738736      <div id="rule.LWS">
    739          <p id="rfc.section.1.2.2.p.2">All linear white space (LWS) in header field-values has the same semantics as SP. A recipient <em class="bcp14">MAY</em> replace any such linear white space with a single SP before interpreting the field value or forwarding the message downstream.
     737         <p id="rfc.section.1.2.2.p.2">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),
     738            and BWS ("bad" whitespace).
    740739         </p>
    741740      </div>
    742       <p id="rfc.section.1.2.2.p.3">Historically, HTTP/1.1 header field values allow linear white space folding across multiple lines. However, this specification
    743          deprecates its use; senders <em class="bcp14">MUST NOT</em> produce messages that include LWS folding (i.e., use the obs-fold rule), except within the message/http media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>). Receivers <em class="bcp14">SHOULD</em> still parse folded linear white space.
    744       </p>
    745       <p id="rfc.section.1.2.2.p.4">This specification uses three rules to denote the use of linear white space; BWS ("Bad" White Space), OWS (Optional White
    746          Space), and RWS (Required White Space).
    747       </p>
    748       <p id="rfc.section.1.2.2.p.5">"Bad" white space is allowed by the BNF, but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. Receivers <em class="bcp14">MUST</em> accept it in incoming messages.
    749       </p>
    750       <p id="rfc.section.1.2.2.p.6">Required white space is used when at least one linear white space character is required to separate field tokens. In all such
    751          cases, a single SP character <em class="bcp14">SHOULD</em> be used.
     741      <p id="rfc.section.1.2.2.p.3">The OWS rule is used where zero or more linear white space characters may appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP character. Multiple OWS characters that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.
     742      </p>
     743      <p id="rfc.section.1.2.2.p.4">RWS is used when at least one linear white space character is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP character. Multiple RWS characters that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.
     744      </p>
     745      <p id="rfc.section.1.2.2.p.5">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1 recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.
    752746      </p>
    753747      <div id="rule.whitespace">
    754          <p id="rfc.section.1.2.2.p.7">        </p>
     748         <p id="rfc.section.1.2.2.p.6">        </p>
    755749      </div>
    756       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span>  <a href="#rule.whitespace" class="smpl">OWS</a>            = *( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> )
     750      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#rule.whitespace" class="smpl">OWS</a>            = *( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> )
    757751                 ; "optional" white space
    758752  <a href="#rule.whitespace" class="smpl">RWS</a>            = 1*( [ obs-fold ] <a href="#core.rules" class="smpl">WSP</a> )
    … …  
    761755                 ; "bad" white space
    762756  <a href="#rule.whitespace" class="smpl">obs-fold</a>       = <a href="#core.rules" class="smpl">CRLF</a>
    763 </pre><div id="rule.TEXT">
    764          <p id="rfc.section.1.2.2.p.9">  The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message
    765             parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> only when encoded according to the rules of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
     757</pre><div id="rule.token.separators">
     758         <p id="rfc.section.1.2.2.p.8">    Many HTTP/1.1 header field values consist of words separated by whitespace or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>).
    766759         </p>
    767760      </div>
    768       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.17"></span>  <a href="#rule.TEXT" class="smpl">TEXT</a>           = %x20-7E / %x80-FF / <a href="#rule.whitespace" class="smpl">OWS</a>
    769                  ; any <a href="#core.rules" class="smpl">OCTET</a> except <a href="#core.rules" class="smpl">CTL</a>s, but including <a href="#rule.whitespace" class="smpl">OWS</a>
    770 </pre><p id="rfc.section.1.2.2.p.11">A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS
    771          will be replaced with a single SP before interpretation of the TEXT value.
    772       </p>
    773       <div id="rule.token.separators">
    774          <p id="rfc.section.1.2.2.p.12">    Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>).
    775          </p>
    776       </div>
    777       <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#rule.token.separators" class="smpl">tchar</a>          = "!" / "#" / "$" / "%" / "&amp;" / "'" / "*"
     761      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#rule.token.separators" class="smpl">tchar</a>          = "!" / "#" / "$" / "%" / "&amp;" / "'" / "*"
    778762                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
    779763                 / <a href="#core.rules" class="smpl">DIGIT</a> / <a href="#core.rules" class="smpl">ALPHA</a>
    780764                 
    781765  <a href="#rule.token.separators" class="smpl">token</a>          = 1*<a href="#rule.token.separators" class="smpl">tchar</a>
    782 </pre><div id="rule.comment">
    783          <p id="rfc.section.1.2.2.p.14">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
    784             in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part
    785             of the field value.
     766</pre><div id="rule.quoted-string">
     767         <p id="rfc.section.1.2.2.p.10">      A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
     768      </div>
     769      <div id="rfc.figure.u.5"></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="#rule.quoted-string" class="smpl">quoted-string</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *(<a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
     770  <a href="#rule.quoted-string" class="smpl">qdtext</a>         = *( <a href="#rule.whitespace" class="smpl">OWS</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
     771  <a href="#rule.quoted-string" class="smpl">obs-text</a>       = %x80-FF
     772</pre><div id="rule.quoted-pair">
     773         <p id="rfc.section.1.2.2.p.12">    The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs.
    786774         </p>
    787775      </div>
    788       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
    789   <a href="#rule.comment" class="smpl">ctext</a>          = &lt;any <a href="#rule.TEXT" class="smpl">TEXT</a> excluding "(" and ")"&gt;
    790 </pre><div id="rule.quoted-string">
    791          <p id="rfc.section.1.2.2.p.16">    A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
    792       </div>
    793       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *(<a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
    794   <a href="#rule.quoted-string" class="smpl">qdtext</a>         = &lt;any <a href="#rule.TEXT" class="smpl">TEXT</a> excluding <a href="#core.rules" class="smpl">DQUOTE</a> and "\"&gt;
    795 </pre><div id="rule.quoted-pair">
    796          <p id="rfc.section.1.2.2.p.18">    The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs.
    797          </p>
    798       </div>
    799       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-text</a>    = %x01-09 /
     776      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-text</a>    = %x01-09 /
    800777                   %x0B-0C /
    801778                   %x0E-FF ; Characters excluding NUL, <a href="#core.rules" class="smpl">CR</a> and <a href="#core.rules" class="smpl">LF</a>
    … …  
    803780</pre><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>
    804781      <p id="rfc.section.1.2.3.p.1">The ABNF rules below are defined in other parts:</p>
    805       <div id="rfc.figure.u.9"></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 4</a>&gt;
     782      <div id="rfc.figure.u.7"></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 4</a>&gt;
    806783  <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 6</a>&gt;
    807 </pre><div id="rfc.figure.u.10"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">accept-params</a>   = &lt;accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
     784</pre><div id="rfc.figure.u.8"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">accept-params</a>   = &lt;accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
    808785  <a href="#abnf.dependencies" class="smpl">entity-body</a>     = &lt;entity-body, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.body" title="Entity Body">Section 4.2</a>&gt;
    809786  <a href="#abnf.dependencies" class="smpl">entity-header</a>   = &lt;entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>&gt;
    810 </pre><div id="rfc.figure.u.11"></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 16.4</a>&gt;
     787</pre><div id="rfc.figure.u.9"></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 16.4</a>&gt;
    811788  <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 16.4</a>&gt;
    812789  <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 16.6</a>&gt;
    … …  
    824801         "path-abempty", "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.
    825802      </p>
    826       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.26"></span><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>  <a href="#uri" class="smpl">URI</a>           = &lt;URI, 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-3">Section 3</a>&gt;
     803      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#uri" class="smpl">URI</a>           = &lt;URI, 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-3">Section 3</a>&gt;
    827804  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, 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.1">Section 4.1</a>&gt;
    828805  <a href="#uri" class="smpl">absolute-URI</a>  = &lt;absolute-URI, 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.3">Section 4.3</a>&gt;
    … …  
    848825         for identifiers using the http or https URI schemes.
    849826      </p>
    850       <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.33"></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> ]
     827      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.30"></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> ]
    851828</pre><p id="rfc.section.2.1.1.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server
    852829         listening for TCP connections on that port of that host, and the request-target for the resource is path-absolute (<a href="#request-target" title="request-target">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a request-target for a resource (<a href="#request-target" title="request-target">Section&nbsp;5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    … …  
    870847      </p>
    871848      <p id="rfc.section.2.1.2.p.3">For example, the following three URIs are equivalent:</p>
    872       <div id="rfc.figure.u.14"></div><pre class="text">   http://example.com:80/~smith/home.html
     849      <div id="rfc.figure.u.12"></div><pre class="text">   http://example.com:80/~smith/home.html
    873850   http://EXAMPLE.com/%7Esmith/home.html
    874851   http://EXAMPLE.com:/%7esmith/home.html
    … …  
    885862         server (O).
    886863      </p>
    887       <div id="rfc.figure.u.15"></div><pre class="drawing">       request chain ------------------------&gt;
     864      <div id="rfc.figure.u.13"></div><pre class="drawing">       request chain ------------------------&gt;
    888865    UA -------------------v------------------- O
    889866       &lt;----------------------- response chain
    … …  
    896873         cannot understand the contents of the messages.
    897874      </p>
    898       <div id="rfc.figure.u.16"></div><pre class="drawing">       request chain --------------------------------------&gt;
     875      <div id="rfc.figure.u.14"></div><pre class="drawing">       request chain --------------------------------------&gt;
    899876    UA -----v----- A -----v----- B -----v----- C -----v----- O
    900877       &lt;------------------------------------- response chain
    … …  
    911888         O (via C) for a request which has not been cached by UA or A.
    912889      </p>
    913       <div id="rfc.figure.u.17"></div><pre class="drawing">          request chain ----------&gt;
     890      <div id="rfc.figure.u.15"></div><pre class="drawing">          request chain ----------&gt;
    914891       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
    915892          &lt;--------- response chain
    … …  
    952929      </p>
    953930      <p id="rfc.section.3.1.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>
    954       <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></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>
     931      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></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>
    955932  <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive
    956933</pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3.
    … …  
    976953      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="full.date" href="#full.date">Full Date</a></h3>
    977954      <p id="rfc.section.3.2.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p>
    978       <div id="rfc.figure.u.19"></div><pre class="text">   Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
     955      <div id="rfc.figure.u.17"></div><pre class="text">   Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
    979956   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    980957   Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    … …  
    989966      <p id="rfc.section.3.2.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
    990967         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    991          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 LWS beyond that specifically included as SP in the grammar.
    992       </p>
    993       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.36"></span><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><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span>  <a href="#full.date" class="smpl">HTTP-date</a>    = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a>
     968         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.
     969      </p>
     970      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><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><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span>  <a href="#full.date" class="smpl">HTTP-date</a>    = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a>
    994971  <a href="#full.date" class="smpl">obsolete-date</a> = <a href="#full.date" class="smpl">rfc850-date</a> / <a href="#full.date" class="smpl">asctime-date</a>
    995972  <a href="#full.date" class="smpl">rfc1123-date</a> = <a href="#full.date" class="smpl">wkday</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> time <a href="#core.rules" class="smpl">SP</a> GMT
    … …  
    10501027         is a property of the message, not of the original entity.
    10511028      </p>
    1052       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>
     1029      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>
    10531030  <a href="#transfer.codings" class="smpl">transfer-extension</a>      = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#transfer.codings" class="smpl">parameter</a> )
    10541031</pre><div id="rule.parameter">
    10551032         <p id="rfc.section.3.3.p.3">      Parameters are in the form of attribute/value pairs.</p>
    10561033      </div>
    1057       <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span>  <a href="#transfer.codings" class="smpl">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>
     1034      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span>  <a href="#transfer.codings" class="smpl">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>
    10581035  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    10591036  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
    … …  
    10801057         necessary for the recipient to verify that it has received the full message.
    10811058      </p>
    1082       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.53"></span><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>  <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>
     1059      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span><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>  <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>
    10831060                   <a href="#chunked.transfer.encoding" class="smpl">last-chunk</a>
    10841061                   <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a>
    … …  
    11181095      </p>
    11191096      <p id="rfc.section.3.3.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    1120       <div id="rfc.figure.u.24"></div><pre class="text">  length := 0
     1097      <div id="rfc.figure.u.22"></div><pre class="text">  length := 0
    11211098  read chunk-size, chunk-ext (if any) and CRLF
    11221099  while (chunk-size &gt; 0) {
    … …  
    11401117         space. By convention, the products are listed in order of their significance for identifying the application.
    11411118      </p>
    1142       <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></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>]
     1119      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></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>]
    11431120  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    11441121</pre><p id="rfc.section.3.4.p.3">Examples:</p>
    1145       <div id="rfc.figure.u.26"></div><pre class="text">    User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     1122      <div id="rfc.figure.u.24"></div><pre class="text">    User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    11461123    Server: Apache/0.8.4
    11471124</pre><p id="rfc.section.3.4.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).
    … …  
    11501127      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="message.types" href="#message.types">Message Types</a></h2>
    11511128      <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>
    1152       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.64"></span>  <a href="#message.types" class="smpl">HTTP-message</a>   = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a>     ; HTTP/1.1 messages
     1129      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.61"></span>  <a href="#message.types" class="smpl">HTTP-message</a>   = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a>     ; HTTP/1.1 messages
    11531130</pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;6</a>) messages use the generic message format of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header
    11541131         fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header
    11551132         fields, and possibly a message-body.
    11561133      </p>
    1157       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span>  <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a>
     1134      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span>  <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a>
    11581135                    *(<a href="#message.headers" class="smpl">message-header</a> <a href="#core.rules" class="smpl">CRLF</a>)
    11591136                    <a href="#core.rules" class="smpl">CRLF</a>
    … …  
    11661143         by the BNF, an HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF.
    11671144      </p>
     1145      <p id="rfc.section.4.1.p.7">Whitespace (WSP) <em class="bcp14">MUST NOT</em> be sent between the start-line and the first header field. The presence of whitespace might be an attempt to trick a noncompliant
     1146         implementation of HTTP into ignoring that field or processing the next line as a new request, either of which may result in
     1147         security issues when implementations within the request chain interpret the same message differently. HTTP/1.1 servers <em class="bcp14">MUST</em> reject such a message with a 400 (Bad Request) response.
     1148      </p>
    11681149      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="message.headers" href="#message.headers">Message Headers</a></h2>
    1169       <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
    1170          field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding
    1171          each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated,
    1172          when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common
    1173          forms.
    1174       </p>
    1175       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span>  <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" [ <a href="#message.headers" class="smpl">field-value</a> ]
     1150      <p id="rfc.section.4.2.p.1">HTTP header fields follow the same general format as Internet messages in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":"), optional whitespace, and the field value. Field names are
     1151         case-insensitive.
     1152      </p>
     1153      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span>  <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" OWS [ <a href="#message.headers" class="smpl">field-value</a> ] OWS
    11761154  <a href="#message.headers" class="smpl">field-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
    11771155  <a href="#message.headers" class="smpl">field-value</a>    = *( <a href="#message.headers" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> )
    1178   <a href="#message.headers" class="smpl">field-content</a>  = &lt;field content&gt;
    1179 </pre><p id="rfc.section.4.2.p.3"> <span class="comment">[rfc.comment.1: whitespace between field-name and colon is an error and MUST NOT be accepted]</span>
    1180       </p>
    1181       <p id="rfc.section.4.2.p.4">The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace
    1182          character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS <em class="bcp14">MAY</em> be removed without changing the semantics of the field value. Any LWS that occurs between field-content <em class="bcp14">MAY</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.
    1183       </p>
    1184       <p id="rfc.section.4.2.p.5">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
     1156  <a href="#message.headers" class="smpl">field-content</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> )
     1157</pre><p id="rfc.section.4.2.p.3">Historically, HTTP has allowed field-content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> character encoding (allowing other character sets through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding). In practice, most HTTP header field-values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> constrain their field-values to US-ASCII characters. Recipients <em class="bcp14">SHOULD</em> treat other (obs-text) octets in field-content as opaque data.
     1158      </p>
     1159      <p id="rfc.section.4.2.p.4">No whitespace is allowed between the header field-name and colon. For security reasons, any request message received containing
     1160         such whitespace <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request) and any such whitespace in a response message <em class="bcp14">MUST</em> be removed.
     1161      </p>
     1162      <p id="rfc.section.4.2.p.5">The field value <em class="bcp14">MAY</em> be preceded by optional white space; a single SP is preferred. The field-value does not include any leading or trailing white
     1163         space: OWS occurring before the first non-whitespace character of the field-value or after the last non-whitespace character
     1164         of the field-value is ignored and <em class="bcp14">MAY</em> be removed without changing the meaning of the header field.
     1165      </p>
     1166      <p id="rfc.section.4.2.p.6">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
     1167         space or horizontal tab character (line folding). This specification deprecates such line folding except within the message/http
     1168         media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>). HTTP/1.1 senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the
     1169         message is intended for packaging within the message/http media type. HTTP/1.1 recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with a single SP prior to interpreting the field value or
     1170         forwarding the message downstream.
     1171      </p>
     1172      <div id="rule.comment">
     1173         <p id="rfc.section.4.2.p.7">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
     1174            in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part
     1175            of the field value.
     1176         </p>
     1177      </div>
     1178      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
     1179  <a href="#rule.comment" class="smpl">ctext</a>          = *( <a href="#rule.whitespace" class="smpl">OWS</a> / %x21-27 / %x2A-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
     1180</pre><p id="rfc.section.4.2.p.9">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    11851181         to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header
    11861182         fields.
    11871183      </p>
    1188       <p id="rfc.section.4.2.p.6">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e.,
     1184      <p id="rfc.section.4.2.p.10">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e.,
    11891185         #(values)]. It <em class="bcp14">MUST</em> be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics
    11901186         of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header
    … …  
    11921188         thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded.
    11931189      </p>
    1194       <p id="rfc.section.4.2.p.7"> </p>
     1190      <p id="rfc.section.4.2.p.11"> </p>
    11951191      <dl class="empty">
    11961192         <dd> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
    … …  
    12031199         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;8.7</a>).
    12041200      </p>
    1205       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>
     1201      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.70"></span>  <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>
    12061202               / &lt;entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>&gt;
    12071203</pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding
    … …  
    12101206      <p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    12111207      <p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    1212          in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
     1208         in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
    12131209         and a method that does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented
    12141210         the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response.
    … …  
    12711267         to the entity being transferred. These header fields apply only to the message being transmitted.
    12721268      </p>
    1273       <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.72"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>
     1269      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a>            ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>
    12741270                 / <a href="#header.connection" class="smpl">Connection</a>               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>
    12751271                 / <a href="#header.date" class="smpl">Date</a>                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a>
    … …  
    12881284         resource, the identifier of the resource, and the protocol version in use.
    12891285      </p>
    1290       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.73"></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;5.1</a>
     1286      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.72"></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;5.1</a>
    12911287                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1292                    / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.6"><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 4</a>
    1293                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>
     1288                   / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.4"><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 4</a>
     1289                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>
    12941290                  <a href="#core.rules" class="smpl">CRLF</a>
    12951291                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
    … …  
    12981294         The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
    12991295      </p>
    1300       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.74"></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>
     1296      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.73"></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>
    13011297</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h3>
    13021298      <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p>
    1303       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
     1299      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    13041300</pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
    13051301      <p id="rfc.section.5.1.2.p.1">The request-target is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.1</a>) and identifies the resource upon which to apply the request.
    13061302      </p>
    1307       <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#request-target" class="smpl">request-target</a>    = "*"
     1303      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.76"></span>  <a href="#request-target" class="smpl">request-target</a>    = "*"
    13081304                 / <a href="#uri" class="smpl">absolute-URI</a>
    13091305                 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
    … …  
    13131309         apply to a resource. One example would be
    13141310      </p>
    1315       <div id="rfc.figure.u.36"></div><pre class="text">    OPTIONS * HTTP/1.1
     1311      <div id="rfc.figure.u.35"></div><pre class="text">    OPTIONS * HTTP/1.1
    13161312</pre><p id="rfc.section.5.1.2.p.5">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,
    13171313         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
    … …  
    13191315         Request-Line would be:
    13201316      </p>
    1321       <div id="rfc.figure.u.37"></div><pre class="text">    GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     1317      <div id="rfc.figure.u.36"></div><pre class="text">    GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    13221318</pre><p id="rfc.section.5.1.2.p.7">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.
    13231319      </p>
    1324       <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1320      <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13251321      </p>
    13261322      <p id="rfc.section.5.1.2.p.9">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the
    … …  
    13281324         server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
    13291325      </p>
    1330       <div id="rfc.figure.u.38"></div><pre class="text">    GET /pub/WWW/TheProject.html HTTP/1.1
     1326      <div id="rfc.figure.u.37"></div><pre class="text">    GET /pub/WWW/TheProject.html HTTP/1.1
    13311327    Host: www.example.org
    13321328</pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
    … …  
    13461342      </dl>
    13471343      <p id="rfc.section.5.1.2.p.15">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 if the received request-target
    1348          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1344         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13491345      </p>
    13501346      <p id="rfc.section.5.1.2.p.16">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.
    … …  
    13731369      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
    13741370      <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
    1375       <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.78"></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;6.1</a>
     1371      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.77"></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;6.1</a>
    13761372                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1377                    / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.9"><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 6</a>
    1378                    / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>
     1373                   / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.7"><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 6</a>
     1374                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>)  ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>
    13791375                  <a href="#core.rules" class="smpl">CRLF</a>
    13801376                  [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
    … …  
    13841380         CRLF sequence.
    13851381      </p>
    1386       <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.79"></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>
     1382      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.78"></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>
    13871383</pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    13881384      <p id="rfc.section.6.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
    1389          are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.10"><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,
     1385         are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><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,
    13901386         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    13911387         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
    … …  
    14011397         <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
    14021398      </ul>
    1403       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    1404   <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a>  = *&lt;<a href="#rule.TEXT" class="smpl">TEXT</a>, excluding <a href="#core.rules" class="smpl">CR</a>, <a href="#core.rules" class="smpl">LF</a>&gt;
     1399      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
     1400  <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> )
    14051401</pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    14061402      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
    … …  
    14571453      <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.
    14581454      </p>
    1459       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><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
     1455      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><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
    14601456         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
    14611457      </p>
    … …  
    14821478      </p>
    14831479      <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
    1484          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent 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
     1480         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent 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
    14851481         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.
    14861482      </p>
    … …  
    15001496      </p>
    15011497      <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>
    1502       <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><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
     1498      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><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
    15031499         to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
    15041500         be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
    … …  
    15071503      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    15081504      <ul>
    1509          <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 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    1510          </li>
    1511          <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 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.15"><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.
     1505         <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 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     1506         </li>
     1507         <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 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><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.
    15121508         </li>
    15131509      </ul>
    … …  
    15531549         <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
    15541550            an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding
    1555             of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1551            of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    15561552         </li>
    15571553      </ul>
    … …  
    15931589      </p>
    15941590      <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p>
    1595       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></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>
     1591      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></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>
    15961592  <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
    15971593  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    … …  
    16061602         of the response. For example,
    16071603      </p>
    1608       <div id="rfc.figure.u.43"></div><pre class="text">  Connection: close
     1604      <div id="rfc.figure.u.42"></div><pre class="text">  Connection: close
    16091605</pre><p id="rfc.section.8.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.
    16101606      </p>
    … …  
    16221618         or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
    16231619      </p>
    1624       <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></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>
     1620      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></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>
    16251621  <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    16261622</pre><p id="rfc.section.8.2.p.3">An example is</p>
    1627       <div id="rfc.figure.u.45"></div><pre class="text">  Content-Length: 3495
     1623      <div id="rfc.figure.u.44"></div><pre class="text">  Content-Length: 3495
    16281624</pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section&nbsp;4.4</a>.
    16291625      </p>
    … …  
    16401636         as orig-date 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="#full.date" title="Full Date">Section&nbsp;3.2.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16411637      </p>
    1642       <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></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>
     1638      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></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>
    16431639  <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a>
    16441640</pre><p id="rfc.section.8.3.p.3">An example is</p>
    1645       <div id="rfc.figure.u.47"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
     1641      <div id="rfc.figure.u.46"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    16461642</pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    16471643      </p>
    … …  
    16791675         a single IP address.
    16801676      </p>
    1681       <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></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>
     1677      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></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>
    16821678  <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.1.1</a>
    16831679</pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
    16841680         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
    16851681      </p>
    1686       <div id="rfc.figure.u.49"></div><pre class="text">  GET /pub/WWW/ HTTP/1.1
     1682      <div id="rfc.figure.u.48"></div><pre class="text">  GET /pub/WWW/ HTTP/1.1
    16871683  Host: www.example.org
    16881684</pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name
    … …  
    16991695         and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>).
    17001696      </p>
    1701       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></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>
     1697      <div id="rfc.figure.u.49"></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.te" class="smpl">TE</a>        = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>
    17021698  <a href="#header.te" class="smpl">TE-v</a>      = #<a href="#header.te" class="smpl">t-codings</a>
    17031699  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#abnf.dependencies" class="smpl">accept-params</a> ] )
    … …  
    17061702      </p>
    17071703      <p id="rfc.section.8.5.p.4">Examples of its use are:</p>
    1708       <div id="rfc.figure.u.51"></div><pre class="text">  TE: deflate
     1704      <div id="rfc.figure.u.50"></div><pre class="text">  TE: deflate
    17091705  TE:
    17101706  TE: trailers, deflate;q=0.5
    … …  
    17251721         <li>
    17261722            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    1727                is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")
     1723               is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")
    17281724            </p>
    17291725         </li>
    … …  
    17431739         chunked transfer-coding.
    17441740      </p>
    1745       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></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>
     1741      <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></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>
    17461742  <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a>
    17471743</pre><p id="rfc.section.8.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
    … …  
    17641760         transfer-coding is a property of the message, not of the entity.
    17651761      </p>
    1766       <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>
     1762      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>
    17671763                        <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a>
    17681764  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    17691765</pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>. An example is:
    17701766      </p>
    1771       <div id="rfc.figure.u.54"></div><pre class="text">  Transfer-Encoding: chunked
     1767      <div id="rfc.figure.u.53"></div><pre class="text">  Transfer-Encoding: chunked
    17721768</pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to an entity, 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 entity-header fields not defined by this specification.
    17731769      </p>
    … …  
    17791775         to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
    17801776      </p>
    1781       <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></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>
     1777      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></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>
    17821778  <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a>
    17831779</pre><p id="rfc.section.8.8.p.3">For example,</p>
    1784       <div id="rfc.figure.u.56"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     1780      <div id="rfc.figure.u.55"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    17851781</pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
    17861782         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    … …  
    18111807         of all senders along the request/response chain.
    18121808      </p>
    1813       <div id="rfc.figure.u.57"></div><pre class="inline"><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><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></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>
     1809      <div id="rfc.figure.u.56"></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><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></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>
    18141810  <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>
    18151811                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    … …  
    18361832         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    18371833      </p>
    1838       <div id="rfc.figure.u.58"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     1834      <div id="rfc.figure.u.57"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    18391835</pre><p id="rfc.section.8.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.
    18401836      </p>
    … …  
    18421838         For example,
    18431839      </p>
    1844       <div id="rfc.figure.u.59"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     1840      <div id="rfc.figure.u.58"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    18451841</pre><p id="rfc.section.8.9.p.12">could be collapsed to</p>
    1846       <div id="rfc.figure.u.60"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     1842      <div id="rfc.figure.u.59"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    18471843</pre><p id="rfc.section.8.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
    18481844         by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    … …  
    23462342         can be interpreted unambiguously.
    23472343      </p>
    2348       <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of SP or HTAB characters between fields, even though only a single SP is required.
     2344      <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required.
    23492345      </p>
    23502346      <p id="rfc.section.A.p.3">The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing
    … …  
    23522348      </p>
    23532349      <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling
    2354          the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2350         the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    23552351      </p>
    23562352      <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>
    … …  
    24442440      <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    24452441         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    2446          computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
     2442         computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
    24472443      </p>
    24482444      <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0
    … …  
    24572453      <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    24582454      <p id="rfc.section.B.4.p.1">Rules about implicit linear white space between certain grammar productions have been removed; now it's only allowed when
    2459          specifically pointed out in the ABNF. The CHAR rule does not allow the NUL character anymore (this affects the comment and
    2460          quoted-string rules). Furthermore, the quoted-pair rule does not allow escaping NUL, CR or LF anymore. (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
     2455         specifically pointed out in the ABNF. The NUL character is no longer allowed in comment and quoted-string text. The quoted-pair
     2456         rule no longer allows escaping NUL, CR or LF. (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
    24612457      </p>
    24622458      <p id="rfc.section.B.4.p.2">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section&nbsp;3.1</a>)
    … …  
    25062502      <dl class="empty">
    25072503         <dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of
    2508             entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     2504            entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    25092505         </dd>
    25102506      </dl>
    … …  
    25122508      </p>
    25132509      <dl class="empty">
    2514          <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
     2510         <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
    25152511         </dd>
    25162512      </dl>
    … …  
    25182514      </p>
    25192515      <dl class="empty">
    2520          <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.16"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
     2516         <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
    25212517         </dd>
    25222518      </dl>
    … …  
    25652561         </dd>
    25662562      </dl>
    2567       <p id="rfc.section.C.p.16"> <span id="rfc.iref.g.108"></span>  <dfn>gateway</dfn> 
     2563      <p id="rfc.section.C.p.16"> <span id="rfc.iref.g.107"></span>  <dfn>gateway</dfn> 
    25682564      </p>
    25692565      <dl class="empty">
    … …  
    26592655      <ul>
    26602656         <li>Update media type registrations to use RFC4288 template.</li>
    2661          <li>Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF for chunk-data (work in progress on &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;)
     2657         <li>Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF for chunk-data (work in progress on &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;)
    26622658         </li>
    26632659      </ul>
    … …  
    26832679            -- these will have to be updated when switching over to RFC3986.
    26842680         </li>
    2685          <li>Synchronize core rules with RFC5234 (this includes a change to CHAR which now excludes NUL).</li>
     2681         <li>Synchronize core rules with RFC5234.</li>
    26862682         <li>Get rid of prose rules that span multiple lines.</li>
    26872683         <li>Get rid of unused rules LOALPHA and UPALPHA.</li>
    … …  
    28122808            </li>
    28132809            <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind">
    2814                   <li class="indline1">gateway&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.108">C</a></li>
     2810                  <li class="indline1">gateway&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.107">C</a></li>
    28152811                  <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
    28162812                     <ul class="ind">
    2817                         <li class="indline1"><tt>absolute-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>2.1</b></a></li>
     2813                        <li class="indline1"><tt>absolute-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>2.1</b></a></li>
    28182814                        <li class="indline1">ALPHA&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>1.2</b></a></li>
    2819                         <li class="indline1"><tt>asctime-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>3.2.1</b></a></li>
    2820                         <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.51"><b>3.3</b></a></li>
    2821                         <li class="indline1"><tt>authority</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>2.1</b></a></li>
    2822                         <li class="indline1"><tt>BWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li>
    2823                         <li class="indline1">CHAR&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li>
    2824                         <li class="indline1"><tt>chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.54"><b>3.3.1</b></a></li>
    2825                         <li class="indline1"><tt>chunk-data</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.60"><b>3.3.1</b></a></li>
    2826                         <li class="indline1"><tt>chunk-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.57"><b>3.3.1</b></a></li>
    2827                         <li class="indline1"><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.58"><b>3.3.1</b></a></li>
    2828                         <li class="indline1"><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.59"><b>3.3.1</b></a></li>
    2829                         <li class="indline1"><tt>chunk-size</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.55"><b>3.3.1</b></a></li>
    2830                         <li class="indline1"><tt>Chunked-Body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.53"><b>3.3.1</b></a></li>
    2831                         <li class="indline1"><tt>comment</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li>
    2832                         <li class="indline1"><tt>Connection</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.83"><b>8.1</b></a></li>
    2833                         <li class="indline1"><tt>connection-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.85"><b>8.1</b></a></li>
    2834                         <li class="indline1"><tt>Connection-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.84"><b>8.1</b></a></li>
    2835                         <li class="indline1"><tt>Content-Length</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.86"><b>8.2</b></a></li>
    2836                         <li class="indline1"><tt>Content-Length-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.87"><b>8.2</b></a></li>
    2837                         <li class="indline1">CR&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li>
    2838                         <li class="indline1">CRLF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li>
    2839                         <li class="indline1"><tt>ctext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li>
    2840                         <li class="indline1">CTL&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li>
    2841                         <li class="indline1"><tt>Date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.88"><b>8.3</b></a></li>
    2842                         <li class="indline1"><tt>Date-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.89"><b>8.3</b></a></li>
    2843                         <li class="indline1"><tt>date1</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>3.2.1</b></a></li>
    2844                         <li class="indline1"><tt>date2</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>3.2.1</b></a></li>
    2845                         <li class="indline1"><tt>date3</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>3.2.1</b></a></li>
    2846                         <li class="indline1">DIGIT&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li>
    2847                         <li class="indline1">DQUOTE&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li>
    2848                         <li class="indline1"><tt>extension-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.81"><b>6.1.1</b></a></li>
    2849                         <li class="indline1"><tt>extension-method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.76"><b>5.1.1</b></a></li>
    2850                         <li class="indline1"><tt>field-content</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.70"><b>4.2</b></a></li>
    2851                         <li class="indline1"><tt>field-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.68"><b>4.2</b></a></li>
    2852                         <li class="indline1"><tt>field-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.69"><b>4.2</b></a></li>
    2853                         <li class="indline1"><tt>general-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.72"><b>4.5</b></a></li>
    2854                         <li class="indline1"><tt>generic-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.65"><b>4.1</b></a></li>
    2855                         <li class="indline1">HEXDIG&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li>
    2856                         <li class="indline1"><tt>Host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.90"><b>8.4</b></a></li>
    2857                         <li class="indline1"><tt>Host-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.91"><b>8.4</b></a></li>
    2858                         <li class="indline1">HTAB&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li>
    2859                         <li class="indline1"><tt>HTTP-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>3.2.1</b></a></li>
    2860                         <li class="indline1"><tt>HTTP-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.64"><b>4.1</b></a></li>
    2861                         <li class="indline1"><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>3.1</b></a></li>
    2862                         <li class="indline1"><tt>http-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>2.1.1</b></a></li>
    2863                         <li class="indline1"><tt>HTTP-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>3.1</b></a></li>
    2864                         <li class="indline1"><tt>last-chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.56"><b>3.3.1</b></a></li>
    2865                         <li class="indline1">LF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li>
    2866                         <li class="indline1"><tt>message-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.71"><b>4.3</b></a></li>
    2867                         <li class="indline1"><tt>message-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.67"><b>4.2</b></a></li>
    2868                         <li class="indline1"><tt>Method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.75"><b>5.1.1</b></a></li>
    2869                         <li class="indline1"><tt>month</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.47"><b>3.2.1</b></a></li>
    2870                         <li class="indline1"><tt>obsolete-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>3.2.1</b></a></li>
    2871                         <li class="indline1">OCTET&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>1.2</b></a></li>
    2872                         <li class="indline1"><tt>OWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li>
    2873                         <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.50"><b>3.3</b></a></li>
    2874                         <li class="indline1"><tt>path-absolute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>2.1</b></a></li>
    2875                         <li class="indline1"><tt>port</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>2.1</b></a></li>
    2876                         <li class="indline1"><tt>product</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.62"><b>3.4</b></a></li>
    2877                         <li class="indline1"><tt>product-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.63"><b>3.4</b></a></li>
    2878                         <li class="indline1"><tt>protocol-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.104"><b>8.9</b></a></li>
    2879                         <li class="indline1"><tt>protocol-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.105"><b>8.9</b></a></li>
    2880                         <li class="indline1"><tt>pseudonym</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.107"><b>8.9</b></a></li>
    2881                         <li class="indline1"><tt>qdtext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>1.2.2</b></a></li>
    2882                         <li class="indline1"><tt>query</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>2.1</b></a></li>
    2883                         <li class="indline1"><tt>quoted-pair</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>1.2.2</b></a></li>
    2884                         <li class="indline1"><tt>quoted-string</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>1.2.2</b></a></li>
    2885                         <li class="indline1"><tt>quoted-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>1.2.2</b></a></li>
    2886                         <li class="indline1"><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.82"><b>6.1.1</b></a></li>
    2887                         <li class="indline1"><tt>received-by</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.106"><b>8.9</b></a></li>
    2888                         <li class="indline1"><tt>received-protocol</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.103"><b>8.9</b></a></li>
    2889                         <li class="indline1"><tt>Request</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.73"><b>5</b></a></li>
    2890                         <li class="indline1"><tt>Request-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.74"><b>5.1</b></a></li>
    2891                         <li class="indline1"><tt>request-target</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.77"><b>5.1.2</b></a></li>
    2892                         <li class="indline1"><tt>Response</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.78"><b>6</b></a></li>
    2893                         <li class="indline1"><tt>rfc1123-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>3.2.1</b></a></li>
    2894                         <li class="indline1"><tt>rfc850-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
    2895                         <li class="indline1"><tt>RWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li>
    2896                         <li class="indline1">SP&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>1.2</b></a></li>
    2897                         <li class="indline1"><tt>start-line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.66"><b>4.1</b></a></li>
    2898                         <li class="indline1"><tt>Status-Code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.80"><b>6.1.1</b></a></li>
    2899                         <li class="indline1"><tt>Status-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.79"><b>6.1</b></a></li>
    2900                         <li class="indline1"><tt>t-codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.94"><b>8.5</b></a></li>
    2901                         <li class="indline1"><tt>tchar</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li>
    2902                         <li class="indline1"><tt>TE</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.92"><b>8.5</b></a></li>
    2903                         <li class="indline1"><tt>TE-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.93"><b>8.5</b></a></li>
    2904                         <li class="indline1"><tt>TEXT</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li>
    2905                         <li class="indline1"><tt>time</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>3.2.1</b></a></li>
    2906                         <li class="indline1"><tt>token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li>
    2907                         <li class="indline1"><tt>Trailer</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.95"><b>8.6</b></a></li>
    2908                         <li class="indline1"><tt>trailer-part</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.61"><b>3.3.1</b></a></li>
    2909                         <li class="indline1"><tt>Trailer-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.96"><b>8.6</b></a></li>
    2910                         <li class="indline1"><tt>transfer-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.48"><b>3.3</b></a></li>
    2911                         <li class="indline1"><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.97"><b>8.7</b></a></li>
    2912                         <li class="indline1"><tt>Transfer-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.98"><b>8.7</b></a></li>
    2913                         <li class="indline1"><tt>transfer-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.49"><b>3.3</b></a></li>
    2914                         <li class="indline1"><tt>Upgrade</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.99"><b>8.8</b></a></li>
    2915                         <li class="indline1"><tt>Upgrade-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.100"><b>8.8</b></a></li>
    2916                         <li class="indline1"><tt>uri-host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>2.1</b></a></li>
    2917                         <li class="indline1"><tt>URI-reference</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>2.1</b></a></li>
    2918                         <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.52"><b>3.3</b></a></li>
    2919                         <li class="indline1"><tt>Via</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.101"><b>8.9</b></a></li>
    2920                         <li class="indline1"><tt>Via-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.102"><b>8.9</b></a></li>
    2921                         <li class="indline1"><tt>weekday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.46"><b>3.2.1</b></a></li>
    2922                         <li class="indline1"><tt>wkday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>3.2.1</b></a></li>
    2923                         <li class="indline1">WSP&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>1.2</b></a></li>
     2815                        <li class="indline1"><tt>asctime-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>3.2.1</b></a></li>
     2816                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.48"><b>3.3</b></a></li>
     2817                        <li class="indline1"><tt>authority</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>2.1</b></a></li>
     2818                        <li class="indline1"><tt>BWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li>
     2819                        <li class="indline1"><tt>chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.51"><b>3.3.1</b></a></li>
     2820                        <li class="indline1"><tt>chunk-data</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.57"><b>3.3.1</b></a></li>
     2821                        <li class="indline1"><tt>chunk-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.54"><b>3.3.1</b></a></li>
     2822                        <li class="indline1"><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.55"><b>3.3.1</b></a></li>
     2823                        <li class="indline1"><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.56"><b>3.3.1</b></a></li>
     2824                        <li class="indline1"><tt>chunk-size</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.52"><b>3.3.1</b></a></li>
     2825                        <li class="indline1"><tt>Chunked-Body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.50"><b>3.3.1</b></a></li>
     2826                        <li class="indline1"><tt>comment</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.68"><b>4.2</b></a></li>
     2827                        <li class="indline1"><tt>Connection</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.82"><b>8.1</b></a></li>
     2828                        <li class="indline1"><tt>connection-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.84"><b>8.1</b></a></li>
     2829                        <li class="indline1"><tt>Connection-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.83"><b>8.1</b></a></li>
     2830                        <li class="indline1"><tt>Content-Length</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.85"><b>8.2</b></a></li>
     2831                        <li class="indline1"><tt>Content-Length-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.86"><b>8.2</b></a></li>
     2832                        <li class="indline1">CR&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li>
     2833                        <li class="indline1">CRLF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li>
     2834                        <li class="indline1"><tt>ctext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.69"><b>4.2</b></a></li>
     2835                        <li class="indline1">CTL&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li>
     2836                        <li class="indline1"><tt>Date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.87"><b>8.3</b></a></li>
     2837                        <li class="indline1"><tt>Date-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.88"><b>8.3</b></a></li>
     2838                        <li class="indline1"><tt>date1</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>3.2.1</b></a></li>
     2839                        <li class="indline1"><tt>date2</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
     2840                        <li class="indline1"><tt>date3</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>3.2.1</b></a></li>
     2841                        <li class="indline1">DIGIT&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li>
     2842                        <li class="indline1">DQUOTE&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li>
     2843                        <li class="indline1"><tt>extension-code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.80"><b>6.1.1</b></a></li>
     2844                        <li class="indline1"><tt>extension-method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.75"><b>5.1.1</b></a></li>
     2845                        <li class="indline1"><tt>field-content</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.67"><b>4.2</b></a></li>
     2846                        <li class="indline1"><tt>field-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.65"><b>4.2</b></a></li>
     2847                        <li class="indline1"><tt>field-value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.66"><b>4.2</b></a></li>
     2848                        <li class="indline1"><tt>general-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.71"><b>4.5</b></a></li>
     2849                        <li class="indline1"><tt>generic-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.62"><b>4.1</b></a></li>
     2850                        <li class="indline1">HEXDIG&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li>
     2851                        <li class="indline1"><tt>Host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.89"><b>8.4</b></a></li>
     2852                        <li class="indline1"><tt>Host-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.90"><b>8.4</b></a></li>
     2853                        <li class="indline1"><tt>HTTP-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>3.2.1</b></a></li>
     2854                        <li class="indline1"><tt>HTTP-message</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.61"><b>4.1</b></a></li>
     2855                        <li class="indline1"><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>3.1</b></a></li>
     2856                        <li class="indline1"><tt>http-URI</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>2.1.1</b></a></li>
     2857                        <li class="indline1"><tt>HTTP-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>3.1</b></a></li>
     2858                        <li class="indline1"><tt>last-chunk</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.53"><b>3.3.1</b></a></li>
     2859                        <li class="indline1">LF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li>
     2860                        <li class="indline1"><tt>message-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.70"><b>4.3</b></a></li>
     2861                        <li class="indline1"><tt>message-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.64"><b>4.2</b></a></li>
     2862                        <li class="indline1"><tt>Method</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.74"><b>5.1.1</b></a></li>
     2863                        <li class="indline1"><tt>month</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>3.2.1</b></a></li>
     2864                        <li class="indline1"><tt>obs-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li>
     2865                        <li class="indline1"><tt>obsolete-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>3.2.1</b></a></li>
     2866                        <li class="indline1">OCTET&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li>
     2867                        <li class="indline1"><tt>OWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>1.2.2</b></a></li>
     2868                        <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.47"><b>3.3</b></a></li>
     2869                        <li class="indline1"><tt>path-absolute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>2.1</b></a></li>
     2870                        <li class="indline1"><tt>port</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>2.1</b></a></li>
     2871                        <li class="indline1"><tt>product</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.59"><b>3.4</b></a></li>
     2872                        <li class="indline1"><tt>product-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.60"><b>3.4</b></a></li>
     2873                        <li class="indline1"><tt>protocol-name</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.103"><b>8.9</b></a></li>
     2874                        <li class="indline1"><tt>protocol-version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.104"><b>8.9</b></a></li>
     2875                        <li class="indline1"><tt>pseudonym</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.106"><b>8.9</b></a></li>
     2876                        <li class="indline1"><tt>qdtext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li>
     2877                        <li class="indline1"><tt>query</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>2.1</b></a></li>
     2878                        <li class="indline1"><tt>quoted-pair</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>1.2.2</b></a></li>
     2879                        <li class="indline1"><tt>quoted-string</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li>
     2880                        <li class="indline1"><tt>quoted-text</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li>
     2881                        <li class="indline1"><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.81"><b>6.1.1</b></a></li>
     2882                        <li class="indline1"><tt>received-by</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.105"><b>8.9</b></a></li>
     2883                        <li class="indline1"><tt>received-protocol</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.102"><b>8.9</b></a></li>
     2884                        <li class="indline1"><tt>Request</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.72"><b>5</b></a></li>
     2885                        <li class="indline1"><tt>Request-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.73"><b>5.1</b></a></li>
     2886                        <li class="indline1"><tt>request-target</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.76"><b>5.1.2</b></a></li>
     2887                        <li class="indline1"><tt>Response</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.77"><b>6</b></a></li>
     2888                        <li class="indline1"><tt>rfc1123-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>3.2.1</b></a></li>
     2889                        <li class="indline1"><tt>rfc850-date</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>3.2.1</b></a></li>
     2890                        <li class="indline1"><tt>RWS</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li>
     2891                        <li class="indline1">SP&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li>
     2892                        <li class="indline1"><tt>start-line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.63"><b>4.1</b></a></li>
     2893                        <li class="indline1"><tt>Status-Code</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.79"><b>6.1.1</b></a></li>
     2894                        <li class="indline1"><tt>Status-Line</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.78"><b>6.1</b></a></li>
     2895                        <li class="indline1"><tt>t-codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.93"><b>8.5</b></a></li>
     2896                        <li class="indline1"><tt>tchar</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li>
     2897                        <li class="indline1"><tt>TE</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.91"><b>8.5</b></a></li>
     2898                        <li class="indline1"><tt>TE-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.92"><b>8.5</b></a></li>
     2899                        <li class="indline1"><tt>time</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>3.2.1</b></a></li>
     2900                        <li class="indline1"><tt>token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li>
     2901                        <li class="indline1"><tt>Trailer</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.94"><b>8.6</b></a></li>
     2902                        <li class="indline1"><tt>trailer-part</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.58"><b>3.3.1</b></a></li>
     2903                        <li class="indline1"><tt>Trailer-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.95"><b>8.6</b></a></li>
     2904                        <li class="indline1"><tt>transfer-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>3.3</b></a></li>
     2905                        <li class="indline1"><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.96"><b>8.7</b></a></li>
     2906                        <li class="indline1"><tt>Transfer-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.97"><b>8.7</b></a></li>
     2907                        <li class="indline1"><tt>transfer-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.46"><b>3.3</b></a></li>
     2908                        <li class="indline1"><tt>Upgrade</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.98"><b>8.8</b></a></li>
     2909                        <li class="indline1"><tt>Upgrade-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.99"><b>8.8</b></a></li>
     2910                        <li class="indline1"><tt>uri-host</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>2.1</b></a></li>
     2911                        <li class="indline1"><tt>URI-reference</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>2.1</b></a></li>
     2912                        <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.49"><b>3.3</b></a></li>
     2913                        <li class="indline1">VCHAR&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>1.2</b></a></li>
     2914                        <li class="indline1"><tt>Via</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.100"><b>8.9</b></a></li>
     2915                        <li class="indline1"><tt>Via-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.101"><b>8.9</b></a></li>
     2916                        <li class="indline1"><tt>weekday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>3.2.1</b></a></li>
     2917                        <li class="indline1"><tt>wkday</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>3.2.1</b></a></li>
     2918                        <li class="indline1">WSP&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>1.2</b></a></li>
    29242919                     </ul>
    29252920                  </li>
    … …  
    29472942            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
    29482943                  <li class="indline1">inbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">C</a></li>
    2949                   <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">1.2.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li>
     2944                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">4.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li>
    29502945               </ul>
    29512946            </li>
    … …  
    29762971            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    29772972                  <li class="indline1"><em>Pad1995</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li>
    2978                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.3</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a>, <a class="iref" href="#rfc.xref.Part2.7">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">
    2979                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">4.3</a></li>
    2980                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a></li>
    2981                         <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li>
    2982                         <li class="indline1"><em>Section 8.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a></li>
    2983                         <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.7">5.1.2</a></li>
    2984                         <li class="indline1"><em>Section 9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.10">6.1.1</a></li>
    2985                         <li class="indline1"><em>Section 9.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
    2986                         <li class="indline1"><em>Section 9.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.16">7.2.3</a></li>
    2987                         <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">5.1.2</a></li>
    2988                         <li class="indline1"><em>Section 10.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a></li>
     2973                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.3</a>, <a class="iref" href="#rfc.xref.Part2.4">5</a>, <a class="iref" href="#rfc.xref.Part2.5">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a>, <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">
     2974                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">4.3</a></li>
     2975                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">5</a></li>
     2976                        <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li>
     2977                        <li class="indline1"><em>Section 8.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li>
     2978                        <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">5.1.2</a></li>
     2979                        <li class="indline1"><em>Section 9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li>
     2980                        <li class="indline1"><em>Section 9.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
     2981                        <li class="indline1"><em>Section 9.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li>
     2982                        <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li>
     2983                        <li class="indline1"><em>Section 10.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
    29892984                     </ul>
    29902985                  </li>
    2991                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">A</a>, <a class="iref" href="#rfc.xref.Part3.13">B.3</a>, <a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a>, <a class="iref" href="#rfc.xref.Part3.16">C</a><ul class="ind">
     2986                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a>, <a class="iref" href="#rfc.xref.Part3.8">5</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a>, <a class="iref" href="#rfc.xref.Part3.12">B.3</a>, <a class="iref" href="#rfc.xref.Part3.13">C</a>, <a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a><ul class="ind">
    29922987                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a></li>
    29932988                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li>
    2994                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.5</a></li>
    2995                         <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li>
    2996                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.14">C</a></li>
     2989                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">8.5</a></li>
     2990                        <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">5</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a></li>
     2991                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.13">C</a></li>
    29972992                        <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.3</a></li>
    2998                         <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.15">C</a>, <a class="iref" href="#rfc.xref.Part3.16">C</a></li>
     2993                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a></li>
    29992994                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li>
    30002995                        <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
    … …  
    30233018                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>
    30243019                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.3</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li>
    3025                   <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">1.2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li>
     3020                  <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">4.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li>
    30263021                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.5">11</a>, <a class="iref" href="#RFC2068"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.6">B</a>, <a class="iref" href="#rfc.xref.RFC2068.7">B.2</a><ul class="ind">
    30273022                        <li class="indline1"><em>Section 19.7.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.6">B</a></li>
    … …  
    30883083                     </ul>
    30893084                  </li>
    3090                   <li class="indline1"><em>USASCII</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#USASCII"><b>12.1</b></a></li>
     3085                  <li class="indline1"><em>USASCII</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#rfc.xref.USASCII.2">4.2</a>, <a class="iref" href="#USASCII"><b>12.1</b></a></li>
    30913086                  <li class="indline1">user agent&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.4">C</a></li>
    30923087               </ul>

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

    r391 r395  
    304304<section title="Syntax Notation" anchor="notation">
    305305<iref primary="true" item="Grammar" subitem="ALPHA"/>
    306 <iref primary="true" item="Grammar" subitem="CHAR"/>
    307306<iref primary="true" item="Grammar" subitem="CR"/>
    308307<iref primary="true" item="Grammar" subitem="CRLF"/>
    … …  
    311310<iref primary="true" item="Grammar" subitem="DQUOTE"/>
    312311<iref primary="true" item="Grammar" subitem="HEXDIG"/>
    313 <iref primary="true" item="Grammar" subitem="HTAB"/>
    314312<iref primary="true" item="Grammar" subitem="LF"/>
    315313<iref primary="true" item="Grammar" subitem="OCTET"/>
    316314<iref primary="true" item="Grammar" subitem="SP"/>
     315<iref primary="true" item="Grammar" subitem="VCHAR"/>
    317316<iref primary="true" item="Grammar" subitem="WSP"/>
    318317<t anchor="core.rules">
    319318  <x:anchor-alias value="ALPHA"/>
    320   <x:anchor-alias value="CHAR"/>
    321319  <x:anchor-alias value="CTL"/>
    322320  <x:anchor-alias value="CR"/>
    … …  
    325323  <x:anchor-alias value="DQUOTE"/>
    326324  <x:anchor-alias value="HEXDIG"/>
    327   <x:anchor-alias value="HTAB"/>
    328325  <x:anchor-alias value="LF"/>
    329326  <x:anchor-alias value="OCTET"/>
    330327  <x:anchor-alias value="SP"/>
     328  <x:anchor-alias value="VCHAR"/>
    331329  <x:anchor-alias value="WSP"/>
    332330   This specification uses the Augmented Backus-Naur Form (ABNF) notation
    333331   of <xref target="RFC5234"/>.  The following core rules are included by
    334332   reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
    335    ALPHA (letters), CHAR (any <xref target="USASCII"/> character,
    336    excluding NUL), CR (carriage return), CRLF (CR LF), CTL (controls),
     333   ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
    337334   DIGIT (decimal 0-9), DQUOTE (double quote),
    338    HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab),
    339    LF (line feed), OCTET (any 8-bit sequence of data), SP (space)
     335   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
     336   OCTET (any 8-bit sequence of data), SP (space),
     337   VCHAR (any visible <xref target="USASCII"/> character),
    340338   and WSP (white space).
    341339</t>
    … …  
    388386</t>
    389387<t anchor="rule.LWS">
    390    All linear white space (LWS) in header field-values has the same semantics as SP. A
    391    recipient &MAY; replace any such linear white space with a single SP before
     388   This specification uses three rules to denote the use of linear
     389   whitespace: OWS (optional whitespace), RWS (required whitespace), and
     390   BWS ("bad" whitespace).
     391</t>
     392<t>
     393   The OWS rule is used where zero or more linear white space characters may
     394   appear. OWS &SHOULD; either not be produced or be produced as a single SP
     395   character. Multiple OWS characters that occur within field-content &SHOULD;
     396   be replaced with a single SP before interpreting the field value or
     397   forwarding the message downstream.
     398</t>
     399<t>
     400   RWS is used when at least one linear white space character is required to
     401   separate field tokens. RWS &SHOULD; be produced as a single SP character.
     402   Multiple RWS characters that occur within field-content &SHOULD; be
     403   replaced with a single SP before interpreting the field value or
     404   forwarding the message downstream.
     405</t>
     406<t>
     407   BWS is used where the grammar allows optional whitespace for historical
     408   reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1
     409   recipients &MUST; accept such bad optional whitespace and remove it before
    392410   interpreting the field value or forwarding the message downstream.
    393 </t>
    394 <t>
    395    Historically, HTTP/1.1 header field values allow linear white space folding across
    396    multiple lines. However, this specification deprecates its use; senders &MUST-NOT;
    397    produce messages that include LWS folding (i.e., use the obs-fold rule), except
    398    within the message/http media type (<xref target="internet.media.type.message.http"/>).
    399    Receivers &SHOULD; still parse folded linear white space.
    400 </t>
    401 <t>
    402    This specification uses three rules to denote the use of linear white space;
    403    BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space).
    404 </t>
    405 <t>
    406    "Bad" white space is allowed by the BNF, but senders &SHOULD-NOT; produce it in messages.
    407    Receivers &MUST; accept it in incoming messages.
    408 </t>
    409 <t>
    410    Required white space is used when at least one linear white space character
    411    is required to separate field tokens. In all such cases, a single SP character
    412    &SHOULD; be used.
    413411</t>
    414412<t anchor="rule.whitespace">
    … …  
    427425  <x:ref>obs-fold</x:ref>       = <x:ref>CRLF</x:ref>
    428426</artwork></figure>
    429 <t anchor="rule.TEXT">
    430   <x:anchor-alias value="TEXT"/>
    431    The TEXT rule is only used for descriptive field contents and values
    432    that are not intended to be interpreted by the message parser. Words
    433    of *TEXT &MAY; contain characters from character sets other than ISO-8859-1
    434    <xref target="ISO-8859-1"/> only when encoded according to the rules of
    435    <xref target="RFC2047"/>.
    436 </t>
    437 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TEXT"/>
    438   <x:ref>TEXT</x:ref>           = %x20-7E / %x80-FF / <x:ref>OWS</x:ref>
    439                  ; any <x:ref>OCTET</x:ref> except <x:ref>CTL</x:ref>s, but including <x:ref>OWS</x:ref>
    440 </artwork></figure>
    441 <t>
    442    A CRLF is allowed in the definition of TEXT only as part of a header
    443    field continuation. It is expected that the folding LWS will be
    444    replaced with a single SP before interpretation of the TEXT value.
    445 </t>
    446427<t anchor="rule.token.separators">
    447428  <x:anchor-alias value="tchar"/>
    448429  <x:anchor-alias value="token"/>
    449    Many HTTP/1.1 header field values consist of words separated by LWS
     430   Many HTTP/1.1 header field values consist of words separated by whitespace
    450431   or special characters. These special characters &MUST; be in a quoted
    451432   string to be used within a parameter value (as defined in
    … …  
    459440  <x:ref>token</x:ref>          = 1*<x:ref>tchar</x:ref>
    460441</artwork></figure>
    461 <t anchor="rule.comment">
    462   <x:anchor-alias value="comment"/>
    463   <x:anchor-alias value="ctext"/>
    464    Comments can be included in some HTTP header fields by surrounding
    465    the comment text with parentheses. Comments are only allowed in
    466    fields containing "comment" as part of their field value definition.
    467    In all other fields, parentheses are considered part of the field
    468    value.
    469 </t>
    470 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>
    471   <x:ref>comment</x:ref>        = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-pair</x:ref> / <x:ref>comment</x:ref> ) ")"
    472   <x:ref>ctext</x:ref>          = &lt;any <x:ref>TEXT</x:ref> excluding "(" and ")"&gt;
    473 </artwork></figure>
    474442<t anchor="rule.quoted-string">
    475443  <x:anchor-alias value="quoted-string"/>
    476444  <x:anchor-alias value="qdtext"/>
     445  <x:anchor-alias value="obs-text"/>
    477446   A string of text is parsed as a single word if it is quoted using
    478447   double-quote marks.
    479448</t>
    480 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/>
     449<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/>
    481450  <x:ref>quoted-string</x:ref>  = <x:ref>DQUOTE</x:ref> *(<x:ref>qdtext</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref>
    482   <x:ref>qdtext</x:ref>         = &lt;any <x:ref>TEXT</x:ref> excluding <x:ref>DQUOTE</x:ref> and "\">
     451  <x:ref>qdtext</x:ref>         = *( <x:ref>OWS</x:ref> / %x21 / %x23-5B / %x5D-7E / <x:ref>obs-text</x:ref> )
     452  <x:ref>obs-text</x:ref>       = %x80-FF
    483453</artwork></figure>
    484454<t anchor="rule.quoted-pair">
    … …  
    564534</t>
    565535<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/>
    566   <x:ref>URI</x:ref>           = &lt;URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/>>
    567   <x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/>>
    568   <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
    569   <x:ref>relative-part</x:ref> = &lt;relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>>
    570   <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>
    571   <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>
    572   <x:ref>path-abempty</x:ref>  = &lt;path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
    573   <x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
    574   <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>>
    575   <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>
    576   <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>>
     536  <x:ref>URI</x:ref>           = &lt;URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/>&gt;
     537  <x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/>&gt;
     538  <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>&gt;
     539  <x:ref>relative-part</x:ref> = &lt;relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>&gt;
     540  <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>&gt;
     541  <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>&gt;
     542  <x:ref>path-abempty</x:ref>  = &lt;path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>&gt;
     543  <x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>&gt;
     544  <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>&gt;
     545  <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>&gt;
     546  <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>&gt;
    577547 
    578548  <x:ref>partial-URI</x:ref>   = relative-part [ "?" query ]
    … …  
    906876   abbreviation for time zone, and &MUST; be assumed when reading the
    907877   asctime format. HTTP-date is case sensitive and &MUST-NOT; include
    908    additional LWS beyond that specifically included as SP in the
     878   additional whitespace beyond that specifically included as SP in the
    909879   grammar.
    910880</t>
    … …  
    12111181   extra CRLF.
    12121182</t>
     1183<t>
     1184   Whitespace (WSP) &MUST-NOT; be sent between the start-line and the first
     1185   header field. The presence of whitespace might be an attempt to trick a
     1186   noncompliant implementation of HTTP into ignoring that field or processing
     1187   the next line as a new request, either of which may result in security
     1188   issues when implementations within the request chain interpret the
     1189   same message differently. HTTP/1.1 servers &MUST; reject such a message
     1190   with a 400 (Bad Request) response.
     1191</t>
    12131192</section>
    12141193
    … …  
    12191198  <x:anchor-alias value="message-header"/>
    12201199<t>
    1221    HTTP header fields, which include general-header (<xref target="general.header.fields"/>),
    1222    request-header (&request-header-fields;), response-header (&response-header-fields;), and
    1223    entity-header (&entity-header-fields;) fields, follow the same generic format as
    1224    that given in <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists
    1225    of a name followed by a colon (":") and the field value. Field names
    1226    are case-insensitive. The field value &MAY; be preceded by any amount
    1227    of LWS, though a single SP is preferred. Header fields can be
    1228    extended over multiple lines by preceding each extra line with at
    1229    least one SP or HTAB. Applications ought to follow "common form", where
    1230    one is known or indicated, when generating HTTP constructs, since
    1231    there might exist some implementations that fail to accept anything
    1232    beyond the common forms.
     1200   HTTP header fields follow the same general format as Internet messages in
     1201   <xref target="RFC5322" x:fmt="of" x:sec="2.1"/>. Each header field consists
     1202   of a name followed by a colon (":"), optional whitespace, and the field
     1203   value. Field names are case-insensitive.
    12331204</t>
    12341205<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/>
    1235   <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" [ <x:ref>field-value</x:ref> ]
     1206  <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" OWS [ <x:ref>field-value</x:ref> ] OWS
    12361207  <x:ref>field-name</x:ref>     = <x:ref>token</x:ref>
    12371208  <x:ref>field-value</x:ref>    = *( <x:ref>field-content</x:ref> / <x:ref>OWS</x:ref> )
    1238   <x:ref>field-content</x:ref>  = &lt;field content&gt;
    1239 </artwork></figure>
    1240 <t>
    1241   <cref>whitespace between field-name and colon is an error and MUST NOT be accepted</cref>
    1242 </t>
    1243 <t>
    1244    The field-content does not include any leading or trailing LWS:
    1245    linear white space occurring before the first non-whitespace
    1246    character of the field-value or after the last non-whitespace
    1247    character of the field-value. Such leading or trailing LWS &MAY; be
    1248    removed without changing the semantics of the field value. Any LWS
    1249    that occurs between field-content &MAY; be replaced with a single SP
    1250    before interpreting the field value or forwarding the message
    1251    downstream.
    1252 </t>
     1209  <x:ref>field-content</x:ref>  = *( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> )
     1210</artwork></figure>
     1211<t>
     1212   Historically, HTTP has allowed field-content with text in the ISO-8859-1
     1213   <xref target="ISO-8859-1"/> character encoding (allowing other character sets
     1214   through use of <xref target="RFC2047"/> encoding). In practice, most HTTP
     1215   header field-values use only a subset of the US-ASCII charset
     1216   <xref target="USASCII"/>. Newly defined header fields &SHOULD; constrain
     1217   their field-values to US-ASCII characters. Recipients &SHOULD; treat other
     1218   (obs-text) octets in field-content as opaque data.
     1219</t>
     1220<t>
     1221   No whitespace is allowed between the header field-name and colon. For
     1222   security reasons, any request message received containing such whitespace
     1223   &MUST; be rejected with a response code of 400 (Bad Request) and any such
     1224   whitespace in a response message &MUST; be removed.
     1225</t>
     1226<t>
     1227   The field value &MAY; be preceded by optional white space; a single SP is
     1228   preferred. The field-value does not include any leading or trailing white
     1229   space: OWS occurring before the first non-whitespace character of the
     1230   field-value or after the last non-whitespace character of the field-value
     1231   is ignored and &MAY; be removed without changing the meaning of the header
     1232   field.
     1233</t>
     1234<t>
     1235   Historically, HTTP header field values could be extended over multiple
     1236   lines by preceding each extra line with at least one space or horizontal
     1237   tab character (line folding). This specification deprecates such line
     1238   folding except within the message/http media type
     1239   (<xref target="internet.media.type.message.http"/>).
     1240   HTTP/1.1 senders &MUST-NOT; produce messages that include line folding
     1241   (i.e., that contain any field-content that matches the obs-fold rule) unless
     1242   the message is intended for packaging within the message/http media type.
     1243   HTTP/1.1 recipients &SHOULD; accept line folding and replace any embedded
     1244   obs-fold whitespace with a single SP prior to interpreting the field value
     1245   or forwarding the message downstream.
     1246</t>
     1247<t anchor="rule.comment">
     1248  <x:anchor-alias value="comment"/>
     1249  <x:anchor-alias value="ctext"/>
     1250   Comments can be included in some HTTP header fields by surrounding
     1251   the comment text with parentheses. Comments are only allowed in
     1252   fields containing "comment" as part of their field value definition.
     1253   In all other fields, parentheses are considered part of the field
     1254   value.
     1255</t>
     1256<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>
     1257  <x:ref>comment</x:ref>        = "(" *( <x:ref>ctext</x:ref> / <x:ref>quoted-pair</x:ref> / <x:ref>comment</x:ref> ) ")"
     1258  <x:ref>ctext</x:ref>          = *( <x:ref>OWS</x:ref> / %x21-27 / %x2A-7E / <x:ref>obs-text</x:ref> )
     1259</artwork></figure>
    12531260<t>
    12541261   The order in which header fields with differing field names are
    … …  
    16921699<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/>
    16931700  <x:ref>Status-Code</x:ref>    = 3<x:ref>DIGIT</x:ref>
    1694   <x:ref>Reason-Phrase</x:ref>  = *&lt;<x:ref>TEXT</x:ref>, excluding <x:ref>CR</x:ref>, <x:ref>LF</x:ref>&gt;
     1701  <x:ref>Reason-Phrase</x:ref>  = *( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> )
    16951702</artwork></figure>
    16961703</section>
    … …  
    38653872   Clients &SHOULD; be tolerant in parsing the Status-Line and servers
    38663873   tolerant when parsing the Request-Line. In particular, they &SHOULD;
    3867    accept any amount of SP or HTAB characters between fields, even though
     3874   accept any amount of WSP characters between fields, even though
    38683875   only a single SP is required.
    38693876</t>
    … …  
    40774084  Rules about implicit linear white space between certain grammar productions
    40784085  have been removed; now it's only allowed when specifically pointed out
    4079   in the ABNF.
    4080   The CHAR rule does not allow the NUL character anymore (this affects
    4081   the comment and quoted-string rules).  Furthermore, the quoted-pair
    4082   rule does not allow escaping NUL, CR or LF anymore.
     4086  in the ABNF. The NUL character is no longer allowed in comment and quoted-string
     4087  text. The quoted-pair rule no longer allows escaping NUL, CR or LF.
    40834088  (<xref target="basic.rules"/>)
    40844089</t>
    … …  
    44634468    </t>
    44644469    <t>
    4465       Use names of RFC4234 core rules DQUOTE and HTAB,
     4470      Use names of RFC4234 core rules DQUOTE and WSP,
    44664471      fix broken ABNF for chunk-data
    44674472      (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>)
    … …  
    45104515    </t>
    45114516    <t>
    4512       Synchronize core rules with RFC5234 (this includes a change to CHAR
    4513       which now excludes NUL).
     4517      Synchronize core rules with RFC5234.
    45144518    </t>
    45154519    <t>

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

    r391 r395  
    485485         <tr>
    486486            <td class="header left"></td>
    487             <td class="header right">November 15, 2008</td>
     487            <td class="header right">November 14, 2008</td>
    488488         </tr>
    489489      </table>
    … …  
    10891089      <p id="rfc.section.7.3.p.2">If the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this
    10901090         outgoing response. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache <em class="bcp14">MAY</em> combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body
    1091          of this outgoing response, (see <a href="p5-range.html#combining.byte.ranges" title="Combining Byte Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).
     1091         of this outgoing response, (see <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).
    10921092      </p>
    10931093      <p id="rfc.section.7.3.p.3">The end-to-end headers stored in the cache entry are used for the constructed response, except that </p>
    … …  
    11561156      </p>
    11571157      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></h1>
    1158       <p id="rfc.section.10.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Byte Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code.
     1158      <p id="rfc.section.10.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 5</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code.
    11591159         A cache <em class="bcp14">MUST NOT</em> return a partial response using a status code of 200 (OK).
    11601160      </p>
    … …  
    19511951      <p id="rfc.section.B.2.p.2">Other changes: </p>
    19521952      <ul>
    1953          <li>Use names of RFC4234 core rules DQUOTE and HTAB (work in progress on &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;)
     1953         <li>Use names of RFC4234 core rule DQUOTE (work in progress on &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;)
    19541954         </li>
    19551955      </ul>

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

    r391 r395  
    29832983  <list style="symbols">
    29842984    <t>
    2985       Use names of RFC4234 core rules DQUOTE and HTAB (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>)
     2985      Use names of RFC4234 core rule DQUOTE (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>)
    29862986    </t>
    29872987  </list>
Note: See TracChangeset for help on using the changeset viewer.