Ignore:
Timestamp:
02/09/11 22:37:07 (12 years ago)
Author:
fielding@…
Message:

(editorial) Remove sections and ABNF defining Request and Response and
move status code semantics to p2. Add more xrefs to architecture intro.

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/httpbis.abnf

    r1425 r1435  
    5252Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
    5353Referer = absolute-URI / partial-URI
    54 Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
    5554Request-Line = Method SP request-target SP HTTP-Version CRLF
    56 Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
    5755Retry-After = HTTP-date / delta-seconds
    5856Server = product *( RWS ( product / comment ) )
    … …  
    270268; Range defined but not used
    271269; Referer defined but not used
    272 ; Request defined but not used
    273 ; Response defined but not used
    274270; Retry-After defined but not used
    275271; Server defined but not used

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

    r1434 r1435  
    384384      <link rel="Chapter" title="2 Architecture" href="#rfc.section.2">
    385385      <link rel="Chapter" title="3 Message Format" href="#rfc.section.3">
    386       <link rel="Chapter" title="4 Request" href="#rfc.section.4">
    387       <link rel="Chapter" title="5 Response" href="#rfc.section.5">
    388       <link rel="Chapter" title="6 Protocol Parameters" href="#rfc.section.6">
    389       <link rel="Chapter" title="7 Connections" href="#rfc.section.7">
    390       <link rel="Chapter" title="8 Miscellaneous notes that might disappear" href="#rfc.section.8">
    391       <link rel="Chapter" title="9 Header Field Definitions" href="#rfc.section.9">
    392       <link rel="Chapter" title="10 IANA Considerations" href="#rfc.section.10">
    393       <link rel="Chapter" title="11 Security Considerations" href="#rfc.section.11">
    394       <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12">
    395       <link rel="Chapter" href="#rfc.section.13" title="13 References">
     386      <link rel="Chapter" title="4 Message Routing" href="#rfc.section.4">
     387      <link rel="Chapter" title="5 Protocol Parameters" href="#rfc.section.5">
     388      <link rel="Chapter" title="6 Connections" href="#rfc.section.6">
     389      <link rel="Chapter" title="7 Miscellaneous notes that might disappear" href="#rfc.section.7">
     390      <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8">
     391      <link rel="Chapter" title="9 IANA Considerations" href="#rfc.section.9">
     392      <link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10">
     393      <link rel="Chapter" title="11 Acknowledgments" href="#rfc.section.11">
     394      <link rel="Chapter" href="#rfc.section.12" title="12 References">
    396395      <link rel="Appendix" title="A HTTP Version History" href="#rfc.section.A">
    397396      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    … …  
    571570         <li>3.&nbsp;&nbsp;&nbsp;<a href="#http.message">Message Format</a><ul>
    572571               <li>3.1&nbsp;&nbsp;&nbsp;<a href="#start.line">Start Line</a><ul>
    573                      <li>3.1.1&nbsp;&nbsp;&nbsp;<a href="#request-line">Request-Line</a><ul>
     572                     <li>3.1.1&nbsp;&nbsp;&nbsp;<a href="#request.line">Request-Line</a><ul>
    574573                           <li>3.1.1.1&nbsp;&nbsp;&nbsp;<a href="#method">Method</a></li>
    575574                           <li>3.1.1.2&nbsp;&nbsp;&nbsp;<a href="#request-target">request-target</a></li>
    576575                        </ul>
    577576                     </li>
    578                      <li>3.1.2&nbsp;&nbsp;&nbsp;<a href="#status-line">Status-Line</a><ul>
     577                     <li>3.1.2&nbsp;&nbsp;&nbsp;<a href="#status.line">Response Status-Line</a><ul>
    579578                           <li>3.1.2.1&nbsp;&nbsp;&nbsp;<a href="#status.code">Status Code</a></li>
    580579                           <li>3.1.2.2&nbsp;&nbsp;&nbsp;<a href="#reason.phrase">Reason Phrase</a></li>
    … …  
    594593            </ul>
    595594         </li>
    596          <li>4.&nbsp;&nbsp;&nbsp;<a href="#request">Request</a><ul>
     595         <li>4.&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul>
    597596               <li>4.1&nbsp;&nbsp;&nbsp;<a href="#request-target-types">Types of Request Target</a></li>
    598597               <li>4.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
    … …  
    600599            </ul>
    601600         </li>
    602          <li>5.&nbsp;&nbsp;&nbsp;<a href="#response">Response</a></li>
    603          <li>6.&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul>
    604                <li>6.1&nbsp;&nbsp;&nbsp;<a href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></li>
    605                <li>6.2&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
    606                      <li>6.2.1&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></li>
    607                      <li>6.2.2&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
    608                            <li>6.2.2.1&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
    609                            <li>6.2.2.2&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
    610                            <li>6.2.2.3&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
     601         <li>5.&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul>
     602               <li>5.1&nbsp;&nbsp;&nbsp;<a href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></li>
     603               <li>5.2&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
     604                     <li>5.2.1&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></li>
     605                     <li>5.2.2&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
     606                           <li>5.2.2.1&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
     607                           <li>5.2.2.2&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
     608                           <li>5.2.2.3&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
    611609                        </ul>
    612610                     </li>
    613                      <li>6.2.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
     611                     <li>5.2.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
    614612                  </ul>
    615613               </li>
    616                <li>6.3&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
    617                <li>6.4&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
     614               <li>5.3&nbsp;&nbsp;&nbsp;<a href="#product.tokens">Product Tokens</a></li>
     615               <li>5.4&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
    618616            </ul>
    619617         </li>
    620          <li>7.&nbsp;&nbsp;&nbsp;<a href="#connections">Connections</a><ul>
    621                <li>7.1&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
    622                      <li>7.1.1&nbsp;&nbsp;&nbsp;<a href="#persistent.purpose">Purpose</a></li>
    623                      <li>7.1.2&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
    624                            <li>7.1.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
    625                            <li>7.1.2.2&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     618         <li>6.&nbsp;&nbsp;&nbsp;<a href="#connections">Connections</a><ul>
     619               <li>6.1&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul>
     620                     <li>6.1.1&nbsp;&nbsp;&nbsp;<a href="#persistent.purpose">Purpose</a></li>
     621                     <li>6.1.2&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul>
     622                           <li>6.1.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
     623                           <li>6.1.2.2&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    626624                        </ul>
    627625                     </li>
    628                      <li>7.1.3&nbsp;&nbsp;&nbsp;<a href="#persistent.proxy">Proxy Servers</a><ul>
    629                            <li>7.1.3.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></li>
    630                            <li>7.1.3.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li>
     626                     <li>6.1.3&nbsp;&nbsp;&nbsp;<a href="#persistent.proxy">Proxy Servers</a><ul>
     627                           <li>6.1.3.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></li>
     628                           <li>6.1.3.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li>
    631629                        </ul>
    632630                     </li>
    633                      <li>7.1.4&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
     631                     <li>6.1.4&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
    634632                  </ul>
    635633               </li>
    636                <li>7.2&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>
    637                      <li>7.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
    638                      <li>7.2.2&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
    639                      <li>7.2.3&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
    640                      <li>7.2.4&nbsp;&nbsp;&nbsp;<a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li>
     634               <li>6.2&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul>
     635                     <li>6.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
     636                     <li>6.2.2&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
     637                     <li>6.2.3&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
     638                     <li>6.2.4&nbsp;&nbsp;&nbsp;<a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li>
    641639                  </ul>
    642640               </li>
    643641            </ul>
    644642         </li>
    645          <li>8.&nbsp;&nbsp;&nbsp;<a href="#misc">Miscellaneous notes that might disappear</a><ul>
    646                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#scheme.aliases">Scheme aliases considered harmful</a></li>
    647                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#http.proxy">Use of HTTP for proxy communication</a></li>
    648                <li>8.3&nbsp;&nbsp;&nbsp;<a href="#http.intercept">Interception of HTTP for access control</a></li>
    649                <li>8.4&nbsp;&nbsp;&nbsp;<a href="#http.others">Use of HTTP by other protocols</a></li>
    650                <li>8.5&nbsp;&nbsp;&nbsp;<a href="#http.media">Use of HTTP by media type specification</a></li>
     643         <li>7.&nbsp;&nbsp;&nbsp;<a href="#misc">Miscellaneous notes that might disappear</a><ul>
     644               <li>7.1&nbsp;&nbsp;&nbsp;<a href="#scheme.aliases">Scheme aliases considered harmful</a></li>
     645               <li>7.2&nbsp;&nbsp;&nbsp;<a href="#http.proxy">Use of HTTP for proxy communication</a></li>
     646               <li>7.3&nbsp;&nbsp;&nbsp;<a href="#http.intercept">Interception of HTTP for access control</a></li>
     647               <li>7.4&nbsp;&nbsp;&nbsp;<a href="#http.others">Use of HTTP by other protocols</a></li>
     648               <li>7.5&nbsp;&nbsp;&nbsp;<a href="#http.media">Use of HTTP by media type specification</a></li>
    651649            </ul>
    652650         </li>
    653          <li>9.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    654                <li>9.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    655                <li>9.2&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
    656                <li>9.3&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a><ul>
    657                      <li>9.3.1&nbsp;&nbsp;&nbsp;<a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li>
     651         <li>8.&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
     652               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
     653               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
     654               <li>8.3&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a><ul>
     655                     <li>8.3.1&nbsp;&nbsp;&nbsp;<a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li>
    658656                  </ul>
    659657               </li>
    660                <li>9.4&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    661                <li>9.5&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
    662                <li>9.6&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
    663                <li>9.7&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
    664                <li>9.8&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
    665                      <li>9.8.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
     658               <li>8.4&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
     659               <li>8.5&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
     660               <li>8.6&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
     661               <li>8.7&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
     662               <li>8.8&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
     663                     <li>8.8.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    666664                  </ul>
    667665               </li>
    668                <li>9.9&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     666               <li>8.9&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    669667            </ul>
    670668         </li>
    671          <li>10.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    672                <li>10.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    673                <li>10.2&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li>
    674                <li>10.3&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registrations</a><ul>
    675                      <li>10.3.1&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>
    676                      <li>10.3.2&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>
     669         <li>9.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     670               <li>9.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     671               <li>9.2&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li>
     672               <li>9.3&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registrations</a><ul>
     673                     <li>9.3.1&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>
     674                     <li>9.3.2&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>
    677675                  </ul>
    678676               </li>
    679                <li>10.4&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registry</a></li>
    680                <li>10.5&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
     677               <li>9.4&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registry</a></li>
     678               <li>9.5&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
    681679            </ul>
    682680         </li>
    683          <li>11.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    684                <li>11.1&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
    685                <li>11.2&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
    686                <li>11.3&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
    687                <li>11.4&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
    688                <li>11.5&nbsp;&nbsp;&nbsp;<a href="#attack.proxies">Proxies and Caching</a></li>
    689                <li>11.6&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li>
    690                <li>11.7&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
     681         <li>10.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
     682               <li>10.1&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
     683               <li>10.2&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
     684               <li>10.3&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
     685               <li>10.4&nbsp;&nbsp;&nbsp;<a href="#dns.related.attacks">DNS-related Attacks</a></li>
     686               <li>10.5&nbsp;&nbsp;&nbsp;<a href="#attack.proxies">Proxies and Caching</a></li>
     687               <li>10.6&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li>
     688               <li>10.7&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
    691689            </ul>
    692690         </li>
    693          <li>12.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    694          <li>13.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    695                <li>13.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    696                <li>13.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     691         <li>11.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     692         <li>12.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     693               <li>12.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     694               <li>12.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    697695            </ul>
    698696         </li>
    … …  
    863861      <div id="rfc.iref.c.2"></div>
    864862      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="operation" href="#operation">Client/Server Messaging</a></h2>
    865       <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging messages across a reliable transport or session-layer
    866          "<dfn>connection</dfn>". An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
     863      <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging <dfn>messages</dfn> (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) across a reliable transport or session-layer "<dfn>connection</dfn>". An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
    867864      </p>
    868865      <div id="rfc.iref.u.1"></div>
    … …  
    887884      <div id="rfc.iref.r.2"></div>
    888885      <div id="rfc.iref.r.3"></div>
    889       <p id="rfc.section.2.1.p.5">A client sends an HTTP request to the server in the form of a <dfn>request</dfn>  <dfn>message</dfn> (<a href="#request" title="Request">Section&nbsp;4</a>), beginning with a method, URI, and protocol version, followed by MIME-like header fields containing request modifiers, client
    890          information, and payload metadata, an empty line to indicate the end of the header section, and finally the payload body (if
    891          any).
    892       </p>
    893       <p id="rfc.section.2.1.p.6">A server responds to the client's request by sending an HTTP <dfn>response</dfn>  <dfn>message</dfn> (<a href="#response" title="Response">Section&nbsp;5</a>), beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase, followed
    894          by MIME-like header fields containing server information, resource metadata, and payload metadata, an empty line to indicate
    895          the end of the header section, and finally the payload body (if any).
     886      <p id="rfc.section.2.1.p.5">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request-Line">Section&nbsp;3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and payload metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
     887      </p>
     888      <p id="rfc.section.2.1.p.6">A server responds to the client's request by sending an HTTP <dfn>response</dfn> message, beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase
     889         (<a href="#status.line" title="Response Status-Line">Section&nbsp;3.1.2</a>), followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
    896890      </p>
    897891      <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
    … …  
    915909<span id="exbody">Hello World!
    916910</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="message-orientation-and-buffering" href="#message-orientation-and-buffering">Message Orientation and Buffering</a></h2>
    917       <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations
     911      <p id="rfc.section.2.2.p.1">Fundamentally, HTTP is a message-based protocol. Although message bodies can be chunked (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>) and implementations often make parts of a message available progressively, this is not required, and some widely-used implementations
    918912         only make a message available when it is complete. Furthermore, while most proxies will progressively stream messages, some
    919913         amount of buffering will take place, and some proxies might buffer messages to perform transformations, check content or provide
    … …  
    937931         a proxy via some other connection port or protocol instead of using the defaults.
    938932      </p>
    939       <p id="rfc.section.2.3.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>.
     933      <p id="rfc.section.2.3.p.3">A connection might be used for multiple HTTP request/response exchanges, as defined in <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;6.1</a>.
    940934      </p>
    941935      <div id="rfc.iref.i.1"></div>
    … …  
    979973         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    980974         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    981          However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>) header fields for both connections.
     975         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.9</a>) header fields for both connections.
    982976      </p>
    983977      <p id="rfc.section.2.4.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    … …  
    10431037      <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    10441038         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
    1045          by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;9.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
     1039         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    10461040      </p>
    10471041      <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
    … …  
    11191113      </p>
    11201114      <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    1121          and sending an HTTP request message to the server containing the URI's identifying data as described in <a href="#request" title="Request">Section&nbsp;4</a>. If the server responds to that request with a non-interim HTTP response message, as described in <a href="#response" title="Response">Section&nbsp;5</a>, then that response is considered an authoritative answer to the client's request.
     1115         and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;4</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    11221116      </p>
    11231117      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    … …  
    11951189         or invalid request method) and clients are implemented to only expect a response.
    11961190      </p>
    1197       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#http.message" class="smpl">start-line</a>      = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a>
     1191      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#http.message" class="smpl">start-line</a>      = <a href="#request.line" class="smpl">Request-Line</a> / <a href="#status.line" class="smpl">Status-Line</a>
    11981192</pre><p id="rfc.section.3.1.p.4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
    11991193         attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
    … …  
    12011195         Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing.
    12021196      </p>
    1203       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="request-line" href="#request-line">Request-Line</a></h3>
     1197      <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="request.line" href="#request.line">Request-Line</a></h3>
    12041198      <p id="rfc.section.3.1.1.p.1">The Request-Line begins with a method token, followed by a single space (SP), the request-target, another single space (SP),
    12051199         the protocol version, and ending with CRLF.
    12061200      </p>
    1207       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.30"></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>
     1201      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.30"></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>
    12081202</pre><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h4>
    12091203      <p id="rfc.section.3.1.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    12101204      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1211 </pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations
     1205</pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations
    12121206         for new methods.
    12131207      </p>
    … …  
    12211215                 / <a href="#uri" class="smpl">authority</a>
    12221216</pre><p id="rfc.section.3.1.1.2.p.3">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
    1223          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1217         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    12241218      </p>
    12251219      <p id="rfc.section.3.1.1.2.p.4">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.
    … …  
    12291223         </p>
    12301224      </div>
    1231       <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="status-line" href="#status-line">Status-Line</a></h3>
     1225      <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="status.line" href="#status.line">Response Status-Line</a></h3>
    12321226      <p id="rfc.section.3.1.2.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version, a space (SP), the status code,
    12331227         another space, a possibly-empty textual phrase describing the status code, and ending with CRLF.
    12341228      </p>
    1235       <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.33"></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" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
     1229      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.33"></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" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    12361230</pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a>&nbsp;<a id="status.code" href="#status.code">Status Code</a></h4>
    1237       <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
     1231      <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
    12381232         for new status codes.
    12391233      </p>
    12401234      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#status.code" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    1241 </pre><p id="rfc.section.3.1.2.1.p.3">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
    1242          There are 5 values for the first digit:
    1243       </p>
    1244       <ul>
    1245          <li>1xx: Informational - Request received, continuing process</li>
    1246          <li>2xx: Success - The action was successfully received, understood, and accepted</li>
    1247          <li>3xx: Redirection - Further action must be taken in order to complete the request</li>
    1248          <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li>
    1249          <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
    1250       </ul>
    1251       <h4 id="rfc.section.3.1.2.2"><a href="#rfc.section.3.1.2.2">3.1.2.2</a>&nbsp;<a id="reason.phrase" href="#reason.phrase">Reason Phrase</a></h4>
     1235</pre><h4 id="rfc.section.3.1.2.2"><a href="#rfc.section.3.1.2.2">3.1.2.2</a>&nbsp;<a id="reason.phrase" href="#reason.phrase">Reason Phrase</a></h4>
    12521236      <p id="rfc.section.3.1.2.2.p.1">The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
    12531237         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    … …  
    12641248  <a href="#header.fields" class="smpl">field-content</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12651249</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1266          the Date header field is defined in <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;9.3</a> as containing the origination timestamp for the message in which it appears.
     1250         the Date header field is defined in <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a> as containing the origination timestamp for the message in which it appears.
    12671251      </p>
    12681252      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
    … …  
    12721256         them.
    12731257      </p>
    1274       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;9.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1258      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    12751259      </p>
    12761260      <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    … …  
    13011285      <p id="rfc.section.3.2.1.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    13021286         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1303          (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;10.3.1</a>). HTTP 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
     1287         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>). HTTP 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
    13041288         message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets
    13051289         (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
    … …  
    13171301      <div id="rule.token.separators">
    13181302         <p id="rfc.section.3.2.3.p.1">        Many HTTP/1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.
    1319             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;6.2</a>).
     1303            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;5.2</a>).
    13201304         </p>
    13211305      </div>
    … …  
    13641348      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
    13651349</pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
    1366          header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;9.7</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
     1350         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.7</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
    13671351      </p>
    13681352      <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
    1369          field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>.
    1370       </p>
    1371       <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;9.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
     1353         field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>.
     1354      </p>
     1355      <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;8.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
    13721356         a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields
    13731357         have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing
    … …  
    13931377         </li>
    13941378         <li>
    1395             <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
     1379            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
    13961380               indicates the data is complete.
    13971381            </p>
    … …  
    14621446      <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data
    14631447         on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message-body if it intends to reuse the same connection for a subsequent request. Pipelining multiple
    1464          requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;7.1.2.2</a>.
     1448         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.1.2.2</a>.
    14651449      </p>
    14661450      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    … …  
    14771461         above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response.
    14781462      </p>
    1479       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="request" href="#request">Request</a></h1>
    1480       <p id="rfc.section.4.p.1">A request message from a client to a server begins with a Request-Line, followed by zero or more header fields, an empty line
    1481          signifying the end of the header block, and an optional message body.
    1482       </p>
    1483       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.52"></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;3.1.1</a>
    1484                   *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
    1485                   <a href="#core.rules" class="smpl">CRLF</a>
    1486                   [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
    1487 </pre><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2>
    1488       <p id="rfc.section.4.1.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target
     1463      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="message.routing" href="#message.routing">Message Routing</a></h1>
     1464      <p id="rfc.section.4.p.1">In most cases, the user agent is provided a URI reference from which it determines an absolute URI for identifying the target
    14891465         resource. When a request to the resource is initiated, all or part of that URI is used to construct the HTTP request-target.
    14901466      </p>
    1491       <p id="rfc.section.4.1.p.2">The four options for request-target are dependent on the nature of the request.</p>
    1492       <p id="rfc.section.4.1.p.3"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening
     1467      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="request-target-types" href="#request-target-types">Types of Request Target</a></h2>
     1468      <p id="rfc.section.4.1.p.1">The four options for request-target are dependent on the nature of the request.</p>
     1469      <p id="rfc.section.4.1.p.2"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening
    14931470         process) rather than to a specific named resource at that server. For example,
    14941471      </p>
    1495       <div id="rfc.figure.u.35"></div><pre class="text2">OPTIONS * HTTP/1.1
    1496 </pre><p id="rfc.section.4.1.p.5"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
     1472      <div id="rfc.figure.u.34"></div><pre class="text2">OPTIONS * HTTP/1.1
     1473</pre><p id="rfc.section.4.1.p.4"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid
    14971474         cache, and then 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
    14981475         loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, and the numeric IP
    14991476         address. An example Request-Line would be:
    15001477      </p>
    1501       <div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1502 </pre><p id="rfc.section.4.1.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.
    1503       </p>
    1504       <p id="rfc.section.4.1.p.8">If a proxy receives a host name that 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.
    1505       </p>
    1506       <p id="rfc.section.4.1.p.9"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    1507       </p>
    1508       <p id="rfc.section.4.1.p.10"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,
     1478      <div id="rfc.figure.u.35"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     1479</pre><p id="rfc.section.4.1.p.6">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.
     1480      </p>
     1481      <p id="rfc.section.4.1.p.7">If a proxy receives a host name that 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.
     1482      </p>
     1483      <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1484      </p>
     1485      <p id="rfc.section.4.1.p.9"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,
    15091486         the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified
    15101487         above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and
    15111488         send the lines:
    15121489      </p>
    1513       <div id="rfc.figure.u.37"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
     1490      <div id="rfc.figure.u.36"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
    15141491Host: www.example.org
    1515 </pre><p id="rfc.section.4.1.p.12">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path;
     1492</pre><p id="rfc.section.4.1.p.11">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path;
    15161493         if the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target.
    15171494      </p>
    1518       <p id="rfc.section.4.1.p.13">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
     1495      <p id="rfc.section.4.1.p.12">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and
    15191496         no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server.
    15201497      </p>
    1521       <div id="rfc.figure.u.38"></div>
     1498      <div id="rfc.figure.u.37"></div>
    15221499      <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
    1523 </pre><div id="rfc.figure.u.39"></div>
     1500</pre><div id="rfc.figure.u.38"></div>
    15241501      <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
    15251502Host: www.example.org:8001
    15261503</pre>  <p>after connecting to port 8001 of host "www.example.org".</p>
    1527       <p id="rfc.section.4.1.p.16">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
    1528       </p>
    1529       <p id="rfc.section.4.1.p.17">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted
     1504      <p id="rfc.section.4.1.p.15">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
     1505      </p>
     1506      <p id="rfc.section.4.1.p.16">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted
    15301507         above to replace a null path-absolute with "/" or "*".
    15311508      </p>
    1532       <div class="note" id="rfc.section.4.1.p.18">
     1509      <div class="note" id="rfc.section.4.1.p.17">
    15331510         <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
    15341511            a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been
    … …  
    15741551         </li>
    15751552         <li>the octet sequence "://",</li>
    1576          <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;9.4</a>), and
     1553         <li>the authority component, as specified in the Host header field (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;8.4</a>), and
    15771554         </li>
    15781555         <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li>
    … …  
    15821559      </p>
    15831560      <p id="rfc.section.4.3.p.6">Otherwise, when request-target uses the authority form, the effective request URI is undefined.</p>
    1584       <div id="rfc.figure.u.40"></div>
     1561      <div id="rfc.figure.u.39"></div>
    15851562      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    15861563Host: www.example.org:8080
    … …  
    15881565         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
    15891566      </p>
    1590       <div id="rfc.figure.u.41"></div>
     1567      <div id="rfc.figure.u.40"></div>
    15911568      <p>Example 2: the effective request URI for the message</p>  <pre class="text">OPTIONS * HTTP/1.1
    15921569Host: www.example.org
    … …  
    15961573      <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
    15971574      </p>
    1598       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
    1599       <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
    1600       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.53"></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;3.1.2</a>
    1601                   *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
    1602                   <a href="#core.rules" class="smpl">CRLF</a>
    1603                   [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
    1604 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    1605       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2>
    1606       <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is
     1575      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
     1576      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="date.time.formats.full.date" href="#date.time.formats.full.date">Date/Time Formats: Full Date</a></h2>
     1577      <p id="rfc.section.5.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is
    16071578         a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
    16081579      </p>
    1609       <div id="rfc.figure.u.43"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
    1610 </pre><p id="rfc.section.6.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
    1611       <div id="rfc.figure.u.44"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
     1580      <div id="rfc.figure.u.41"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
     1581</pre><p id="rfc.section.5.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
     1582      <div id="rfc.figure.u.42"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    16121583Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    1613 </pre><p id="rfc.section.6.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields.
    1614       </p>
    1615       <p id="rfc.section.6.1.p.6">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
     1584</pre><p id="rfc.section.5.1.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields.
     1585      </p>
     1586      <p id="rfc.section.5.1.p.6">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
    16161587         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    16171588         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.
    16181589      </p>
    1619       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
     1590      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
    16201591</pre><div id="preferred.date.format">
    1621          <p id="rfc.section.6.1.p.8">                    Preferred format:</p>
     1592         <p id="rfc.section.5.1.p.8">                    Preferred format:</p>
    16221593      </div>
    1623       <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
     1594      <div id="rfc.figure.u.44"></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><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    16241595  ; fixed length subset of the format defined in
    16251596  ; <a href="http://tools.ietf.org/html/rfc1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>
    … …  
    16591630  <a href="#preferred.date.format" class="smpl">minute</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
    16601631  <a href="#preferred.date.format" class="smpl">second</a>       = 2<a href="#core.rules" class="smpl">DIGIT</a>               
    1661 </pre><p id="rfc.section.6.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
     1632</pre><p id="rfc.section.5.1.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
    16621633      </p>
    16631634      <div id="obsolete.date.formats">
    1664          <p id="rfc.section.6.1.p.11">                Obsolete formats:</p>
     1635         <p id="rfc.section.5.1.p.11">                Obsolete formats:</p>
    16651636      </div>
    1666       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>
    1667 </pre><div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.68"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
     1637      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.65"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>
     1638</pre><div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.66"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
    16681639  <a href="#obsolete.date.formats" class="smpl">date2</a>        = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a>
    16691640                 ; day-month-year (e.g., 02-Jun-82)
    … …  
    16761647         / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
    16771648         / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
    1678 </pre><div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.69"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
     1649</pre><div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
    16791650  <a href="#obsolete.date.formats" class="smpl">date3</a>        = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> ))
    16801651                 ; month day (e.g., Jun  2)
    1681 </pre><div class="note" id="rfc.section.6.1.p.15">
     1652</pre><div class="note" id="rfc.section.5.1.p.15">
    16821653         <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications,
    16831654            as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
    16841655         </p>
    16851656      </div>
    1686       <div class="note" id="rfc.section.6.1.p.16">
     1657      <div class="note" id="rfc.section.5.1.p.16">
    16871658         <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
    16881659            are not required to use these formats for user presentation, request logging, etc.
    16891660         </p>
    16901661      </div>
    1691       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
    1692       <p id="rfc.section.6.2.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
     1662      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
     1663      <p id="rfc.section.5.2.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
    16931664         to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the
    16941665         transfer-coding is a property of the message rather than a property of the representation that is being transferred.
    16951666      </p>
    1696       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>
    1697                           / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;6.2.2.1</a>
    1698                           / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;6.2.2.2</a>
    1699                           / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;6.2.2.3</a>
     1667      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>
     1668                          / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.2.1</a>
     1669                          / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2.2</a>
     1670                          / "gzip" ; <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.2.3</a>
    17001671                          / <a href="#transfer.codings" class="smpl">transfer-extension</a>
    17011672  <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="#rule.parameter" class="smpl">transfer-parameter</a> )
    17021673</pre><div id="rule.parameter">
    1703          <p id="rfc.section.6.2.p.3">      Parameters are in the form of attribute/value pairs.</p>
     1674         <p id="rfc.section.5.2.p.3">      Parameters are in the form of attribute/value pairs.</p>
    17041675      </div>
    1705       <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
     1676      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>
    17061677  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    17071678  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
    1708 </pre><p id="rfc.section.6.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;9.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;9.7</a>).
    1709       </p>
    1710       <p id="rfc.section.6.2.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
     1679</pre><p id="rfc.section.5.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;8.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;8.7</a>).
     1680      </p>
     1681      <p id="rfc.section.5.2.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
    17111682         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic
    17121683         of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>), or the desire to encrypt data over a shared transport.
    17131684      </p>
    1714       <p id="rfc.section.6.2.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
     1685      <p id="rfc.section.5.2.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
    17151686      </p>
    17161687      <div id="rfc.iref.c.6"></div>
    17171688      <div id="rfc.iref.c.7"></div>
    1718       <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
    1719       <p id="rfc.section.6.2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
     1689      <h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
     1690      <p id="rfc.section.5.2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
    17201691         indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary
    17211692         for the recipient to verify that it has received the full message.
    17221693      </p>
    1723       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     1694      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    17241695                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    17251696                   <a href="#chunked.encoding" class="smpl">trailer-part</a>
    … …  
    17411712                 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding
    17421713  <a href="#chunked.encoding" class="smpl">qdtext-nf</a>      = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    1743 </pre><p id="rfc.section.6.2.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
     1714</pre><p id="rfc.section.5.2.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
    17441715         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
    17451716      </p>
    1746       <p id="rfc.section.6.2.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
    1747          can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;9.6</a>).
    1748       </p>
    1749       <p id="rfc.section.6.2.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
     1717      <p id="rfc.section.5.2.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
     1718         can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;8.6</a>).
     1719      </p>
     1720      <p id="rfc.section.5.2.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
    17501721      </p>
    17511722      <ol>
    17521723         <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as
    1753             described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;9.5</a>; or,
     1724            described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;8.5</a>; or,
    17541725         </li>
    17551726         <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
    … …  
    17591730         </li>
    17601731      </ol>
    1761       <p id="rfc.section.6.2.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
     1732      <p id="rfc.section.5.2.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
    17621733         forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly
    17631734         infinite buffer on the proxy.
    17641735      </p>
    1765       <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
    1766       <div id="rfc.figure.u.53"></div><pre class="text">  length := 0
     1736      <p id="rfc.section.5.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>
     1737      <div id="rfc.figure.u.51"></div><pre class="text">  length := 0
    17671738  read chunk-size, chunk-ext (if any) and CRLF
    17681739  while (chunk-size &gt; 0) {
    … …  
    17791750  Content-Length := length
    17801751  Remove "chunked" from Transfer-Encoding
    1781 </pre><p id="rfc.section.6.2.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
    1782       </p>
    1783       <p id="rfc.section.6.2.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
     1752</pre><p id="rfc.section.5.2.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
     1753      </p>
     1754      <p id="rfc.section.5.2.1.p.10">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
    17841755         messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding
    17851756         applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body.
    17861757      </p>
    1787       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>
    1788       <p id="rfc.section.6.2.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
    1789       <div class="note" id="rfc.section.6.2.2.p.2">
     1758      <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h3>
     1759      <p id="rfc.section.5.2.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
     1760      <div class="note" id="rfc.section.5.2.2.p.2">
    17901761         <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
    17911762            Their use here is representative of historical practice, not good design.
    17921763         </p>
    17931764      </div>
    1794       <div class="note" id="rfc.section.6.2.2.p.3">
     1765      <div class="note" id="rfc.section.5.2.2.p.3">
    17951766         <p> <b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
    17961767         </p>
    … …  
    17981769      <div id="rfc.iref.c.8"></div>
    17991770      <div id="rfc.iref.c.9"></div>
    1800       <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h4>
    1801       <p id="rfc.section.6.2.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
     1771      <h4 id="rfc.section.5.2.2.1"><a href="#rfc.section.5.2.2.1">5.2.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h4>
     1772      <p id="rfc.section.5.2.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
    18021773         coding (LZW).
    18031774      </p>
    18041775      <div id="rfc.iref.d.2"></div>
    18051776      <div id="rfc.iref.c.10"></div>
    1806       <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>
    1807       <p id="rfc.section.6.2.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).
    1808       </p>
    1809       <div class="note" id="rfc.section.6.2.2.2.p.2">
     1777      <h4 id="rfc.section.5.2.2.2"><a href="#rfc.section.5.2.2.2">5.2.2.2</a>&nbsp;<a id="deflate.coding" href="#deflate.coding">Deflate Coding</a></h4>
     1778      <p id="rfc.section.5.2.2.2.p.1">The "deflate" format is defined as the "deflate" compression mechanism (described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>).
     1779      </p>
     1780      <div class="note" id="rfc.section.5.2.2.2.p.2">
    18101781         <p> <b>Note:</b> Some incorrect implementations send the "deflate" compressed data without the zlib wrapper.
    18111782         </p>
    18121783      </div>
    1813       <div id="rfc.iref.g.88"></div>
     1784      <div id="rfc.iref.g.86"></div>
    18141785      <div id="rfc.iref.c.11"></div>
    1815       <h4 id="rfc.section.6.2.2.3"><a href="#rfc.section.6.2.2.3">6.2.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>
    1816       <p id="rfc.section.6.2.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
    1817       </p>
    1818       <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3>
    1819       <p id="rfc.section.6.2.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
    1820       <p id="rfc.section.6.2.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     1786      <h4 id="rfc.section.5.2.2.3"><a href="#rfc.section.5.2.2.3">5.2.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h4>
     1787      <p id="rfc.section.5.2.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
     1788      </p>
     1789      <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h3>
     1790      <p id="rfc.section.5.2.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
     1791      <p id="rfc.section.5.2.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    18211792      </p>
    18221793      <ul>
    … …  
    18251796         <li>Pointer to specification text</li>
    18261797      </ul>
    1827       <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
    1828       </p>
    1829       <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
    1830       </p>
    1831       <p id="rfc.section.6.2.3.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    1832       </p>
    1833       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
    1834       <p id="rfc.section.6.3.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
     1798      <p id="rfc.section.5.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;5.2.2</a>).
     1799      </p>
     1800      <p id="rfc.section.5.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
     1801      </p>
     1802      <p id="rfc.section.5.2.3.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     1803      </p>
     1804      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
     1805      <p id="rfc.section.5.3.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
    18351806         using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace.
    18361807         By convention, the products are listed in order of their significance for identifying the application.
    18371808      </p>
    1838       <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></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>]
     1809      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></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>]
    18391810  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    1840 </pre><p id="rfc.section.6.3.p.3">Examples:</p>
    1841       <div id="rfc.figure.u.55"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     1811</pre><p id="rfc.section.5.3.p.3">Examples:</p>
     1812      <div id="rfc.figure.u.53"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    18421813  Server: Apache/0.8.4
    1843 </pre><p id="rfc.section.6.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <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).
    1844       </p>
    1845       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1846       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1814</pre><p id="rfc.section.5.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <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).
     1815      </p>
     1816      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
     1817      <p id="rfc.section.5.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;8.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    18471818         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    18481819         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    18491820      </p>
    1850       <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.91"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
     1821      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.89"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    18511822                 / ( "1" [ "." 0*3("0") ] )
    1852 </pre><div class="note" id="rfc.section.6.4.p.3">
     1823</pre><div class="note" id="rfc.section.5.4.p.3">
    18531824         <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.
    18541825         </p>
    18551826      </div>
    1856       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    1857       <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>
    1858       <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
    1859       <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers
     1827      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
     1828      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
     1829      <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
     1830      <p id="rfc.section.6.1.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers
    18601831         and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make
    18611832         multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a
    18621833         prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
    18631834      </p>
    1864       <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
     1835      <p id="rfc.section.6.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
    18651836      <ul>
    18661837         <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways,
    … …  
    18791850         </li>
    18801851      </ul>
    1881       <p id="rfc.section.7.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
    1882       </p>
    1883       <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
    1884       <p id="rfc.section.7.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
     1852      <p id="rfc.section.6.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
     1853      </p>
     1854      <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
     1855      <p id="rfc.section.6.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
    18851856         of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server.
    18861857      </p>
    1887       <p id="rfc.section.7.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
    1888          takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
    1889       </p>
    1890       <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    1891       <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection-token
     1858      <p id="rfc.section.6.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
     1859         takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
     1860      </p>
     1861      <h4 id="rfc.section.6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
     1862      <p id="rfc.section.6.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection-token
    18921863         "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token "close".
    18931864      </p>
    1894       <p id="rfc.section.7.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
     1865      <p id="rfc.section.6.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
    18951866         a Connection header field with the connection-token close. In case the client does not want to maintain a connection for more
    18961867         than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token close.
    18971868      </p>
    1898       <p id="rfc.section.7.1.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one
     1869      <p id="rfc.section.6.1.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one
    18991870         for the connection.
    19001871      </p>
    1901       <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    1902       </p>
    1903       <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>.
    1904       </p>
    1905       <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
    1906       <p id="rfc.section.7.1.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
    1907       </p>
    1908       <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.
    1909       </p>
    1910       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><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
     1872      <p id="rfc.section.6.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
     1873      </p>
     1874      <p id="rfc.section.6.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>.
     1875      </p>
     1876      <h4 id="rfc.section.6.1.2.2"><a href="#rfc.section.6.1.2.2">6.1.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
     1877      <p id="rfc.section.6.1.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
     1878      </p>
     1879      <p id="rfc.section.6.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.
     1880      </p>
     1881      <p id="rfc.section.6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><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
    19111882         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    19121883      </p>
    1913       <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
    1914       <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;9.1</a>.
    1915       </p>
    1916       <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
     1884      <h3 id="rfc.section.6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
     1885      <p id="rfc.section.6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;8.1</a>.
     1886      </p>
     1887      <p id="rfc.section.6.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
    19171888         to. Each persistent connection applies to only one transport link.
    19181889      </p>
    1919       <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
    1920       </p>
    1921       <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4>
    1922       <p id="rfc.section.7.1.3.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p>
     1890      <p id="rfc.section.6.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
     1891      </p>
     1892      <h4 id="rfc.section.6.1.3.1"><a href="#rfc.section.6.1.3.1">6.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4>
     1893      <p id="rfc.section.6.1.3.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p>
    19231894      <ul>
    19241895         <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields
    … …  
    19291900         </li>
    19301901      </ul>
    1931       <p id="rfc.section.7.1.3.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
     1902      <p id="rfc.section.6.1.3.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
    19321903      <ul>
    19331904         <li>Connection</li>
    … …  
    19401911         <li>Upgrade</li>
    19411912      </ul>
    1942       <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
    1943       <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;9.1</a>).
    1944       </p>
    1945       <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
    1946       <p id="rfc.section.7.1.3.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A non-transforming
     1913      <p id="rfc.section.6.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
     1914      <p id="rfc.section.6.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;8.1</a>).
     1915      </p>
     1916      <h4 id="rfc.section.6.1.3.2"><a href="#rfc.section.6.1.3.2">6.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
     1917      <p id="rfc.section.6.1.3.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A non-transforming
    19471918         proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header field unless the definition of that header field requires or specifically allows that.
    19481919      </p>
    1949       <p id="rfc.section.7.1.3.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
     1920      <p id="rfc.section.6.1.3.2.p.2">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
    19501921      </p>
    19511922      <ul>
    … …  
    19571928         <li>Server</li>
    19581929      </ul>
    1959       <p id="rfc.section.7.1.3.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response:
     1930      <p id="rfc.section.6.1.3.2.p.3">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a response:
    19601931      </p>
    19611932      <ul>
    19621933         <li>Expires</li>
    19631934      </ul>
    1964       <p id="rfc.section.7.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
    1965       </p>
    1966       <p id="rfc.section.7.1.3.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
     1935      <p id="rfc.section.6.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
     1936      </p>
     1937      <p id="rfc.section.6.1.3.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
    19671938      </p>
    19681939      <ul>
    … …  
    19711942         <li>Content-Type</li>
    19721943      </ul>
    1973       <p id="rfc.section.7.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    1974       </p>
    1975       <div class="note" id="rfc.section.7.1.3.2.p.7">
     1944      <p id="rfc.section.6.1.3.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1945      </p>
     1946      <div class="note" id="rfc.section.6.1.3.2.p.7">
    19761947         <p> <b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms
    19771948            are introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    19781949         </p>
    19791950      </div>
    1980       <p id="rfc.section.7.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    1981       </p>
    1982       <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
    1983       <p id="rfc.section.7.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
     1951      <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>).
     1952      </p>
     1953      <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
     1954      <p id="rfc.section.6.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
    19841955         might make this a higher value since it is likely that the client will be making more connections through the same server.
    19851956         The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
    19861957         or the server.
    19871958      </p>
    1988       <p id="rfc.section.7.1.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
     1959      <p id="rfc.section.6.1.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
    19891960         not detect the other side's close promptly it could cause unnecessary resource drain on the network.
    19901961      </p>
    1991       <p id="rfc.section.7.1.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
     1962      <p id="rfc.section.6.1.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
    19921963         that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
    19931964         while it was idle, but from the client's point of view, a request is in progress.
    19941965      </p>
    1995       <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
    1996          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     1966      <p id="rfc.section.6.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
     1967         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    19971968         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.
    19981969      </p>
    1999       <p id="rfc.section.7.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
    2000       </p>
    2001       <p id="rfc.section.7.1.4.p.6">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
    2002       </p>
    2003       <p id="rfc.section.7.1.4.p.7">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
     1970      <p id="rfc.section.6.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
     1971      </p>
     1972      <p id="rfc.section.6.1.4.p.6">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
     1973      </p>
     1974      <p id="rfc.section.6.1.4.p.7">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
    20041975         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    20051976         clients to be conservative when opening multiple connections.
    20061977      </p>
    2007       <p id="rfc.section.7.1.4.p.8">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
     1978      <p id="rfc.section.6.1.4.p.8">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
    20081979         server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
    20091980         consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
    20101981         effects in congested networks.
    20111982      </p>
    2012       <p id="rfc.section.7.1.4.p.9">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
    2013       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
    2014       <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
    2015       <p id="rfc.section.7.2.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
     1983      <p id="rfc.section.6.1.4.p.9">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
     1984      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
     1985      <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
     1986      <p id="rfc.section.6.2.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
    20161987         connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.
    20171988      </p>
    2018       <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    2019       <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    2020          status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    2021       </p>
    2022       <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>
    2023       <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><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
     1989      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
     1990      <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
     1991         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
     1992      </p>
     1993      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.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>
     1994      <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><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
    20241995         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    20251996         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    20261997         looking at the body.
    20271998      </p>
    2028       <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    2029       <ul>
    2030          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2031          </li>
    2032          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><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.
    2033          </li>
    2034       </ul>
    2035       <p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
     1999      <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
     2000      <ul>
     2001         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2002         </li>
     2003         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.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 if it does not intend to send a request body.
     2004         </li>
     2005      </ul>
     2006      <p id="rfc.section.6.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    20362007         100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client
    20372008         sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code,
    20382009         the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    20392010      </p>
    2040       <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
     2011      <p id="rfc.section.6.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    20412012      <ul>
    20422013         <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
    … …  
    20622033         </li>
    20632034      </ul>
    2064       <p id="rfc.section.7.2.3.p.5">Requirements for HTTP/1.1 proxies: </p>
     2035      <p id="rfc.section.6.2.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    20652036      <ul>
    20662037         <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either
    … …  
    20742045         <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
    20752046            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    2076             1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    2077          </li>
    2078       </ul>
    2079       <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a>&nbsp;<a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
    2080       <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect header field with
     2047            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2048         </li>
     2049      </ul>
     2050      <h3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a>&nbsp;<a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
     2051      <p id="rfc.section.6.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect header field with
    20812052         the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client
    20822053         sees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
    … …  
    20952066         </li>
    20962067      </ol>
    2097       <p id="rfc.section.7.2.4.p.2">If at any point an error status code is received, the client </p>
     2068      <p id="rfc.section.6.2.4.p.2">If at any point an error status code is received, the client </p>
    20982069      <ul>
    20992070         <li><em class="bcp14">SHOULD NOT</em> continue and
    … …  
    21022073         </li>
    21032074      </ul>
    2104       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="misc" href="#misc">Miscellaneous notes that might disappear</a></h1>
    2105       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h2>
    2106       <p id="rfc.section.8.1.p.1"> <span class="comment" id="TBD-aliases-harmful">[<a href="#TBD-aliases-harmful" class="smpl">TBD-aliases-harmful</a>: describe why aliases like webcal are harmful.]</span>
    2107       </p>
    2108       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="http.proxy" href="#http.proxy">Use of HTTP for proxy communication</a></h2>
    2109       <p id="rfc.section.8.2.p.1"> <span class="comment" id="TBD-proxy-other">[<a href="#TBD-proxy-other" class="smpl">TBD-proxy-other</a>: Configured to use HTTP to proxy HTTP or other protocols.]</span>
    2110       </p>
    2111       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="http.intercept" href="#http.intercept">Interception of HTTP for access control</a></h2>
    2112       <p id="rfc.section.8.3.p.1"> <span class="comment" id="TBD-intercept">[<a href="#TBD-intercept" class="smpl">TBD-intercept</a>: Interception of HTTP traffic for initiating access control.]</span>
    2113       </p>
    2114       <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="http.others" href="#http.others">Use of HTTP by other protocols</a></h2>
    2115       <p id="rfc.section.8.4.p.1"> <span class="comment" id="TBD-profiles">[<a href="#TBD-profiles" class="smpl">TBD-profiles</a>: Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.]</span>
    2116       </p>
    2117       <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="http.media" href="#http.media">Use of HTTP by media type specification</a></h2>
    2118       <p id="rfc.section.8.5.p.1"> <span class="comment" id="TBD-hypertext">[<a href="#TBD-hypertext" class="smpl">TBD-hypertext</a>: Instructions on composing HTTP requests via hypertext formats.]</span>
    2119       </p>
    2120       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
    2121       <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP header fields related to message origination, framing, and routing.</p>
     2075      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="misc" href="#misc">Miscellaneous notes that might disappear</a></h1>
     2076      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h2>
     2077      <p id="rfc.section.7.1.p.1"> <span class="comment" id="TBD-aliases-harmful">[<a href="#TBD-aliases-harmful" class="smpl">TBD-aliases-harmful</a>: describe why aliases like webcal are harmful.]</span>
     2078      </p>
     2079      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="http.proxy" href="#http.proxy">Use of HTTP for proxy communication</a></h2>
     2080      <p id="rfc.section.7.2.p.1"> <span class="comment" id="TBD-proxy-other">[<a href="#TBD-proxy-other" class="smpl">TBD-proxy-other</a>: Configured to use HTTP to proxy HTTP or other protocols.]</span>
     2081      </p>
     2082      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="http.intercept" href="#http.intercept">Interception of HTTP for access control</a></h2>
     2083      <p id="rfc.section.7.3.p.1"> <span class="comment" id="TBD-intercept">[<a href="#TBD-intercept" class="smpl">TBD-intercept</a>: Interception of HTTP traffic for initiating access control.]</span>
     2084      </p>
     2085      <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="http.others" href="#http.others">Use of HTTP by other protocols</a></h2>
     2086      <p id="rfc.section.7.4.p.1"> <span class="comment" id="TBD-profiles">[<a href="#TBD-profiles" class="smpl">TBD-profiles</a>: Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.]</span>
     2087      </p>
     2088      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="http.media" href="#http.media">Use of HTTP by media type specification</a></h2>
     2089      <p id="rfc.section.7.5.p.1"> <span class="comment" id="TBD-hypertext">[<a href="#TBD-hypertext" class="smpl">TBD-hypertext</a>: Instructions on composing HTTP requests via hypertext formats.]</span>
     2090      </p>
     2091      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     2092      <p id="rfc.section.8.p.1">This section defines the syntax and semantics of HTTP header fields related to message origination, framing, and routing.</p>
    21222093      <div id="rfc.table.u.1">
    21232094         <table class="tt full left" cellpadding="3" cellspacing="0">
    … …  
    21312102               <tr>
    21322103                  <td class="left">Connection</td>
    2133                   <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;9.1</a></td>
     2104                  <td class="left"><a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;8.1</a></td>
    21342105               </tr>
    21352106               <tr>
    21362107                  <td class="left">Content-Length</td>
    2137                   <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;9.2</a></td>
     2108                  <td class="left"><a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;8.2</a></td>
    21382109               </tr>
    21392110               <tr>
    21402111                  <td class="left">Date</td>
    2141                   <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;9.3</a></td>
     2112                  <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;8.3</a></td>
    21422113               </tr>
    21432114               <tr>
    21442115                  <td class="left">Host</td>
    2145                   <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;9.4</a></td>
     2116                  <td class="left"><a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;8.4</a></td>
    21462117               </tr>
    21472118               <tr>
    21482119                  <td class="left">TE</td>
    2149                   <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;9.5</a></td>
     2120                  <td class="left"><a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;8.5</a></td>
    21502121               </tr>
    21512122               <tr>
    21522123                  <td class="left">Trailer</td>
    2153                   <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;9.6</a></td>
     2124                  <td class="left"><a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.6</a></td>
    21542125               </tr>
    21552126               <tr>
    21562127                  <td class="left">Transfer-Encoding</td>
    2157                   <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;9.7</a></td>
     2128                  <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;8.7</a></td>
    21582129               </tr>
    21592130               <tr>
    21602131                  <td class="left">Upgrade</td>
    2161                   <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;9.8</a></td>
     2132                  <td class="left"><a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.8</a></td>
    21622133               </tr>
    21632134               <tr>
    21642135                  <td class="left">Via</td>
    2165                   <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;9.9</a></td>
     2136                  <td class="left"><a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;8.9</a></td>
    21662137               </tr>
    21672138            </tbody>
    … …  
    21702141      <div id="rfc.iref.c.12"></div>
    21712142      <div id="rfc.iref.h.6"></div>
    2172       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    2173       <p id="rfc.section.9.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such
     2143      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
     2144      <p id="rfc.section.8.1.p.1">The "Connection" header field allows the sender to specify options that are desired only for that particular connection. Such
    21742145         connection options <em class="bcp14">MUST</em> be removed or replaced before the message can be forwarded downstream by a proxy or gateway. This mechanism also allows the
    21752146         sender to indicate which HTTP header fields used in the message are only intended for the immediate recipient ("hop-by-hop"),
    … …  
    21782149         intermediaries.
    21792150      </p>
    2180       <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p>
    2181       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
     2151      <p id="rfc.section.8.1.p.2">The Connection header field's value has the following grammar:</p>
     2152      <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span>  <a href="#header.connection" class="smpl">Connection</a>       = 1#<a href="#header.connection" class="smpl">connection-token</a>
    21822153  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    2183 </pre><p id="rfc.section.9.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
     2154</pre><p id="rfc.section.8.1.p.4">A proxy or gateway <em class="bcp14">MUST</em> parse a received Connection header field before a message is forwarded and, for each connection-token in this field, remove
    21842155         any header field(s) from the message with the same name as the connection-token, and then remove the Connection header field
    21852156         itself or replace it with the sender's own connection options for the forwarded message.
    21862157      </p>
    2187       <p id="rfc.section.9.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
     2158      <p id="rfc.section.8.1.p.5">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
    21882159         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    21892160      </p>
    2190       <p id="rfc.section.9.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
     2161      <p id="rfc.section.8.1.p.6">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
    21912162         field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain
    21922163         connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-token rather than only the presence of the optional header field. In other words,
    … …  
    21942165         compliant.
    21952166      </p>
    2196       <p id="rfc.section.9.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
     2167      <p id="rfc.section.8.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
    21972168         that the new connection-token does not share the same name as an unrelated header field that might already be deployed. Defining
    21982169         a new connection-token essentially reserves that potential field-name for carrying additional information related to the connection
    21992170         option, since it would be unwise for senders to use that field-name for anything else.
    22002171      </p>
    2201       <p id="rfc.section.9.1.p.8">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
     2172      <p id="rfc.section.8.1.p.8">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
    22022173         of the response. For example,
    22032174      </p>
    2204       <div id="rfc.figure.u.58"></div><pre class="text">  Connection: close
    2205 </pre><p id="rfc.section.9.1.p.10">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.
    2206       </p>
    2207       <p id="rfc.section.9.1.p.11">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
    2208       </p>
    2209       <p id="rfc.section.9.1.p.12">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
     2175      <div id="rfc.figure.u.56"></div><pre class="text">  Connection: close
     2176</pre><p id="rfc.section.8.1.p.10">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;6.1</a>) after the current request/response is complete.
     2177      </p>
     2178      <p id="rfc.section.8.1.p.11">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
     2179      </p>
     2180      <p id="rfc.section.8.1.p.12">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
    22102181      </p>
    22112182      <div id="rfc.iref.c.13"></div>
    22122183      <div id="rfc.iref.h.7"></div>
    2213       <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
    2214       <p id="rfc.section.9.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
     2184      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
     2185      <p id="rfc.section.8.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
    22152186         than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length
    22162187         indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
    … …  
    22182189         body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
    22192190      </p>
    2220       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.94"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    2221 </pre><p id="rfc.section.9.2.p.3">An example is</p>
    2222       <div id="rfc.figure.u.60"></div><pre class="text">  Content-Length: 3495
    2223 </pre><p id="rfc.section.9.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
     2191      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.92"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     2192</pre><p id="rfc.section.8.2.p.3">An example is</p>
     2193      <div id="rfc.figure.u.58"></div><pre class="text">  Content-Length: 3495
     2194</pre><p id="rfc.section.8.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
    22242195         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
    22252196      </p>
    2226       <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
    2227       <p id="rfc.section.9.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is
     2197      <p id="rfc.section.8.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
     2198      <p id="rfc.section.8.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is
    22282199         an optional field used within the "message/external-body" content-type.
    22292200      </p>
    22302201      <div id="rfc.iref.d.3"></div>
    22312202      <div id="rfc.iref.h.8"></div>
    2232       <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    2233       <p id="rfc.section.9.3.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
    2234          Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    2235       </p>
    2236       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.95"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>
    2237 </pre><p id="rfc.section.9.3.p.3">An example is</p>
    2238       <div id="rfc.figure.u.62"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    2239 </pre><p id="rfc.section.9.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
     2203      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
     2204      <p id="rfc.section.8.3.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
     2205         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;5.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     2206      </p>
     2207      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.93"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>
     2208</pre><p id="rfc.section.8.3.p.3">An example is</p>
     2209      <div id="rfc.figure.u.60"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
     2210</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:
    22402211      </p>
    22412212      <ol>
    … …  
    22452216            is inconvenient or impossible to generate a valid Date.
    22462217         </li>
    2247          <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section&nbsp;9.3.1</a>  <em class="bcp14">MUST</em> be followed.
     2218         <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section&nbsp;8.3.1</a>  <em class="bcp14">MUST</em> be followed.
    22482219         </li>
    22492220      </ol>
    2250       <p id="rfc.section.9.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
    2251       </p>
    2252       <p id="rfc.section.9.3.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
     2221      <p id="rfc.section.8.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
     2222      </p>
     2223      <p id="rfc.section.8.3.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
    22532224         when it doesn't convey any useful information (as it is usually the case for requests that do not contain a payload).
    22542225      </p>
    2255       <p id="rfc.section.9.3.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
     2226      <p id="rfc.section.8.3.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    22562227         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    22572228         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    22582229         value.
    22592230      </p>
    2260       <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a>&nbsp;<a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>
    2261       <p id="rfc.section.9.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or
     2231      <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>
     2232      <p id="rfc.section.8.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or
    22622233         user with a reliable clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration"
    22632234         of responses without storing separate Expires values for each resource).
    … …  
    22652236      <div id="rfc.iref.h.9"></div>
    22662237      <div id="rfc.iref.h.10"></div>
    2267       <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    2268       <p id="rfc.section.9.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
     2238      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
     2239      <p id="rfc.section.8.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin
    22692240         server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the
    22702241         Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line.
    22712242      </p>
    2272       <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.96"></span>  <a href="#header.host" class="smpl">Host</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.7.1</a>
    2273 </pre><p id="rfc.section.9.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
     2243      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.94"></span>  <a href="#header.host" class="smpl">Host</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.7.1</a>
     2244</pre><p id="rfc.section.8.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then
    22742245         the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value.
    22752246      </p>
    2276       <p id="rfc.section.9.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    2277       <div id="rfc.figure.u.64"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
     2247      <p id="rfc.section.8.4.p.4">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
     2248      <div id="rfc.figure.u.62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    22782249Host: www.example.org
    2279 </pre><p id="rfc.section.9.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
     2250</pre><p id="rfc.section.8.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information
    22802251         to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
    22812252      </p>
    2282       <p id="rfc.section.9.4.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
     2253      <p id="rfc.section.8.4.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When
    22832254         a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host.
    22842255      </p>
    2285       <p id="rfc.section.9.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
     2256      <p id="rfc.section.8.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
    22862257         poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
    22872258         relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared
    22882259         cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.
    22892260      </p>
    2290       <p id="rfc.section.9.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
     2261      <p id="rfc.section.8.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
    22912262         message that contains more than one Host header field or a Host header field with an invalid field-value.
    22922263      </p>
    2293       <p id="rfc.section.9.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
     2264      <p id="rfc.section.8.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">A.1.1</a> for other requirements relating to Host.
    22942265      </p>
    22952266      <div id="rfc.iref.t.5"></div>
    22962267      <div id="rfc.iref.h.11"></div>
    2297       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    2298       <p id="rfc.section.9.5.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not
     2268      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
     2269      <p id="rfc.section.8.5.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not
    22992270         it is willing to accept trailer fields in a chunked transfer-coding.
    23002271      </p>
    2301       <p id="rfc.section.9.5.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    2302          accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    2303       </p>
    2304       <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     2272      <p id="rfc.section.8.5.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
     2273         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>).
     2274      </p>
     2275      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    23052276  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] )
    23062277  <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
    23072278  <a href="#header.te" class="smpl">te-ext</a>    = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
    2308 </pre><p id="rfc.section.9.5.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    2309          as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
    2310       </p>
    2311       <p id="rfc.section.9.5.p.5">Examples of its use are:</p>
    2312       <div id="rfc.figure.u.66"></div><pre class="text">  TE: deflate
     2279</pre><p id="rfc.section.8.5.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
     2280         as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
     2281      </p>
     2282      <p id="rfc.section.8.5.p.5">Examples of its use are:</p>
     2283      <div id="rfc.figure.u.64"></div><pre class="text">  TE: deflate
    23132284  TE:
    23142285  TE: trailers, deflate;q=0.5
    2315 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;9.1</a>) whenever TE is present in an HTTP/1.1 message.
    2316       </p>
    2317       <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
     2286</pre><p id="rfc.section.8.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;8.1</a>) whenever TE is present in an HTTP/1.1 message.
     2287      </p>
     2288      <p id="rfc.section.8.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    23182289      <ol>
    23192290         <li>
    … …  
    23292300         <li>
    23302301            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    2331                is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;6.4</a>, a qvalue of 0 means "not acceptable".)
     2302               is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.4</a>, a qvalue of 0 means "not acceptable".)
    23322303            </p>
    23332304         </li>
    … …  
    23382309         </li>
    23392310      </ol>
    2340       <p id="rfc.section.9.5.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
     2311      <p id="rfc.section.8.5.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
    23412312         is always acceptable.
    23422313      </p>
    23432314      <div id="rfc.iref.t.6"></div>
    23442315      <div id="rfc.iref.h.12"></div>
    2345       <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
    2346       <p id="rfc.section.9.6.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
     2316      <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
     2317      <p id="rfc.section.8.6.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
    23472318         chunked transfer-coding.
    23482319      </p>
    2349       <div id="rfc.figure.u.67"></div><pre class="inline"><span id="rfc.iref.g.101"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    2350 </pre><p id="rfc.section.9.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
     2320      <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.99"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
     2321</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
    23512322         to know which header fields to expect in the trailer.
    23522323      </p>
    2353       <p id="rfc.section.9.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
    2354       </p>
    2355       <p id="rfc.section.9.6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
     2324      <p id="rfc.section.8.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
     2325      </p>
     2326      <p id="rfc.section.8.6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
    23562327      </p>
    23572328      <ul>
    … …  
    23622333      <div id="rfc.iref.t.7"></div>
    23632334      <div id="rfc.iref.h.13"></div>
    2364       <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    2365       <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
     2335      <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
     2336      <p id="rfc.section.8.7.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
    23662337         from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
    23672338         are not.
    23682339      </p>
    2369       <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.102"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    2370 </pre><p id="rfc.section.9.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>. An example is:
    2371       </p>
    2372       <div id="rfc.figure.u.69"></div><pre class="text">  Transfer-Encoding: chunked
    2373 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    2374       </p>
    2375       <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
     2340      <div id="rfc.figure.u.66"></div><pre class="inline"><span id="rfc.iref.g.100"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
     2341</pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5.2</a>. An example is:
     2342      </p>
     2343      <div id="rfc.figure.u.67"></div><pre class="text">  Transfer-Encoding: chunked
     2344</pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     2345      </p>
     2346      <p id="rfc.section.8.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
    23762347      <div id="rfc.iref.u.5"></div>
    23772348      <div id="rfc.iref.h.14"></div>
    2378       <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2379       <p id="rfc.section.9.8.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
     2349      <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
     2350      <p id="rfc.section.8.8.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
    23802351         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    23812352      </p>
    2382       <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.103"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>
    2383 </pre><p id="rfc.section.9.8.p.3">For example,</p>
    2384       <div id="rfc.figure.u.71"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2385 </pre><p id="rfc.section.9.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
     2353      <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.101"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#product.tokens" class="smpl">product</a>
     2354</pre><p id="rfc.section.8.8.p.3">For example,</p>
     2355      <div id="rfc.figure.u.69"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     2356</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
    23862357         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    23872358         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    23902361         the server, possibly according to the nature of the request method or target resource).
    23912362      </p>
    2392       <p id="rfc.section.9.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
     2363      <p id="rfc.section.8.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
    23932364         Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    23942365         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
    23952366         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
    23962367      </p>
    2397       <p id="rfc.section.9.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;9.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    2398       </p>
    2399       <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2400          is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    2401       </p>
    2402       <p id="rfc.section.9.8.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
     2368      <p id="rfc.section.8.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2369      </p>
     2370      <p id="rfc.section.8.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
     2371         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2372      </p>
     2373      <p id="rfc.section.8.8.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    24032374         to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    24042375      </p>
    2405       <p id="rfc.section.9.8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     2376      <p id="rfc.section.8.8.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    24062377         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    24072378         below.
    24082379      </p>
    2409       <h3 id="rfc.section.9.8.1"><a href="#rfc.section.9.8.1">9.8.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
    2410       <p id="rfc.section.9.8.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header
     2380      <h3 id="rfc.section.8.8.1"><a href="#rfc.section.8.8.1">8.8.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
     2381      <p id="rfc.section.8.8.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header
    24112382         field. Each registered token is associated with contact information and an optional set of specifications that details how
    24122383         the connection will be processed after it has been upgraded.
    24132384      </p>
    2414       <p id="rfc.section.9.8.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:
     2385      <p id="rfc.section.8.8.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:
    24152386      </p>
    24162387      <ol>
    … …  
    24312402      <div id="rfc.iref.v.1"></div>
    24322403      <div id="rfc.iref.h.15"></div>
    2433       <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    2434       <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
     2404      <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
     2405      <p id="rfc.section.8.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by a proxy or gateway to indicate the intermediate protocols and recipients between the user agent and the server
    24352406         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field used by email
    24362407         systems (<a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a>) and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
    24372408         of all senders along the request/response chain.
    24382409      </p>
    2439       <div id="rfc.figure.u.72"></div><pre class="inline"><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><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></span>  <a href="#header.via" class="smpl">Via</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>
     2410      <div id="rfc.figure.u.70"></div><pre class="inline"><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>               = 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>
    24402411                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    24412412  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a>
    … …  
    24442415  <a href="#header.via" class="smpl">received-by</a>       = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a>
    24452416  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    2446 </pre><p id="rfc.section.9.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
     2417</pre><p id="rfc.section.8.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    24472418         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
    24482419         so that information about the protocol capabilities of upstream applications remains visible to all recipients.
    24492420      </p>
    2450       <p id="rfc.section.9.9.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
     2421      <p id="rfc.section.8.9.p.4">The protocol-name is excluded if and only if it would be "HTTP". The received-by field is normally the host and optional port
    24512422         number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to
    24522423         be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
    24532424      </p>
    2454       <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    2455       </p>
    2456       <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
     2425      <p id="rfc.section.8.9.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
     2426      </p>
     2427      <p id="rfc.section.8.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
    24572428         fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    24582429      </p>
    2459       <p id="rfc.section.9.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
     2430      <p id="rfc.section.8.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    24602431         HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin
    24612432         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    24622433      </p>
    2463       <div id="rfc.figure.u.73"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    2464 </pre><p id="rfc.section.9.9.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
     2434      <div id="rfc.figure.u.71"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2435</pre><p id="rfc.section.8.9.p.9">A proxy or gateway used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled,
    24652436         the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.
    24662437      </p>
    2467       <p id="rfc.section.9.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
     2438      <p id="rfc.section.8.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.
    24682439         For example,
    24692440      </p>
    2470       <div id="rfc.figure.u.74"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    2471 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p>
    2472       <div id="rfc.figure.u.75"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    2473 </pre><p id="rfc.section.9.9.p.14">Senders <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
     2441      <div id="rfc.figure.u.72"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2442</pre><p id="rfc.section.8.9.p.12">could be collapsed to</p>
     2443      <div id="rfc.figure.u.73"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2444</pre><p id="rfc.section.8.9.p.14">Senders <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
    24742445         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    24752446      </p>
    2476       <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    2477       <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    2478       <p id="rfc.section.10.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     2447      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     2448      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     2449      <p id="rfc.section.9.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    24792450      </p>
    24802451      <div id="rfc.table.1">
    … …  
    24942465                  <td class="left">http</td>
    24952466                  <td class="left">standard</td>
    2496                   <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;9.1</a>
     2467                  <td class="left"> <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;8.1</a>
    24972468                  </td>
    24982469               </tr>
    … …  
    25012472                  <td class="left">http</td>
    25022473                  <td class="left">standard</td>
    2503                   <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section&nbsp;9.2</a>
     2474                  <td class="left"> <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">Section&nbsp;8.2</a>
    25042475                  </td>
    25052476               </tr>
    … …  
    25082479                  <td class="left">http</td>
    25092480                  <td class="left">standard</td>
    2510                   <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section&nbsp;9.3</a>
     2481                  <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section&nbsp;8.3</a>
    25112482                  </td>
    25122483               </tr>
    … …  
    25152486                  <td class="left">http</td>
    25162487                  <td class="left">standard</td>
    2517                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>
     2488                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;8.4</a>
    25182489                  </td>
    25192490               </tr>
    … …  
    25222493                  <td class="left">http</td>
    25232494                  <td class="left">standard</td>
    2524                   <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;9.5</a>
     2495                  <td class="left"> <a href="#header.te" id="rfc.xref.header.te.5" title="TE">Section&nbsp;8.5</a>
    25252496                  </td>
    25262497               </tr>
    … …  
    25292500                  <td class="left">http</td>
    25302501                  <td class="left">standard</td>
    2531                   <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;9.6</a>
     2502                  <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section&nbsp;8.6</a>
    25322503                  </td>
    25332504               </tr>
    … …  
    25362507                  <td class="left">http</td>
    25372508                  <td class="left">standard</td>
    2538                   <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;9.7</a>
     2509                  <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.7</a>
    25392510                  </td>
    25402511               </tr>
    … …  
    25432514                  <td class="left">http</td>
    25442515                  <td class="left">standard</td>
    2545                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;9.8</a>
     2516                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;8.8</a>
    25462517                  </td>
    25472518               </tr>
    … …  
    25502521                  <td class="left">http</td>
    25512522                  <td class="left">standard</td>
    2552                   <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;9.9</a>
     2523                  <td class="left"> <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section&nbsp;8.9</a>
    25532524                  </td>
    25542525               </tr>
    … …  
    25562527         </table>
    25572528      </div>
    2558       <p id="rfc.section.10.1.p.2">Furthermore, the header field name "Close" shall be registered as "reserved", as its use as HTTP header field would be in
    2559          conflict with the use of the "close" connection option for the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;9.1</a>).
     2529      <p id="rfc.section.9.1.p.2">Furthermore, the header field name "Close" shall be registered as "reserved", as its use as HTTP header field would be in
     2530         conflict with the use of the "close" connection option for the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section&nbsp;8.1</a>).
    25602531      </p>
    25612532      <div id="rfc.table.u.2">
    … …  
    25742545                  <td class="left">http</td>
    25752546                  <td class="left">reserved</td>
    2576                   <td class="left"> <a href="#header.field.registration" title="Header Field Registration">Section&nbsp;10.1</a>
     2547                  <td class="left"> <a href="#header.field.registration" title="Header Field Registration">Section&nbsp;9.1</a>
    25772548                  </td>
    25782549               </tr>
    … …  
    25802551         </table>
    25812552      </div>
    2582       <p id="rfc.section.10.1.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    2583       <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>
    2584       <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.7.1</a> and <a href="#https.uri" title="https URI scheme">2.7.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
    2585       </p>
    2586       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
    2587       <p id="rfc.section.10.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following
     2553      <p id="rfc.section.9.1.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     2554      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>
     2555      <p id="rfc.section.9.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.7.1</a> and <a href="#https.uri" title="https URI scheme">2.7.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
     2556      </p>
     2557      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
     2558      <p id="rfc.section.9.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following
    25882559         is to be registered with IANA (see <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>).
    25892560      </p>
    25902561      <div id="rfc.iref.m.2"></div>
    25912562      <div id="rfc.iref.m.3"></div>
    2592       <h3 id="rfc.section.10.3.1"><a href="#rfc.section.10.3.1">10.3.1</a>&nbsp;<a id="internet.media.type.message.http" href="#internet.media.type.message.http">Internet Media Type message/http</a></h3>
    2593       <p id="rfc.section.10.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions
     2563      <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a>&nbsp;<a id="internet.media.type.message.http" href="#internet.media.type.message.http">Internet Media Type message/http</a></h3>
     2564      <p id="rfc.section.9.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions
    25942565         for all "message" types regarding line length and encodings.
    25952566      </p>
    2596       <p id="rfc.section.10.3.1.p.2"> </p>
     2567      <p id="rfc.section.9.3.1.p.2"> </p>
    25972568      <dl>
    25982569         <dt>Type name:</dt>
    … …  
    26202591         <dd>none</dd>
    26212592         <dt>Published specification:</dt>
    2622          <dd>This specification (see <a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;10.3.1</a>).
     2593         <dd>This specification (see <a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;9.3.1</a>).
    26232594         </dd>
    26242595         <dt>Applications that use this media type:</dt>
    … …  
    26452616      <div id="rfc.iref.m.4"></div>
    26462617      <div id="rfc.iref.a.5"></div>
    2647       <h3 id="rfc.section.10.3.2"><a href="#rfc.section.10.3.2">10.3.2</a>&nbsp;<a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3>
    2648       <p id="rfc.section.10.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p>
    2649       <p id="rfc.section.10.3.2.p.2"> </p>
     2618      <h3 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a>&nbsp;<a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3>
     2619      <p id="rfc.section.9.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p>
     2620      <p id="rfc.section.9.3.2.p.2"> </p>
    26502621      <dl>
    26512622         <dt>Type name:</dt>
    … …  
    26752646         <dd>none</dd>
    26762647         <dt>Published specification:</dt>
    2677          <dd>This specification (see <a href="#internet.media.type.application.http" title="Internet Media Type application/http">Section&nbsp;10.3.2</a>).
     2648         <dd>This specification (see <a href="#internet.media.type.application.http" title="Internet Media Type application/http">Section&nbsp;9.3.2</a>).
    26782649         </dd>
    26792650         <dt>Applications that use this media type:</dt>
    … …  
    26982669         <dd>IESG</dd>
    26992670      </dl>
    2700       <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2>
    2701       <p id="rfc.section.10.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;6.2.3</a> of this document.
    2702       </p>
    2703       <p id="rfc.section.10.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
     2671      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2>
     2672      <p id="rfc.section.9.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;5.2.3</a> of this document.
     2673      </p>
     2674      <p id="rfc.section.9.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
    27042675      </p>
    27052676      <div id="rfc.table.2">
    … …  
    27172688                  <td class="left">chunked</td>
    27182689                  <td class="left">Transfer in a series of chunks</td>
    2719                   <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>
     2690                  <td class="left"> <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>
    27202691                  </td>
    27212692               </tr>
    … …  
    27232694                  <td class="left">compress</td>
    27242695                  <td class="left">UNIX "compress" program method</td>
    2725                   <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;6.2.2.1</a>
     2696                  <td class="left"> <a href="#compress.coding" title="Compress Coding">Section&nbsp;5.2.2.1</a>
    27262697                  </td>
    27272698               </tr>
    … …  
    27302701                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.2"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.2"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    27312702                  </td>
    2732                   <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;6.2.2.2</a>
     2703                  <td class="left"> <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;5.2.2.2</a>
    27332704                  </td>
    27342705               </tr>
    … …  
    27362707                  <td class="left">gzip</td>
    27372708                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.2"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    2738                   <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;6.2.2.3</a>
     2709                  <td class="left"> <a href="#gzip.coding" title="Gzip Coding">Section&nbsp;5.2.2.3</a>
    27392710                  </td>
    27402711               </tr>
    … …  
    27422713         </table>
    27432714      </div>
    2744       <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
    2745       <p id="rfc.section.10.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;9.8.1</a> of this document.
    2746       </p>
    2747       <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
     2715      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
     2716      <p id="rfc.section.9.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.8.1</a> of this document.
     2717      </p>
     2718      <p id="rfc.section.9.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    27482719      </p>
    27492720      <div id="rfc.table.u.3">
    … …  
    27662737         </table>
    27672738      </div>
    2768       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    2769       <p id="rfc.section.11.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
     2739      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     2740      <p id="rfc.section.10.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
    27702741         as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
    27712742         make some suggestions for reducing security risks.
    27722743      </p>
    2773       <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
    2774       <p id="rfc.section.11.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g., the user's name, location, mail address, passwords,
     2744      <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
     2745      <p id="rfc.section.10.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g., the user's name, location, mail address, passwords,
    27752746         encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information. We very strongly recommend that a convenient interface
    27762747         be provided for the user to control dissemination of such information, and that designers and implementors be particularly
    … …  
    27782749         highly adverse publicity for the implementor's company.
    27792750      </p>
    2780       <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
    2781       <p id="rfc.section.11.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
     2751      <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
     2752      <p id="rfc.section.10.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
    27822753         of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries.
    27832754         People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission
    27842755         of any individuals that are identifiable by the published results.
    27852756      </p>
    2786       <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
    2787       <p id="rfc.section.11.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
     2757      <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
     2758      <p id="rfc.section.10.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
    27882759         If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft
    27892760         Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On
    … …  
    27932764         bugs in such HTTP server implementations have turned into security risks.
    27942765      </p>
    2795       <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
    2796       <p id="rfc.section.11.4.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
     2766      <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2>
     2767      <p id="rfc.section.10.4.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the
    27972768         deliberate misassociation of IP addresses and DNS names not protected by DNSSec. Clients need to be cautious in assuming the
    27982769         validity of an IP number/DNS name association unless the response is protected by DNSSec (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>).
    27992770      </p>
    2800       <h2 id="rfc.section.11.5"><a href="#rfc.section.11.5">11.5</a>&nbsp;<a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2>
    2801       <p id="rfc.section.11.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise
     2771      <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2>
     2772      <p id="rfc.section.10.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise
    28022773         of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related
    28032774         information, personal information about individual users and organizations, and proprietary information belonging to users
    … …  
    28052776         might be used in the commission of a wide range of potential attacks.
    28062777      </p>
    2807       <p id="rfc.section.11.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports
     2778      <p id="rfc.section.10.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports
    28082779         sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information,
    28092780         and/or information about organizations. Log information needs to be carefully guarded, and appropriate guidelines for use
    2810          need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
    2811       </p>
    2812       <p id="rfc.section.11.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the
     2781         need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;10.2</a>).
     2782      </p>
     2783      <p id="rfc.section.10.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the
    28132784         configuration options they provide to proxy operators (especially the default configuration).
    28142785      </p>
    2815       <p id="rfc.section.11.5.p.4">Users of a proxy need to be aware that proxies are no trustworthier than the people who run them; HTTP itself cannot solve
     2786      <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no trustworthier than the people who run them; HTTP itself cannot solve
    28162787         this problem.
    28172788      </p>
    2818       <p id="rfc.section.11.5.p.5">The judicious use of cryptography, when appropriate, might suffice to protect against a broad range of security and privacy
     2789      <p id="rfc.section.10.5.p.5">The judicious use of cryptography, when appropriate, might suffice to protect against a broad range of security and privacy
    28192790         attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
    28202791      </p>
    2821       <h2 id="rfc.section.11.6"><a href="#rfc.section.11.6">11.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>
    2822       <p id="rfc.section.11.6.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
     2792      <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>
     2793      <p id="rfc.section.10.6.p.1">Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform
    28232794         a Denial of Service against implementations that accept fields with unlimited lengths.
    28242795      </p>
    2825       <p id="rfc.section.11.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
     2796      <p id="rfc.section.10.6.p.2">To promote interoperability, this specification makes specific recommendations for size limits on request-targets (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
    28262797         that most implementations will choose substantially higher limits.
    28272798      </p>
    2828       <p id="rfc.section.11.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    2829       </p>
    2830       <p id="rfc.section.11.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
    2831       </p>
    2832       <h2 id="rfc.section.11.7"><a href="#rfc.section.11.7">11.7</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
    2833       <p id="rfc.section.11.7.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    2834       <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2835       <p id="rfc.section.12.p.1">This document revision builds on the work that went into <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a> and its predecessors. See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for detailed acknowledgements.
    2836       </p>
    2837       <p id="rfc.section.12.p.2">Since 1999, many contributors have helped by reporting bugs, asking smart questions, drafting and reviewing text, and discussing
     2799      <p id="rfc.section.10.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2800      </p>
     2801      <p id="rfc.section.10.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
     2802      </p>
     2803      <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
     2804      <p id="rfc.section.10.7.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
     2805      <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     2806      <p id="rfc.section.11.p.1">This document revision builds on the work that went into <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a> and its predecessors. See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for detailed acknowledgements.
     2807      </p>
     2808      <p id="rfc.section.11.p.2">Since 1999, many contributors have helped by reporting bugs, asking smart questions, drafting and reviewing text, and discussing
    28382809         open issues:
    28392810      </p>
    2840       <p id="rfc.section.12.p.3">Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Petersson, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian McBarron, Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Anderson, Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges (for coming up with the term 'effective Request-URI'), Jeff Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Kemp, John Panzer, John Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, Matt Lynch, Max Clark, Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Alvarez, Noah Slater, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, Peter Saint-Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence (for maintaining the original issues list), Sean B. Palmer, Shane McCarron, Stefan Eissing, Stefanos Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang, Yutaka Oiwa, and Zed A. Shaw.</p>
    2841       <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References
     2811      <p id="rfc.section.11.p.3">Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Petersson, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian McBarron, Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Anderson, Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges (for coming up with the term 'effective Request-URI'), Jeff Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Kemp, John Panzer, John Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, Matt Lynch, Max Clark, Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Alvarez, Noah Slater, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, Peter Saint-Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence (for maintaining the original issues list), Sean B. Palmer, Shane McCarron, Stefan Eissing, Stefanos Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang, Yutaka Oiwa, and Zed A. Shaw.</p>
     2812      <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References
    28422813      </h1>
    2843       <h2 id="rfc.references.1"><a href="#rfc.section.13.1" id="rfc.section.13.1">13.1</a> Normative References
     2814      <h2 id="rfc.references.1"><a href="#rfc.section.12.1" id="rfc.section.12.1">12.1</a> Normative References
    28442815      </h2>
    28452816      <table>                     
    … …  
    29012872         </tr>
    29022873      </table>
    2903       <h2 id="rfc.references.2"><a href="#rfc.section.13.2" id="rfc.section.13.2">13.2</a> Informative References
     2874      <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References
    29042875      </h2>
    29052876      <table>                                                   
    … …  
    30803051      <p id="rfc.section.A.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    30813052      <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3>
    3082       <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.
     3053      <p id="rfc.section.A.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.4" title="Host">Section&nbsp;8.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;3.1.1.2</a>) are among the most important changes defined by HTTP/1.1.
    30833054      </p>
    30843055      <p id="rfc.section.A.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
    … …  
    31043075         Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when
    31053076         talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce
    3106          a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section&nbsp;9.1</a>.
     3077         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section&nbsp;8.1</a>.
    31073078      </p>
    31083079      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    31233094      <p id="rfc.section.A.2.p.6">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>)
    31243095      </p>
    3125       <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">6.2</a>)
     3096      <p id="rfc.section.A.2.p.7">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">5.2</a>)
    31263097      </p>
    31273098      <p id="rfc.section.A.2.p.8">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk
    … …  
    31293100      </p>
    31303101      <p id="rfc.section.A.2.p.9">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore
    3131          disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>)
    3132       </p>
    3133       <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;7.1.4</a>)
    3134       </p>
    3135       <p id="rfc.section.A.2.p.11">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    3136       </p>
    3137       <p id="rfc.section.A.2.p.12">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section&nbsp;9.1</a>)
    3138       </p>
    3139       <p id="rfc.section.A.2.p.13">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;9.8</a>)
     3102         disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.2.1</a>)
     3103      </p>
     3104      <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.1.4</a>)
     3105      </p>
     3106      <p id="rfc.section.A.2.p.11">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;8</a>)
     3107      </p>
     3108      <p id="rfc.section.A.2.p.12">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section&nbsp;8.1</a>)
     3109      </p>
     3110      <p id="rfc.section.A.2.p.13">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.8</a>)
    31403111      </p>
    31413112      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    3142       <div id="rfc.figure.u.76"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
     3113      <div id="rfc.figure.u.74"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    31433114
    31443115<a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF
    … …  
    31643135<a href="#rule.whitespace" class="smpl">RWS</a> = 1*( SP / HTAB / obs-fold )
    31653136<a href="#reason.phrase" class="smpl">Reason-Phrase</a> = *( HTAB / SP / VCHAR / obs-text )
    3166 <a href="#request" class="smpl">Request</a> = Request-Line *( header-field CRLF ) CRLF [ message-body ]
    3167 <a href="#request-line" class="smpl">Request-Line</a> = Method SP request-target SP HTTP-Version CRLF
    3168 <a href="#response" class="smpl">Response</a> = Status-Line *( header-field CRLF ) CRLF [ message-body ]
     3137<a href="#request.line" class="smpl">Request-Line</a> = Method SP request-target SP HTTP-Version CRLF
    31693138
    31703139<a href="#status.code" class="smpl">Status-Code</a> = 3DIGIT
    3171 <a href="#status-line" class="smpl">Status-Line</a> = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
     3140<a href="#status.line" class="smpl">Status-Line</a> = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
    31723141
    31733142<a href="#header.te" class="smpl">TE</a> = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
    … …  
    33063275
    33073276<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    3308 </pre> <div id="rfc.figure.u.77"></div>
     3277</pre> <div id="rfc.figure.u.75"></div>
    33093278      <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used
    33103279; Connection defined but not used
    … …  
    33133282; HTTP-message defined but not used
    33143283; Host defined but not used
    3315 ; Request defined but not used
    3316 ; Response defined but not used
    33173284; TE defined but not used
    33183285; Trailer defined but not used
    … …  
    36853652                  <li>absolute-URI form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.3">4.1</a></li>
    36863653                  <li>accelerator&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.4</b></a></li>
    3687                   <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>10.3.2</b></a></li>
     3654                  <li>application/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.a.5"><b>9.3.2</b></a></li>
    36883655                  <li>asterisk form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.2">4.1</a></li>
    36893656                  <li>authority form (of request-target)&nbsp;&nbsp;<a href="#rfc.iref.a.4">4.1</a></li>
    … …  
    36913658            </li>
    36923659            <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul>
    3693                   <li><em>BCP97</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP97.1">13.1</a>, <a href="#rfc.xref.BCP97.2">13.1</a>, <a href="#rfc.xref.BCP97.3">13.1</a>, <a href="#BCP97"><b>13.2</b></a></li>
     3660                  <li><em>BCP97</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP97.1">12.1</a>, <a href="#rfc.xref.BCP97.2">12.1</a>, <a href="#rfc.xref.BCP97.3">12.1</a>, <a href="#BCP97"><b>12.2</b></a></li>
    36943661                  <li>browser&nbsp;&nbsp;<a href="#rfc.iref.b.1"><b>2.1</b></a></li>
    36953662               </ul>
    … …  
    36993666                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>2.5</b></a></li>
    37003667                  <li>captive portal&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>2.4</b></a></li>
    3701                   <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">6.2.1</a></li>
     3668                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">5.2.1</a></li>
    37023669                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    37033670                  <li>Coding Format&nbsp;&nbsp;
    37043671                     <ul>
    3705                         <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.7">6.2.1</a></li>
    3706                         <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.9">6.2.2.1</a></li>
    3707                         <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.10">6.2.2.2</a></li>
    3708                         <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.11">6.2.2.3</a></li>
     3672                        <li>chunked&nbsp;&nbsp;<a href="#rfc.iref.c.7">5.2.1</a></li>
     3673                        <li>compress&nbsp;&nbsp;<a href="#rfc.iref.c.9">5.2.2.1</a></li>
     3674                        <li>deflate&nbsp;&nbsp;<a href="#rfc.iref.c.10">5.2.2.2</a></li>
     3675                        <li>gzip&nbsp;&nbsp;<a href="#rfc.iref.c.11">5.2.2.3</a></li>
    37093676                     </ul>
    37103677                  </li>
    3711                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li>
     3678                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.2.2.1</a></li>
    37123679                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3713                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.xref.header.connection.7">9</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
    3714                   <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">9</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.3">10.1</a></li>
     3680                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.5</a>, <a href="#rfc.xref.header.connection.9">8.8</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
     3681                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
    37153682               </ul>
    37163683            </li>
    37173684            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    3718                   <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">9</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li>
    3719                   <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">6.2.2.2</a></li>
     3685                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">8</a>, <a href="#rfc.iref.d.3"><b>8.3</b></a>, <a href="#rfc.xref.header.date.3">9.1</a></li>
     3686                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">5.2.2.2</a></li>
    37203687                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.4</b></a></li>
    37213688               </ul>
    … …  
    37313698                        <li><tt>absolute-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>2.7</b></a></li>
    37323699                        <li>ALPHA&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2</b></a></li>
    3733                         <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>6.1</b></a></li>
    3734                         <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>6.2</b></a></li>
     3700                        <li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>5.1</b></a></li>
     3701                        <li><tt>attribute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>5.2</b></a></li>
    37353702                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    37363703                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>1.2.2</b></a></li>
    3737                         <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>6.2.1</b></a></li>
    3738                         <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>6.2.1</b></a></li>
    3739                         <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>6.2.1</b></a></li>
    3740                         <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>6.2.1</b></a></li>
    3741                         <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>6.2.1</b></a></li>
    3742                         <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>6.2.1</b></a></li>
    3743                         <li><tt>Chunked-Body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>6.2.1</b></a></li>
     3704                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>5.2.1</b></a></li>
     3705                        <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>5.2.1</b></a></li>
     3706                        <li><tt>chunk-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.2.1</b></a></li>
     3707                        <li><tt>chunk-ext-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.2.1</b></a></li>
     3708                        <li><tt>chunk-ext-val</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.81"><b>5.2.1</b></a></li>
     3709                        <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>5.2.1</b></a></li>
     3710                        <li><tt>Chunked-Body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>5.2.1</b></a></li>
    37443711                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.3</b></a></li>
    3745                         <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>9.1</b></a></li>
    3746                         <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>9.1</b></a></li>
    3747                         <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.94"><b>9.2</b></a></li>
     3712                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>8.1</b></a></li>
     3713                        <li><tt>connection-token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>8.1</b></a></li>
     3714                        <li><tt>Content-Length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>8.2</b></a></li>
    37483715                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    37493716                        <li>CRLF&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>1.2</b></a></li>
    37503717                        <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.3</b></a></li>
    37513718                        <li>CTL&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>1.2</b></a></li>
    3752                         <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.95"><b>9.3</b></a></li>
    3753                         <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>6.1</b></a></li>
    3754                         <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>6.2</b></a></li>
    3755                         <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>6.2</b></a></li>
    3756                         <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>6.1</b></a></li>
    3757                         <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>6.1</b></a></li>
    3758                         <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>6.1</b></a></li>
     3719                        <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>8.3</b></a></li>
     3720                        <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>5.1</b></a></li>
     3721                        <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>5.2</b></a></li>
     3722                        <li><tt>date3</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>5.2</b></a></li>
     3723                        <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>5.1</b></a></li>
     3724                        <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>5.1</b></a></li>
     3725                        <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>5.1</b></a></li>
    37593726                        <li>DIGIT&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>1.2</b></a></li>
    37603727                        <li>DQUOTE&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>1.2</b></a></li>
    … …  
    37623729                        <li><tt>field-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2</b></a></li>
    37633730                        <li><tt>field-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2</b></a></li>
    3764                         <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>6.1</b></a></li>
     3731                        <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>5.1</b></a></li>
    37653732                        <li><tt>header-field</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>3.2</b></a></li>
    37663733                        <li>HEXDIG&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>1.2</b></a></li>
    3767                         <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.96"><b>9.4</b></a></li>
    3768                         <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>6.1</b></a></li>
     3734                        <li><tt>Host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.94"><b>8.4</b></a></li>
     3735                        <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>5.1</b></a></li>
    37693736                        <li>HTAB&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>1.2</b></a></li>
    3770                         <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>6.1</b></a></li>
     3737                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>5.1</b></a></li>
    37713738                        <li><tt>HTTP-message</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3</b></a></li>
    37723739                        <li><tt>HTTP-Prot-Name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.6</b></a></li>
    … …  
    37743741                        <li><tt>HTTP-Version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>2.6</b></a></li>
    37753742                        <li><tt>https-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>2.7.2</b></a></li>
    3776                         <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>6.2.1</b></a></li>
     3743                        <li><tt>last-chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>5.2.1</b></a></li>
    37773744                        <li>LF&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>1.2</b></a></li>
    37783745                        <li><tt>message-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.3</b></a></li>
    37793746                        <li><tt>Method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.1.1</b></a></li>
    3780                         <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.59"><b>6.1</b></a></li>
    3781                         <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>6.1</b></a></li>
    3782                         <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.67"><b>6.1</b></a></li>
     3747                        <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>5.1</b></a></li>
     3748                        <li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>5.1</b></a></li>
     3749                        <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>5.1</b></a></li>
    37833750                        <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.3</b></a></li>
    37843751                        <li>OCTET&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>1.2</b></a></li>
    … …  
    37863753                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    37873754                        <li><tt>port</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7</b></a></li>
    3788                         <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>6.3</b></a></li>
    3789                         <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>6.3</b></a></li>
    3790                         <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.106"><b>9.9</b></a></li>
    3791                         <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.107"><b>9.9</b></a></li>
    3792                         <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.109"><b>9.9</b></a></li>
     3755                        <li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>5.3</b></a></li>
     3756                        <li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.3</b></a></li>
     3757                        <li><tt>protocol-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.104"><b>8.9</b></a></li>
     3758                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.105"><b>8.9</b></a></li>
     3759                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.107"><b>8.9</b></a></li>
    37933760                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.3</b></a></li>
    3794                         <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.87"><b>6.2.1</b></a></li>
     3761                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.2.1</b></a></li>
    37953762                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>2.7</b></a></li>
    37963763                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.3</b></a></li>
    37973764                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.3</b></a></li>
    3798                         <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.86"><b>6.2.1</b></a></li>
     3765                        <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.84"><b>5.2.1</b></a></li>
    37993766                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.3</b></a></li>
    3800                         <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>6.4</b></a></li>
     3767                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.89"><b>5.4</b></a></li>
    38013768                        <li><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>3.1.2.2</b></a></li>
    3802                         <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.108"><b>9.9</b></a></li>
    3803                         <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.105"><b>9.9</b></a></li>
    3804                         <li><tt>Request</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>4</b></a></li>
     3769                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.106"><b>8.9</b></a></li>
     3770                        <li><tt>received-protocol</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.103"><b>8.9</b></a></li>
    38053771                        <li><tt>Request-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.1</b></a></li>
    38063772                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.1.2</b></a></li>
    3807                         <li><tt>Response</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>5</b></a></li>
    3808                         <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>6.1</b></a></li>
    3809                         <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>6.1</b></a></li>
     3773                        <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>5.1</b></a></li>
     3774                        <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.66"><b>5.1</b></a></li>
    38103775                        <li><tt>RWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>1.2.2</b></a></li>
    3811                         <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>6.1</b></a></li>
     3776                        <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.58"><b>5.1</b></a></li>
    38123777                        <li>SP&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>1.2</b></a></li>
    38133778                        <li><tt>special</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.3</b></a></li>
    … …  
    38153780                        <li><tt>Status-Code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>3.1.2.1</b></a></li>
    38163781                        <li><tt>Status-Line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>3.1.2</b></a></li>
    3817                         <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.98"><b>9.5</b></a></li>
     3782                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.96"><b>8.5</b></a></li>
    38183783                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.3</b></a></li>
    3819                         <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.97"><b>9.5</b></a></li>
    3820                         <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.100"><b>9.5</b></a></li>
    3821                         <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.99"><b>9.5</b></a></li>
    3822                         <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>6.1</b></a></li>
     3784                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.95"><b>8.5</b></a></li>
     3785                        <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.98"><b>8.5</b></a></li>
     3786                        <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.97"><b>8.5</b></a></li>
     3787                        <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>5.1</b></a></li>
    38233788                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.3</b></a></li>
    3824                         <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.101"><b>9.6</b></a></li>
    3825                         <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>6.2.1</b></a></li>
    3826                         <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>6.2</b></a></li>
    3827                         <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.102"><b>9.7</b></a></li>
    3828                         <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>6.2</b></a></li>
    3829                         <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>6.2</b></a></li>
    3830                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.103"><b>9.8</b></a></li>
     3789                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.99"><b>8.6</b></a></li>
     3790                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.83"><b>5.2.1</b></a></li>
     3791                        <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.68"><b>5.2</b></a></li>
     3792                        <li><tt>Transfer-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.100"><b>8.7</b></a></li>
     3793                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>5.2</b></a></li>
     3794                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>5.2</b></a></li>
     3795                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.101"><b>8.8</b></a></li>
    38313796                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>2.7</b></a></li>
    38323797                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
    3833                         <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>6.2</b></a></li>
     3798                        <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>5.2</b></a></li>
    38343799                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    3835                         <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.104"><b>9.9</b></a></li>
     3800                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.102"><b>8.9</b></a></li>
    38363801                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.3</b></a></li>
    3837                         <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.65"><b>6.1</b></a></li>
     3802                        <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>5.1</b></a></li>
    38383803                     </ul>
    38393804                  </li>
    3840                   <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.88">6.2.2.3</a></li>
     3805                  <li>gzip (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.g.86">5.2.2.3</a></li>
    38413806               </ul>
    38423807            </li>
    … …  
    38453810                  <li>Header Fields&nbsp;&nbsp;
    38463811                     <ul>
    3847                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.xref.header.connection.7">9</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.8">9.5</a>, <a href="#rfc.xref.header.connection.9">9.8</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">10.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
    3848                         <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">9</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.3">10.1</a></li>
    3849                         <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">9</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.3">10.1</a></li>
    3850                         <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">9</a>, <a href="#rfc.iref.h.10"><b>9.4</b></a>, <a href="#rfc.xref.header.host.3">10.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
    3851                         <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.xref.header.te.4">9</a>, <a href="#rfc.iref.h.11"><b>9.5</b></a>, <a href="#rfc.xref.header.te.5">10.1</a></li>
    3852                         <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">6.2.1</a>, <a href="#rfc.xref.header.trailer.2">9</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>
    3853                         <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">6.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">9</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>
    3854                         <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">9</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    3855                         <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">9</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>
     3812                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.5</a>, <a href="#rfc.xref.header.connection.9">8.8</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
     3813                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
     3814                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.2</a>, <a href="#rfc.xref.header.date.2">8</a>, <a href="#rfc.iref.h.8"><b>8.3</b></a>, <a href="#rfc.xref.header.date.3">9.1</a></li>
     3815                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.10"><b>8.4</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3816                        <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.2</a>, <a href="#rfc.xref.header.te.2">5.2.1</a>, <a href="#rfc.xref.header.te.3">5.4</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.h.11"><b>8.5</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
     3817                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.2.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.h.12"><b>8.6</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3818                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.h.13"><b>8.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
     3819                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.h.14"><b>8.8</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3820                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.h.15"><b>8.9</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    38563821                     </ul>
    38573822                  </li>
    38583823                  <li>header section&nbsp;&nbsp;<a href="#rfc.iref.h.3">3</a></li>
    38593824                  <li>headers&nbsp;&nbsp;<a href="#rfc.iref.h.4">3</a></li>
    3860                   <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">9</a>, <a href="#rfc.iref.h.9"><b>9.4</b></a>, <a href="#rfc.xref.header.host.3">10.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
     3825                  <li>Host header field&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.4</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>
    38613826                  <li>http URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.7.1</b></a></li>
    38623827                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.2">2.7.2</a></li>
    … …  
    38673832                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.4</b></a></li>
    38683833                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.4</b></a></li>
    3869                   <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2.1</a>, <a href="#ISO-8859-1"><b>13.1</b></a></li>
     3834                  <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2.1</a>, <a href="#ISO-8859-1"><b>12.1</b></a></li>
    38703835               </ul>
    38713836            </li>
    38723837            <li><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul>
    3873                   <li><em>Kri2001</em>&nbsp;&nbsp;<a href="#rfc.xref.Kri2001.1">3.2</a>, <a href="#Kri2001"><b>13.2</b></a></li>
     3838                  <li><em>Kri2001</em>&nbsp;&nbsp;<a href="#rfc.xref.Kri2001.1">3.2</a>, <a href="#Kri2001"><b>12.2</b></a></li>
    38743839               </ul>
    38753840            </li>
    … …  
    38773842                  <li>Media Type&nbsp;&nbsp;
    38783843                     <ul>
    3879                         <li>application/http&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>10.3.2</b></a></li>
    3880                         <li>message/http&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>10.3.1</b></a></li>
     3844                        <li>application/http&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>9.3.2</b></a></li>
     3845                        <li>message/http&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>9.3.1</b></a></li>
    38813846                     </ul>
    38823847                  </li>
    38833848                  <li>message&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>2.1</b></a></li>
    3884                   <li>message/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>10.3.1</b></a></li>
     3849                  <li>message/http Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>9.3.1</b></a></li>
    38853850               </ul>
    38863851            </li>
    38873852            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    3888                   <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">7.1.1</a>, <a href="#Nie1997"><b>13.2</b></a></li>
     3853                  <li><em>Nie1997</em>&nbsp;&nbsp;<a href="#rfc.xref.Nie1997.1">6.1.1</a>, <a href="#Nie1997"><b>12.2</b></a></li>
    38893854                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.4</b></a></li>
    38903855               </ul>
    … …  
    38973862            </li>
    38983863            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3899                   <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li>
    3900                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">3.1.1.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.2</a>, <a href="#rfc.xref.Part2.4">3.1.2.1</a>, <a href="#rfc.xref.Part2.5">3.2</a>, <a href="#rfc.xref.Part2.6">4.1</a>, <a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a>, <a href="#rfc.xref.Part2.12">7.2.3</a>, <a href="#rfc.xref.Part2.13">9.8</a>, <a href="#rfc.xref.Part2.14">11.6</a>, <a href="#rfc.xref.Part2.15">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul>
    3901                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">3.1.1.1</a></li>
    3902                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.2</a></li>
    3903                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.2.1</a></li>
    3904                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a></li>
    3905                         <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">4.1</a></li>
    3906                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">7.2.3</a></li>
    3907                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">7.2.3</a></li>
     3864                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
     3865                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">4.1</a>, <a href="#rfc.xref.Part2.8">6.1.2.2</a>, <a href="#rfc.xref.Part2.9">6.1.4</a>, <a href="#rfc.xref.Part2.10">6.2.3</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">8.8</a>, <a href="#rfc.xref.Part2.15">10.6</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3866                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
     3867                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
     3868                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
     3869                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">6.1.2.2</a>, <a href="#rfc.xref.Part2.9">6.1.4</a></li>
     3870                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">4.1</a></li>
     3871                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">6.2.3</a></li>
     3872                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a></li>
    39083873                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a></li>
    3909                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">9.8</a></li>
    3910                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">11.6</a></li>
    3911                         <li><em>Section 7.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.2</a>, <a href="#rfc.xref.Part2.14">11.6</a></li>
    3912                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a></li>
     3874                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">8.8</a></li>
     3875                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">10.6</a></li>
     3876                        <li><em>Section 7.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.15">10.6</a></li>
     3877                        <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a></li>
    39133878                     </ul>
    39143879                  </li>
    3915                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.3">6.4</a>, <a href="#rfc.xref.Part3.4">7.1.3.2</a>, <a href="#rfc.xref.Part3.5">9.7</a>, <a href="#Part3"><b>13.1</b></a><ul>
    3916                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">6.2.3</a>, <a href="#rfc.xref.Part3.5">9.7</a></li>
    3917                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">6.4</a></li>
     3880                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">5.2.3</a>, <a href="#rfc.xref.Part3.3">5.4</a>, <a href="#rfc.xref.Part3.4">6.1.3.2</a>, <a href="#rfc.xref.Part3.5">8.7</a>, <a href="#Part3"><b>12.1</b></a><ul>
     3881                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">5.2.3</a>, <a href="#rfc.xref.Part3.5">8.7</a></li>
     3882                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">5.4</a></li>
    39183883                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
    39193884                     </ul>
    39203885                  </li>
    3921                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a>, <a href="#rfc.xref.Part6.6">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul>
     3886                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a>, <a href="#rfc.xref.Part6.6">8.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
    39223887                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.5</a></li>
    39233888                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    3924                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">9.1</a></li>
    3925                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li>
     3889                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">8.1</a></li>
     3890                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.5">6.1.3.2</a></li>
    39263891                     </ul>
    39273892                  </li>
    … …  
    39353900                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li>
    39363901                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.4</b></a></li>
    3937                   <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul>
    3938                         <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">6.1</a></li>
     3902                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">5.1</a>, <a href="#rfc.xref.RFC1123.2">5.1</a>, <a href="#RFC1123"><b>12.2</b></a><ul>
     3903                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">5.1</a></li>
    39393904                     </ul>
    39403905                  </li>
    3941                   <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>13.2</b></a></li>
    3942                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>13.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
    3943                   <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1950.2">10.4</a>, <a href="#RFC1950"><b>13.1</b></a></li>
    3944                   <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">6.2.2.2</a>, <a href="#rfc.xref.RFC1951.2">10.4</a>, <a href="#RFC1951"><b>13.1</b></a></li>
    3945                   <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">6.2.2.3</a>, <a href="#rfc.xref.RFC1952.2">10.4</a>, <a href="#RFC1952"><b>13.1</b></a></li>
    3946                   <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">6.2</a>, <a href="#RFC2045"><b>13.2</b></a><ul>
    3947                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">6.2</a></li>
     3906                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.4</a>, <a href="#RFC1919"><b>12.2</b></a></li>
     3907                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>12.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
     3908                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">5.2.2.2</a>, <a href="#rfc.xref.RFC1950.2">9.4</a>, <a href="#RFC1950"><b>12.1</b></a></li>
     3909                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">5.2.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
     3910                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">5.2.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
     3911                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5.2</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
     3912                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">5.2</a></li>
    39483913                     </ul>
    39493914                  </li>
    3950                   <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.1</a>, <a href="#RFC2047"><b>13.2</b></a></li>
    3951                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.4">7.2.3</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a><ul>
    3952                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a></li>
     3915                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.1</a>, <a href="#RFC2047"><b>12.2</b></a></li>
     3916                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">§</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.1.3</a>, <a href="#rfc.xref.RFC2068.4">6.2.3</a>, <a href="#rfc.xref.RFC2068.5">12.1</a>, <a href="#rfc.xref.RFC2068.6">12.1</a>, <a href="#rfc.xref.RFC2068.7">12.1</a>, <a href="#RFC2068"><b>12.2</b></a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a><ul>
     3917                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.1.3</a>, <a href="#rfc.xref.RFC2068.8">A.1.2</a></li>
    39533918                     </ul>
    39543919                  </li>
    3955                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>13.1</b></a></li>
    3956                   <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">§</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#RFC2145"><b>13.2</b></a></li>
    3957                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.6</a>, <a href="#rfc.xref.RFC2616.4">12</a>, <a href="#rfc.xref.RFC2616.5">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.6">C.1</a><ul>
    3958                         <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">12</a></li>
     3920                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
     3921                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">§</a>, <a href="#rfc.xref.RFC2145.2">1</a>, <a href="#RFC2145"><b>12.2</b></a></li>
     3922                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">1</a>, <a href="#rfc.xref.RFC2616.3">2.6</a>, <a href="#rfc.xref.RFC2616.4">11</a>, <a href="#rfc.xref.RFC2616.5">11</a>, <a href="#RFC2616"><b>12.2</b></a>, <a href="#rfc.xref.RFC2616.6">C.1</a><ul>
     3923                        <li><em>Section 16</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.5">11</a></li>
    39593924                     </ul>
    39603925                  </li>
    3961                   <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul>
    3962                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">10.5</a></li>
     3926                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">9.5</a>, <a href="#RFC2817"><b>12.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul>
     3927                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">9.5</a></li>
    39633928                     </ul>
    39643929                  </li>
    3965                   <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>13.2</b></a></li>
    3966                   <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>13.2</b></a></li>
    3967                   <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>13.2</b></a></li>
    3968                   <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">10.1</a>, <a href="#RFC3864"><b>13.2</b></a></li>
    3969                   <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>13.1</b></a><ul>
     3930                  <li><em>RFC2818</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2818.1">2.7.2</a>, <a href="#RFC2818"><b>12.2</b></a></li>
     3931                  <li><em>RFC2965</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2965.1">3.2</a>, <a href="#RFC2965"><b>12.2</b></a></li>
     3932                  <li><em>RFC3040</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3040.1">2.4</a>, <a href="#RFC3040"><b>12.2</b></a></li>
     3933                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">9.1</a>, <a href="#RFC3864"><b>12.2</b></a></li>
     3934                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7</a>, <a href="#rfc.xref.RFC3986.13">2.7</a>, <a href="#rfc.xref.RFC3986.14">2.7.1</a>, <a href="#rfc.xref.RFC3986.15">2.7.1</a>, <a href="#rfc.xref.RFC3986.16">2.7.3</a>, <a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.18">3.1.1.2</a>, <a href="#rfc.xref.RFC3986.19">4.1</a>, <a href="#rfc.xref.RFC3986.20">4.3</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
    39703935                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.17">2.7.3</a>, <a href="#rfc.xref.RFC3986.19">4.1</a></li>
    39713936                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.8">2.7</a></li>
    … …  
    39823947                     </ul>
    39833948                  </li>
    3984                   <li><em>RFC4033</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4033.1">11.4</a>, <a href="#RFC4033"><b>13.2</b></a></li>
    3985                   <li><em>RFC4288</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4288.1">10.3</a>, <a href="#RFC4288"><b>13.2</b></a></li>
    3986                   <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">10.2</a>, <a href="#RFC4395"><b>13.2</b></a></li>
    3987                   <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.2</a>, <a href="#RFC4559"><b>13.2</b></a></li>
    3988                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">6.2.3</a>, <a href="#rfc.xref.RFC5226.2">9.8.1</a>, <a href="#RFC5226"><b>13.2</b></a><ul>
    3989                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">6.2.3</a>, <a href="#rfc.xref.RFC5226.2">9.8.1</a></li>
     3949                  <li><em>RFC4033</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4033.1">10.4</a>, <a href="#RFC4033"><b>12.2</b></a></li>
     3950                  <li><em>RFC4288</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4288.1">9.3</a>, <a href="#RFC4288"><b>12.2</b></a></li>
     3951                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">9.2</a>, <a href="#RFC4395"><b>12.2</b></a></li>
     3952                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.2</a>, <a href="#RFC4559"><b>12.2</b></a></li>
     3953                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.2.3</a>, <a href="#rfc.xref.RFC5226.2">8.8.1</a>, <a href="#RFC5226"><b>12.2</b></a><ul>
     3954                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.2.3</a>, <a href="#rfc.xref.RFC5226.2">8.8.1</a></li>
    39903955                     </ul>
    39913956                  </li>
    3992                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">1.2.1</a>, <a href="#RFC5234"><b>13.1</b></a><ul>
     3957                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">1.2.1</a>, <a href="#RFC5234"><b>12.1</b></a><ul>
    39933958                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">1.2</a></li>
    39943959                     </ul>
    39953960                  </li>
    3996                   <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">6.1</a>, <a href="#rfc.xref.RFC5322.4">9.3</a>, <a href="#rfc.xref.RFC5322.5">9.9</a>, <a href="#RFC5322"><b>13.2</b></a><ul>
    3997                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">6.1</a></li>
    3998                         <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">9.3</a></li>
    3999                         <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.5">9.9</a></li>
     3961                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.1</a>, <a href="#rfc.xref.RFC5322.4">8.3</a>, <a href="#rfc.xref.RFC5322.5">8.9</a>, <a href="#RFC5322"><b>12.2</b></a><ul>
     3962                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">5.1</a></li>
     3963                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">8.3</a></li>
     3964                        <li><em>Section 3.6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.5">8.9</a></li>
    40003965                     </ul>
    40013966                  </li>
    4002                   <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>13.2</b></a></li>
     3967                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>12.2</b></a></li>
    40033968               </ul>
    40043969            </li>
    … …  
    40063971                  <li>sender&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>2.1</b></a></li>
    40073972                  <li>server&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>2.1</b></a></li>
    4008                   <li><em>Spe</em>&nbsp;&nbsp;<a href="#rfc.xref.Spe.1">7.1.1</a>, <a href="#Spe"><b>13.2</b></a></li>
     3973                  <li><em>Spe</em>&nbsp;&nbsp;<a href="#rfc.xref.Spe.1">6.1.1</a>, <a href="#Spe"><b>12.2</b></a></li>
    40093974                  <li>spider&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>2.1</b></a></li>
    40103975               </ul>
    … …  
    40123977            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    40133978                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.4"><b>4.3</b></a></li>
    4014                   <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.xref.header.te.4">9</a>, <a href="#rfc.iref.t.5"><b>9.5</b></a>, <a href="#rfc.xref.header.te.5">10.1</a></li>
    4015                   <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">7.1.1</a>, <a href="#Tou1998"><b>13.2</b></a></li>
    4016                   <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">6.2.1</a>, <a href="#rfc.xref.header.trailer.2">9</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>
    4017                   <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">6.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">9</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>
     3979                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">5.2</a>, <a href="#rfc.xref.header.te.2">5.2.1</a>, <a href="#rfc.xref.header.te.3">5.4</a>, <a href="#rfc.xref.header.te.4">8</a>, <a href="#rfc.iref.t.5"><b>8.5</b></a>, <a href="#rfc.xref.header.te.5">9.1</a></li>
     3980                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.1.1</a>, <a href="#Tou1998"><b>12.2</b></a></li>
     3981                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">5.2.1</a>, <a href="#rfc.xref.header.trailer.2">8</a>, <a href="#rfc.iref.t.6"><b>8.6</b></a>, <a href="#rfc.xref.header.trailer.3">9.1</a></li>
     3982                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">5.2</a>, <a href="#rfc.xref.header.transfer-encoding.3">8</a>, <a href="#rfc.iref.t.7"><b>8.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">9.1</a></li>
    40183983                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.4</b></a></li>
    40193984                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.4</b></a></li>
    … …  
    40223987            </li>
    40233988            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    4024                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">9</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
     3989                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">8</a>, <a href="#rfc.iref.u.5"><b>8.8</b></a>, <a href="#rfc.xref.header.upgrade.2">9.1</a>, <a href="#rfc.xref.header.upgrade.3">A.2</a></li>
    40253990                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li>
    40263991                  <li>URI scheme&nbsp;&nbsp;
    … …  
    40303995                     </ul>
    40313996                  </li>
    4032                   <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.1</a>, <a href="#USASCII"><b>13.1</b></a></li>
     3997                  <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.1</a>, <a href="#USASCII"><b>12.1</b></a></li>
    40333998                  <li>user agent&nbsp;&nbsp;<a href="#rfc.iref.u.1"><b>2.1</b></a></li>
    40343999               </ul>
    40354000            </li>
    40364001            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    4037                   <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">9</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>
     4002                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">8</a>, <a href="#rfc.iref.v.1"><b>8.9</b></a>, <a href="#rfc.xref.header.via.3">9.1</a></li>
    40384003               </ul>
    40394004            </li>

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

    r1432 r1435  
    492492<t>
    493493   HTTP is a stateless request/response protocol that operates by exchanging
    494    messages across a reliable transport or session-layer
     494   <x:dfn>messages</x:dfn> (<xref target="http.message"/>) across a reliable
     495   transport or session-layer
    495496   "<x:dfn>connection</x:dfn>". An HTTP "<x:dfn>client</x:dfn>" is a
    496497   program that establishes a connection to a server for the purpose of
    … …  
    533534<t>
    534535   A client sends an HTTP request to the server in the form of a <x:dfn>request</x:dfn>
    535    <x:dfn>message</x:dfn> (<xref target="request"/>), beginning with a method, URI, and
    536    protocol version, followed by MIME-like header fields containing
    537    request modifiers, client information, and payload metadata, an empty
    538    line to indicate the end of the header section, and finally the payload
    539    body (if any).
     536   message, beginning with a request-line that includes a method, URI, and
     537   protocol version (<xref target="request.line"/>),
     538   followed by MIME-like header fields containing
     539   request modifiers, client information, and payload metadata
     540   (<xref target="header.fields"/>),
     541   an empty line to indicate the end of the header section, and finally
     542   a message body containing the payload body (if any,
     543   <xref target="message.body"/>).
    540544</t>
    541545<t>
    542546   A server responds to the client's request by sending an HTTP <x:dfn>response</x:dfn>
    543    <x:dfn>message</x:dfn> (<xref target="response"/>), beginning with a status line that
     547   message, beginning with a status line that
    544548   includes the protocol version, a success or error code, and textual
    545    reason phrase, followed by MIME-like header fields containing server
    546    information, resource metadata, and payload metadata, an empty line to
    547    indicate the end of the header section, and finally the payload body (if any).
     549   reason phrase (<xref target="status.line"/>),
     550   followed by MIME-like header fields containing server
     551   information, resource metadata, and payload metadata
     552   (<xref target="header.fields"/>),
     553   an empty line to indicate the end of the header section, and finally
     554   a message body containing the payload body (if any,
     555   <xref target="message.body"/>).
    548556</t>
    549557<t>
    … …  
    10111019   indicated resource, a client &MAY; attempt access by resolving
    10121020   the host to an IP address, establishing a TCP connection to that address
    1013    on the indicated port, and sending an HTTP request message to the server
    1014    containing the URI's identifying data as described in <xref target="request"/>.
     1021   on the indicated port, and sending an HTTP request message
     1022   (<xref target="http.message"/>) containing the URI's identifying data
     1023   (<xref target="message.routing"/>) to the server.
    10151024   If the server responds to that request with a non-interim HTTP response
    1016    message, as described in <xref target="response"/>, then that response
     1025   message, as described in &status-code-reasonphr;, then that response
    10171026   is considered an authoritative answer to the client's request.
    10181027</t>
    … …  
    11621171</t>
    11631172
    1164 <section anchor="start.line" title="Start Line">
     1173<section title="Start Line" anchor="start.line">
     1174  <x:anchor-alias value="Start-Line"/>
    11651175<t>
    11661176   An HTTP message can either be a request from client to server or a
    … …  
    11911201</t>
    11921202
    1193 <section title="Request-Line" anchor="request-line">
     1203<section title="Request-Line" anchor="request.line">
     1204  <x:anchor-alias value="Request"/>
    11941205  <x:anchor-alias value="Request-Line"/>
    11951206<t>
    … …  
    12521263</section>
    12531264
    1254 <section title="Status-Line" anchor="status-line">
     1265<section title="Response Status-Line" anchor="status.line">
     1266  <x:anchor-alias value="Response"/>
    12551267  <x:anchor-alias value="Status-Line"/>
    12561268<t>
    … …  
    12751287  <x:ref>Status-Code</x:ref>    = 3<x:ref>DIGIT</x:ref>
    12761288</artwork></figure>
    1277 <t>
    1278    The first digit of the Status-Code defines the class of response. The
    1279    last two digits do not have any categorization role. There are 5
    1280    values for the first digit:
    1281   <list style="symbols">
    1282     <t>
    1283       1xx: Informational - Request received, continuing process
    1284     </t>
    1285     <t>
    1286       2xx: Success - The action was successfully received,
    1287         understood, and accepted
    1288     </t>
    1289     <t>
    1290       3xx: Redirection - Further action must be taken in order to
    1291         complete the request
    1292     </t>
    1293     <t>
    1294       4xx: Client Error - The request contains bad syntax or cannot
    1295         be fulfilled
    1296     </t>
    1297     <t>
    1298       5xx: Server Error - The server failed to fulfill an apparently
    1299         valid request
    1300     </t>
    1301   </list>
    1302 </t>
    13031289</section>
    13041290
    … …  
    17831769</section>
    17841770
    1785 <section title="Request" anchor="request">
    1786   <x:anchor-alias value="Request"/>
    1787 <t>
    1788    A request message from a client to a server begins with a
    1789    Request-Line, followed by zero or more header fields, an empty
    1790    line signifying the end of the header block, and an optional
    1791    message body.
    1792 </t>
    1793 <!--                 Host                      ; should be moved here eventually -->
    1794 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/>
    1795   <x:ref>Request</x:ref>       = <x:ref>Request-Line</x:ref>              ; <xref target="request-line"/>
    1796                   *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
    1797                   <x:ref>CRLF</x:ref>
    1798                   [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
    1799 </artwork></figure>
    1800 
    1801 <section title="Types of Request Target" anchor="request-target-types">
     1771<section title="Message Routing" anchor="message.routing">
    18021772<t>
    18031773   In most cases, the user agent is provided a URI reference
    … …  
    18061776   of that URI is used to construct the HTTP request-target.
    18071777</t>
     1778
     1779<section title="Types of Request Target" anchor="request-target-types">
    18081780<t>
    18091781   The four options for request-target are dependent on the nature of the
    … …  
    20312003</t> 
    20322004</section>
    2033 
    2034 </section>
    2035 
    2036 
    2037 <section title="Response" anchor="response">
    2038   <x:anchor-alias value="Response"/>
    2039 <t>
    2040    After receiving and interpreting a request message, a server responds
    2041    with an HTTP response message.
    2042 </t>
    2043 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/>
    2044   <x:ref>Response</x:ref>      = <x:ref>Status-Line</x:ref>               ; <xref target="status-line"/>
    2045                   *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
    2046                   <x:ref>CRLF</x:ref>
    2047                   [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
    2048 </artwork></figure>
    2049 
    20502005</section>
    20512006
    … …  
    53235278<x:ref>RWS</x:ref> = 1*( SP / HTAB / obs-fold )
    53245279<x:ref>Reason-Phrase</x:ref> = *( HTAB / SP / VCHAR / obs-text )
    5325 <x:ref>Request</x:ref> = Request-Line *( header-field CRLF ) CRLF [ message-body ]
    53265280<x:ref>Request-Line</x:ref> = Method SP request-target SP HTTP-Version CRLF
    5327 <x:ref>Response</x:ref> = Status-Line *( header-field CRLF ) CRLF [ message-body ]
    53285281
    53295282<x:ref>Status-Code</x:ref> = 3DIGIT
    … …  
    54745427; HTTP-message defined but not used
    54755428; Host defined but not used
    5476 ; Request defined but not used
    5477 ; Response defined but not used
    54785429; TE defined but not used
    54795430; Trailer defined but not used

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

    r1434 r1435  
    751751      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    752752  <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    753   <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
     753  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 5.1</a>&gt;
    754754  <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    755   <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a>&gt;
     755  <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.3</a>&gt;
    756756  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    757757</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    … …  
    872872            to a particular request method.
    873873         </li>
    874          <li>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 9.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     874         <li>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    875875         </li>
    876876         <li>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</li>
    877877         <li>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    878878         </li>
    879          <li>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     879         <li>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    880880         </li>
    881881         <li>Whether the header field should be preserved across redirects.</li>
    … …  
    925925               <tr>
    926926                  <td class="left">Host</td>
    927                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     927                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    928928               </tr>
    929929               <tr>
    … …  
    965965               <tr>
    966966                  <td class="left">TE</td>
    967                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 9.5</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     967                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.5</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    968968               </tr>
    969969               <tr>
    … …  
    15231523      </p>
    15241524      <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1525          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     1525         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    15261526         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    15271527         infinite loop.
    15281528      </p>
    1529       <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1529      <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    15301530      </p>
    15311531      <div id="rfc.iref.c.1"></div>
    … …  
    15711571      </p>
    15721572      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="status.codes" href="#status.codes">Status Code Definitions</a></h1>
    1573       <p id="rfc.section.7.p.1">Each Status-Code is described below, including any metadata required in the response.</p>
     1573      <p id="rfc.section.7.p.1">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
     1574         There are 5 values for the first digit:
     1575      </p>
     1576      <ul>
     1577         <li>1xx: Informational - Request received, continuing process</li>
     1578         <li>2xx: Success - The action was successfully received, understood, and accepted</li>
     1579         <li>3xx: Redirection - Further action must be taken in order to complete the request</li>
     1580         <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li>
     1581         <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
     1582      </ul>
     1583      <p id="rfc.section.7.p.2">Each Status-Code is described below, including any metadata required in the response.</p>
    15741584      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>
    15751585      <p id="rfc.section.7.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional header fields,
    … …  
    15891599      <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    15901600         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    1591          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     1601         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    15921602      </p>
    15931603      <div id="rfc.iref.23"></div>
    15941604      <div id="rfc.iref.s.3"></div>
    15951605      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    1596       <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     1606      <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    15971607         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    15981608      </p>
    … …  
    19771987      <div id="rfc.iref.s.37"></div>
    19781988      <h3 id="rfc.section.7.4.19"><a href="#rfc.section.7.4.19">7.4.19</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    1979       <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
     1989      <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
    19801990      </p>
    19811991      <div id="rfc.figure.u.8"></div>
    … …  
    20772087      </p>
    20782088      <p id="rfc.section.8.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    2079       <p id="rfc.section.8.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
     2089      <p id="rfc.section.8.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
    20802090      </p>
    20812091      <div id="rfc.iref.f.1"></div>
    … …  
    21812191      <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    21822192      <p id="rfc.section.8.8.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    2183       <p id="rfc.section.8.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     2193      <p id="rfc.section.8.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    21842194         identifying the application.
    21852195      </p>
    … …  
    21872197</pre><p id="rfc.section.8.8.p.4">Example:</p>
    21882198      <div id="rfc.figure.u.24"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2189 </pre><p id="rfc.section.8.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     2199</pre><p id="rfc.section.8.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    21902200      </p>
    21912201      <div class="note" id="rfc.section.8.8.p.7">
    … …  
    22032213         user agent limitations.
    22042214      </p>
    2205       <p id="rfc.section.8.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     2215      <p id="rfc.section.8.9.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    22062216         for identifying the application.
    22072217      </p>
    … …  
    26682678      </p>
    26692679      <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2670       <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     2680      <p id="rfc.section.11.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    26712681      </p>
    26722682      <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References
    … …  
    28232833      </p>
    28242834      <p id="rfc.section.A.p.14">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    2825          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.8</a>)
     2835         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.8</a>)
    28262836      </p>
    28272837      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    28322842<a href="#header.from" class="smpl">From</a> = mailbox
    28332843
    2834 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part1], Section 6.1&gt;
     2844<a href="#abnf.dependencies" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part1], Section 5.1&gt;
    28352845
    28362846<a href="#header.location" class="smpl">Location</a> = URI-reference
    … …  
    28682878
    28692879<a href="#abnf.dependencies" class="smpl">partial-URI</a> = &lt;partial-URI, defined in [Part1], Section 2.7&gt;
    2870 <a href="#abnf.dependencies" class="smpl">product</a> = &lt;product, defined in [Part1], Section 6.3&gt;
     2880<a href="#abnf.dependencies" class="smpl">product</a> = &lt;product, defined in [Part1], Section 5.3&gt;
    28712881
    28722882<a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in [Part1], Section 3.2.3&gt;
    … …  
    33303340                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li>
    33313341                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>
    3332                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a></li>
    3333                         <li><em>Section 6.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
    3334                         <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.38">8.8</a>, <a href="#rfc.xref.Part1.41">8.9</a></li>
    3335                         <li><em>Section 7.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">8.2</a></li>
    3336                         <li><em>Section 9.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
    3337                         <li><em>Section 9.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
    3338                         <li><em>Section 9.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
    3339                         <li><em>Section 9.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li>
    3340                         <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.40">8.8</a>, <a href="#rfc.xref.Part1.44">A</a></li>
    3341                         <li><em>Section 10.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a></li>
    3342                         <li><em>Section 12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">11</a></li>
     3342                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a></li>
     3343                        <li><em>Section 5.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
     3344                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.38">8.8</a>, <a href="#rfc.xref.Part1.41">8.9</a></li>
     3345                        <li><em>Section 6.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">8.2</a></li>
     3346                        <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
     3347                        <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
     3348                        <li><em>Section 8.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
     3349                        <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li>
     3350                        <li><em>Section 8.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.40">8.8</a>, <a href="#rfc.xref.Part1.44">A</a></li>
     3351                        <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a></li>
     3352                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">11</a></li>
    33433353                     </ul>
    33443354                  </li>

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

    r1430 r1435  
    13291329<section title="Status Code Definitions" anchor="status.codes">
    13301330<t>
     1331   The first digit of the Status-Code defines the class of response. The
     1332   last two digits do not have any categorization role. There are 5
     1333   values for the first digit:
     1334  <list style="symbols">
     1335    <t>
     1336      1xx: Informational - Request received, continuing process
     1337    </t>
     1338    <t>
     1339      2xx: Success - The action was successfully received,
     1340        understood, and accepted
     1341    </t>
     1342    <t>
     1343      3xx: Redirection - Further action must be taken in order to
     1344        complete the request
     1345    </t>
     1346    <t>
     1347      4xx: Client Error - The request contains bad syntax or cannot
     1348        be fulfilled
     1349    </t>
     1350    <t>
     1351      5xx: Server Error - The server failed to fulfill an apparently
     1352        valid request
     1353    </t>
     1354  </list>
     1355</t>
     1356<t>
    13311357   Each Status-Code is described below, including any metadata required
    13321358   in the response.
    … …  
    37323758<x:ref>From</x:ref> = mailbox
    37333759
    3734 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part1], Section 6.1&gt;
     3760<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part1], Section 5.1&gt;
    37353761
    37363762<x:ref>Location</x:ref> = URI-reference
    … …  
    37683794
    37693795<x:ref>partial-URI</x:ref> = &lt;partial-URI, defined in [Part1], Section 2.7&gt;
    3770 <x:ref>product</x:ref> = &lt;product, defined in [Part1], Section 6.3&gt;
     3796<x:ref>product</x:ref> = &lt;product, defined in [Part1], Section 5.3&gt;
    37713797
    37723798<x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in [Part1], Section 3.2.3&gt;
Note: See TracChangeset for help on using the changeset viewer.