Changeset 2734 for draft-ietf-httpbis


Ignore:
Timestamp:
17/12/14 14:46:09 (7 years ago)
Author:
julian.reschke@…
Message:

update XSLTs, switch to Saxon 9.6 HE in Makefile, regen specs

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/Makefile

    r2588 r2734  
    11xml2rfc = "../../xml2rfc/xml2rfc.tcl"
    2 saxpath = "$(HOME)/java/saxon-8-9-j/saxon8.jar"
    3 saxon = java -classpath $(saxpath) net.sf.saxon.Transform -novw -l
     2saxpath = "$(HOME)/java/saxon-9-6-j/saxon9he.jar"
     3saxon = java -classpath $(saxpath) net.sf.saxon.Transform -l -versionmsg:off
    44
    55stylesheet = ../myxml2rfc.xslt
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2726 r2734  
    1313  fb.appendChild(document.createTextNode("feedback"));
    1414
    15   var bodyl = document.getElementsByTagName("body");
    16   bodyl.item(0).appendChild(fb);
     15  document.body.appendChild(fb);
    1716}
    1817
     
    106105body {
    107106  color: black;
    108   font-family: cambria, helvetica, arial, sans-serif;
    109   font-size: 11pt;
    110   margin-right: 2em;
     107  font-family: cambria, georgia, serif;
     108  font-size: 12pt;
     109  margin: 2em auto;
     110  max-width: 1000px;
     111}
     112samp, tt, code, pre {
     113  font-family: consolas, monaco, monospace;
    111114}
    112115cite {
     
    119122  margin-left: 2em;
    120123}
     124dl > dt {
     125  float: left;
     126  margin-right: 1em;
     127}
     128dl.nohang > dt {
     129  float: none;
     130}
     131dl > dd {
     132  margin-bottom: .5em;
     133}
     134dl.compact > dd {
     135  margin-bottom: .0em;
     136}
     137dl > dd > dl {
     138  margin-top: 0.5em;
     139}
    121140ul.empty {
    122141  list-style-type: none;
     
    127146dl p {
    128147  margin-left: 0em;
    129 }
    130 dt {
    131   margin-top: .5em;
    132148}
    133149h1 {
     
    176192}
    177193pre {
     194  font-size: 11pt;
    178195  margin-left: 3em;
    179196  background-color: lightyellow;
     
    185202  border-width: 1px;
    186203  background-color: #f0f0f0;
    187   width: 69em;
    188204}
    189205pre.inline {
    190206  background-color: white;
    191207  padding: 0em;
     208  page-break-inside: auto;
    192209}
    193210pre.text {
     
    195212  border-width: 1px;
    196213  background-color: #f8f8f8;
    197   width: 69em;
    198214}
    199215pre.drawing {
     
    308324  line-height: normal;
    309325  font-weight: normal;
    310   font-size: 10pt;
     326  font-size: 11pt;
    311327  margin-left: 0em;
    312328}
     
    318334}
    319335.title, .filename, h1, h2, h3, h4 {
    320   font-family: candara, helvetica, arial, sans-serif;
    321 }
    322 samp, tt, code, pre {
    323   font: consolas, monospace;
     336  font-family: candara, calibri, segoe, optima, arial, sans-serif;
    324337}
    325338ul.ind, ul.ind ul {
     
    339352  margin-left: 0em;
    340353}
    341 .avoidbreak {
     354.avoidbreakinside {
    342355  page-break-inside: avoid;
     356}
     357.avoidbreakafter {
     358  page-break-after: avoid;
    343359}
    344360.bcp14 {
     
    390406  font-size: 130%;
    391407  background-color: yellow;
    392 }
    393 .feedback {
     408}.feedback {
    394409  position: fixed;
    395410  bottom: 1%;
     
    398413  color: white;
    399414  border-radius: 5px;
    400   background: #a00000;
     415  background: #006400;
    401416  border: 1px solid silver;
     417  -webkit-user-select: none;
     418  -moz-user-select: none;
     419  -ms-user-select: none;
    402420}
    403421.fbbutton {
     
    412430}
    413431
     432@media screen {
     433  pre.text, pre.text2 {
     434    width: 69em;
     435  }
     436}
     437
    414438@media print {
    415439  .noprint {
     
    434458  }
    435459
    436   ul.toc a:nth-child(2)::after {
     460  ul.toc a:last-child::after {
    437461    content: leader('.') target-counter(attr(href), page);
    438462  }
     
    440464  ul.ind li li a {
    441465    content: target-counter(attr(href), page);
     466  }
     467
     468  pre {
     469    font-size: 10pt;
    442470  }
    443471
     
    463491  }
    464492  @bottom-center {
    465        content: "Expires December 16, 2014";
     493       content: "Expires December 2014";
    466494  }
    467495  @bottom-right {
     
    500528      <link rel="Alternate" title="RFC7230" href="http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html">
    501529      <link href="p2-semantics.html" rel="next">
    502       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     530      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.710, 2014/12/09 13:12:18, XSLT vendor: Saxonica http://www.saxonica.com/">
    503531      <meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP message format">
    504532      <link rel="schema.dct" href="http://purl.org/dc/terms/">
     
    506534      <meta name="dct.creator" content="Reschke, J. F.">
    507535      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    508       <meta name="dct.issued" scheme="ISO8601" content="2014-06-14">
     536      <meta name="dct.issued" scheme="ISO8601" content="2014-06">
    509537      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    510538      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    513541   </head>
    514542   <body onload="initFeedback();">
    515       <table class="header">
     543      <table class="header" id="rfc.headerblock">
    516544         <tbody>
    517545            <tr>
     
    535563            <tr>
    536564               <td class="left">Intended status: Standards Track</td>
    537                <td class="right">June 14, 2014</td>
     565               <td class="right">June 2014</td>
    538566            </tr>
    539567            <tr>
    540                <td class="left">Expires: December 16, 2014</td>
     568               <td class="left">Expires: December 2014</td>
    541569               <td class="right"></td>
    542570            </tr>
    543571         </tbody>
    544572      </table>
    545       <p class="title">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing<br><span class="filename">draft-ietf-httpbis-p1-messaging-latest</span></p>
     573      <p class="title" id="rfc.title">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing<br><span class="filename">draft-ietf-httpbis-p1-messaging-latest</span></p>
    546574      <p style="color: green; text-align: center; font-size: 14pt; background-color: yellow;"><b>Note:</b> a later version of this document has been published as <a href="http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html">RFC7230</a>.
    547575         
    548576      </p>
    549577      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    550       <p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext
    551          information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http"
    552          and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes
    553          related security concerns for implementations.
     578      <p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for
     579         distributed, collaborative, hypertext information systems. This document provides
     580         an overview of HTTP architecture and its associated terminology, defines the "http"
     581         and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message
     582         syntax and parsing requirements, and describes related security concerns for implementations.
    554583      </p>
    555584      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
    556       <p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.
     585      <p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org),
     586         which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.
    557587      </p>
    558588      <p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.
    559589      </p>
    560       <p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em>
     590      <p><em>This is a temporary document for the purpose of tracking the editorial changes made
     591            during the AUTH48 (RFC publication) phase.</em>
    561592      </p>
    562593      <div id="rfc.status">
    563594         <h1><a href="#rfc.status">Status of This Memo</a></h1>
    564          <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
    565          <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
    566             working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
     595         <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78
     596            and BCP 79.
    567597         </p>
    568          <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    569             documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    570             in progress”.
     598         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).
     599            Note that other groups may also distribute working documents as Internet-Drafts. The
     600            list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
    571601         </p>
    572          <p>This Internet-Draft will expire on December 16, 2014.</p>
     602         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated,
     603            replaced, or obsoleted by other documents at any time. It is inappropriate to use
     604            Internet-Drafts as reference material or to cite them other than as “work in progress”.
     605         </p>
     606         <p>This Internet-Draft will expire in December 2014.</p>
    573607      </div>
    574608      <div id="rfc.copyrightnotice">
    575609         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    576          <p>Copyright © 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    577          <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
    578             and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
    579             text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
    580             BSD License.
     610         <p>Copyright © 2014 IETF Trust and the persons identified as the document authors. All
     611            rights reserved.
    581612         </p>
    582          <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
    583             10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
    584             allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
    585             controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
    586             works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
    587             it into languages other than English.
     613         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating
     614            to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents
     615            carefully, as they describe your rights and restrictions with respect to this document.
     616            Code Components extracted from this document must include Simplified BSD License text
     617            as described in Section 4.e of the Trust Legal Provisions and are provided without
     618            warranty as described in the Simplified BSD License.
     619         </p>
     620         <p>This document may contain material from IETF Documents or IETF Contributions published
     621            or made publicly available before November 10, 2008. The person(s) controlling the
     622            copyright in some of this material may not have granted the IETF Trust the right to
     623            allow modifications of such material outside the IETF Standards Process. Without obtaining
     624            an adequate license from the person(s) controlling the copyright in such materials,
     625            this document may not be modified outside the IETF Standards Process, and derivative
     626            works of it may not be created outside the IETF Standards Process, except to format
     627            it for publication as an RFC or to translate it into languages other than English.
    588628         </p>
    589629      </div>
    590630      <hr class="noprint">
    591       <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
    592       <ul class="toc">
    593          <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    594                <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements Notation</a></li>
    595                <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
    596             </ul>
    597          </li>
    598          <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#architecture">Architecture</a><ul>
    599                <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
    600                <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#implementation-diversity">Implementation Diversity</a></li>
    601                <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
    602                <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
    603                <li><a href="#rfc.section.2.5">2.5</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
    604                <li><a href="#rfc.section.2.6">2.6</a>&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
    605                <li><a href="#rfc.section.2.7">2.7</a>&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
    606                      <li><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI Scheme</a></li>
    607                      <li><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI Scheme</a></li>
    608                      <li><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li>
    609                   </ul>
    610                </li>
    611             </ul>
    612          </li>
    613          <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#http.message">Message Format</a><ul>
    614                <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#start.line">Start Line</a><ul>
    615                      <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.line">Request Line</a></li>
    616                      <li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.line">Status Line</a></li>
    617                   </ul>
    618                </li>
    619                <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a><ul>
    620                      <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#field.extensibility">Field Extensibility</a></li>
    621                      <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#field.order">Field Order</a></li>
    622                      <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#whitespace">Whitespace</a></li>
    623                      <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li>
    624                      <li><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#field.limits">Field Limits</a></li>
    625                      <li><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#field.components">Field Value Components</a></li>
    626                   </ul>
    627                </li>
    628                <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a><ul>
    629                      <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
    630                      <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
    631                      <li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body.length">Message Body Length</a></li>
    632                   </ul>
    633                </li>
    634                <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.messages">Handling Incomplete Messages</a></li>
    635                <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#message.robustness">Message Parsing Robustness</a></li>
    636             </ul>
    637          </li>
    638          <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
    639                <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a><ul>
    640                      <li><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.extension">Chunk Extensions</a></li>
    641                      <li><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.trailer.part">Chunked Trailer Part</a></li>
    642                      <li><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#decoding.chunked">Decoding Chunked</a></li>
    643                   </ul>
    644                </li>
    645                <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
    646                      <li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
    647                      <li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
    648                      <li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
    649                   </ul>
    650                </li>
    651                <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
    652                <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
    653             </ul>
    654          </li>
    655          <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul>
    656                <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#target-resource">Identifying a Target Resource</a></li>
    657                <li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#connecting.inbound">Connecting Inbound</a></li>
    658                <li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request-target">Request Target</a><ul>
    659                      <li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#origin-form">origin-form</a></li>
    660                      <li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#absolute-form">absolute-form</a></li>
    661                      <li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#authority-form">authority-form</a></li>
    662                      <li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#asterisk-form">asterisk-form</a></li>
    663                   </ul>
    664                </li>
    665                <li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
    666                <li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    667                <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    668                <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a><ul>
    669                      <li><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
    670                      <li><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#message.transformations">Transformations</a></li>
    671                   </ul>
    672                </li>
    673             </ul>
    674          </li>
    675          <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#connection.management">Connection Management</a><ul>
    676                <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
    677                <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li>
    678                <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a><ul>
    679                      <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
    680                      <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    681                   </ul>
    682                </li>
    683                <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li>
    684                <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Timeouts</a></li>
    685                <li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li>
    686                <li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
    687             </ul>
    688          </li>
    689          <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#abnf.extension">ABNF List Extension: #rule</a></li>
    690          <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    691                <li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    692                <li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li>
    693                <li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul>
    694                      <li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>
    695                      <li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>
    696                   </ul>
    697                </li>
    698                <li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a><ul>
    699                      <li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry.procedure">Procedure</a></li>
    700                      <li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Registration</a></li>
    701                   </ul>
    702                </li>
    703                <li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registration</a></li>
    704                <li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a><ul>
    705                      <li><a href="#rfc.section.8.6.1">8.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry.procedure">Procedure</a></li>
    706                      <li><a href="#rfc.section.8.6.2">8.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
    707                   </ul>
    708                </li>
    709             </ul>
    710          </li>
    711          <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    712                <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#establishing.authority">Establishing Authority</a></li>
    713                <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#risks.intermediaries">Risks of Intermediaries</a></li>
    714                <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.length">Attacks via Protocol Element Length</a></li>
    715                <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.splitting">Response Splitting</a></li>
    716                <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.smuggling">Request Smuggling</a></li>
    717                <li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li>
    718                <li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.confidentiality">Message Confidentiality</a></li>
    719                <li><a href="#rfc.section.9.8">9.8</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.of.server.log.information">Privacy of Server Log Information</a></li>
    720             </ul>
    721          </li>
    722          <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    723          <li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    724                <li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    725                <li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    726             </ul>
    727          </li>
    728          <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility">HTTP Version History</a><ul>
    729                <li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul>
    730                      <li><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.to.simplify.multihomed.web.servers.and.conserve.ip.addresses">Multihomed Web Servers</a></li>
    731                      <li><a href="#rfc.section.A.1.2">A.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li>
    732                      <li><a href="#rfc.section.A.1.3">A.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li>
    733                   </ul>
    734                </li>
    735                <li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    736             </ul>
    737          </li>
    738          <li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
    739          <li><a href="#rfc.index">Index</a></li>
    740          <li><a href="#rfc.authors">Authors' Addresses</a></li>
    741       </ul>
     631      <div id="rfc.toc">
     632         <h1 class="np"><a href="#rfc.toc">Table of Contents</a></h1>
     633         <ul class="toc">
     634            <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
     635                  <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements Notation</a></li>
     636                  <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
     637               </ul>
     638            </li>
     639            <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#architecture">Architecture</a><ul>
     640                  <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
     641                  <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#implementation-diversity">Implementation Diversity</a></li>
     642                  <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
     643                  <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
     644                  <li><a href="#rfc.section.2.5">2.5</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
     645                  <li><a href="#rfc.section.2.6">2.6</a>&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li>
     646                  <li><a href="#rfc.section.2.7">2.7</a>&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul>
     647                        <li><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI Scheme</a></li>
     648                        <li><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI Scheme</a></li>
     649                        <li><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li>
     650                     </ul>
     651                  </li>
     652               </ul>
     653            </li>
     654            <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#http.message">Message Format</a><ul>
     655                  <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#start.line">Start Line</a><ul>
     656                        <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.line">Request Line</a></li>
     657                        <li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.line">Status Line</a></li>
     658                     </ul>
     659                  </li>
     660                  <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a><ul>
     661                        <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#field.extensibility">Field Extensibility</a></li>
     662                        <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#field.order">Field Order</a></li>
     663                        <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#whitespace">Whitespace</a></li>
     664                        <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li>
     665                        <li><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#field.limits">Field Limits</a></li>
     666                        <li><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#field.components">Field Value Components</a></li>
     667                     </ul>
     668                  </li>
     669                  <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a><ul>
     670                        <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
     671                        <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
     672                        <li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body.length">Message Body Length</a></li>
     673                     </ul>
     674                  </li>
     675                  <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.messages">Handling Incomplete Messages</a></li>
     676                  <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#message.robustness">Message Parsing Robustness</a></li>
     677               </ul>
     678            </li>
     679            <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul>
     680                  <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a><ul>
     681                        <li><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.extension">Chunk Extensions</a></li>
     682                        <li><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.trailer.part">Chunked Trailer Part</a></li>
     683                        <li><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#decoding.chunked">Decoding Chunked</a></li>
     684                     </ul>
     685                  </li>
     686                  <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul>
     687                        <li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li>
     688                        <li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li>
     689                        <li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li>
     690                     </ul>
     691                  </li>
     692                  <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
     693                  <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
     694               </ul>
     695            </li>
     696            <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul>
     697                  <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#target-resource">Identifying a Target Resource</a></li>
     698                  <li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#connecting.inbound">Connecting Inbound</a></li>
     699                  <li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request-target">Request Target</a><ul>
     700                        <li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#origin-form">origin-form</a></li>
     701                        <li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#absolute-form">absolute-form</a></li>
     702                        <li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#authority-form">authority-form</a></li>
     703                        <li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#asterisk-form">asterisk-form</a></li>
     704                     </ul>
     705                  </li>
     706                  <li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
     707                  <li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
     708                  <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
     709                  <li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a><ul>
     710                        <li><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
     711                        <li><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#message.transformations">Transformations</a></li>
     712                     </ul>
     713                  </li>
     714               </ul>
     715            </li>
     716            <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#connection.management">Connection Management</a><ul>
     717                  <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
     718                  <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li>
     719                  <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a><ul>
     720                        <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
     721                        <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
     722                     </ul>
     723                  </li>
     724                  <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li>
     725                  <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Timeouts</a></li>
     726                  <li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li>
     727                  <li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
     728               </ul>
     729            </li>
     730            <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#abnf.extension">ABNF List Extension: #rule</a></li>
     731            <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     732                  <li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     733                  <li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li>
     734                  <li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul>
     735                        <li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>
     736                        <li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>
     737                     </ul>
     738                  </li>
     739                  <li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a><ul>
     740                        <li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry.procedure">Procedure</a></li>
     741                        <li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Registration</a></li>
     742                     </ul>
     743                  </li>
     744                  <li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registration</a></li>
     745                  <li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a><ul>
     746                        <li><a href="#rfc.section.8.6.1">8.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry.procedure">Procedure</a></li>
     747                        <li><a href="#rfc.section.8.6.2">8.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
     748                     </ul>
     749                  </li>
     750               </ul>
     751            </li>
     752            <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
     753                  <li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#establishing.authority">Establishing Authority</a></li>
     754                  <li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#risks.intermediaries">Risks of Intermediaries</a></li>
     755                  <li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.length">Attacks via Protocol Element Length</a></li>
     756                  <li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.splitting">Response Splitting</a></li>
     757                  <li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.smuggling">Request Smuggling</a></li>
     758                  <li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li>
     759                  <li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.confidentiality">Message Confidentiality</a></li>
     760                  <li><a href="#rfc.section.9.8">9.8</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.of.server.log.information">Privacy of Server Log Information</a></li>
     761               </ul>
     762            </li>
     763            <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     764            <li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     765                  <li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     766                  <li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     767               </ul>
     768            </li>
     769            <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility">HTTP Version History</a><ul>
     770                  <li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul>
     771                        <li><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.to.simplify.multihomed.web.servers.and.conserve.ip.addresses">Multihomed Web Servers</a></li>
     772                        <li><a href="#rfc.section.A.1.2">A.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li>
     773                        <li><a href="#rfc.section.A.1.3">A.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li>
     774                     </ul>
     775                  </li>
     776                  <li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
     777               </ul>
     778            </li>
     779            <li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
     780            <li><a href="#rfc.index">Index</a></li>
     781            <li><a href="#rfc.authors">Authors' Addresses</a></li>
     782         </ul>
     783      </div>
    742784      <div id="introduction">
    743785         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1>
    744          <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics
    745             and self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document
    746             is the first in a series of documents that collectively form the HTTP/1.1 specification:
    747          </p>
    748          <ol>
    749             <li>"Message Syntax and Routing" (this document)</li>
    750             <li>"Semantics and Content" <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a></li>
    751             <li>"Conditional Requests" <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></li>
    752             <li>"Range Requests" <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></li>
    753             <li>"Caching" <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></li>
    754             <li>"Authentication" <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></li>
    755          </ol>
    756          <p id="rfc.section.1.p.2">This HTTP/1.1 specification obsoletes <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> and <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning). This specification also updates the use of CONNECT to establish a tunnel, previously defined in <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">RFC 2817</cite>, and defines the "https" URI scheme that was described informally in <cite title="HTTP Over TLS" id="rfc.xref.RFC2818.1">RFC 2818</cite>.
    757          </p>
    758          <p id="rfc.section.1.p.3">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented
    759             by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do
    760             not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated
    761             with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used
    762             effectively in many different contexts and for which implementations can evolve independently over time.
    763          </p>
    764          <p id="rfc.section.1.p.4">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information
    765             systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols
    766             into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services.
    767          </p>
    768          <p id="rfc.section.1.p.5">One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead,
    769             we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of
    770             recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding
    771             changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps
    772             at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
    773          </p>
    774          <p id="rfc.section.1.p.6">This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI
    775             schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements.
    776             Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics,
    777             thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.
    778          </p>
     786         <div id="rfc.section.1.p.1">
     787            <p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response
     788               protocol that uses extensible semantics and self-descriptive message payloads for
     789               flexible interaction with network-based hypertext information systems. This document
     790               is the first in a series of documents that collectively form the HTTP/1.1 specification:
     791            </p>
     792            <ol>
     793               <li>"Message Syntax and Routing" (this document)</li>
     794               <li>"Semantics and Content" <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a></li>
     795               <li>"Conditional Requests" <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></li>
     796               <li>"Range Requests" <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></li>
     797               <li>"Caching" <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></li>
     798               <li>"Authentication" <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></li>
     799            </ol>
     800         </div>
     801         <div id="rfc.section.1.p.2">
     802            <p>This HTTP/1.1 specification obsoletes <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> and <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning). This specification also updates the use of CONNECT to establish
     803               a tunnel, previously defined in <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">RFC 2817</cite>, and defines the "https" URI scheme that was described informally in <cite title="HTTP Over TLS" id="rfc.xref.RFC2818.1">RFC 2818</cite>.
     804            </p>
     805         </div>
     806         <div id="rfc.section.1.p.3">
     807            <p>HTTP is a generic interface protocol for information systems. It is designed to hide
     808               the details of how a service is implemented by presenting a uniform interface to clients
     809               that is independent of the types of resources provided. Likewise, servers do not need
     810               to be aware of each client's purpose: an HTTP request can be considered in isolation
     811               rather than being associated with a specific type of client or a predetermined sequence
     812               of application steps. The result is a protocol that can be used effectively in many
     813               different contexts and for which implementations can evolve independently over time.
     814            </p>
     815         </div>
     816         <div id="rfc.section.1.p.4">
     817            <p>HTTP is also designed for use as an intermediation protocol for translating communication
     818               to and from non-HTTP information systems. HTTP proxies and gateways can provide access
     819               to alternative information services by translating their diverse protocols into a
     820               hypertext format that can be viewed and manipulated by clients in the same way as
     821               HTTP services.
     822            </p>
     823         </div>
     824         <div id="rfc.section.1.p.5">
     825            <p>One consequence of this flexibility is that the protocol cannot be defined in terms
     826               of what occurs behind the interface. Instead, we are limited to defining the syntax
     827               of communication, the intent of received communication, and the expected behavior
     828               of recipients. If the communication is considered in isolation, then successful actions
     829               ought to be reflected in corresponding changes to the observable interface provided
     830               by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes,
     831               we cannot require that such changes be observable beyond the scope of a single response.
     832            </p>
     833         </div>
     834         <div id="rfc.section.1.p.6">
     835            <p>This document describes the architectural elements that are used or referred to in
     836               HTTP, defines the "http" and "https" URI schemes, describes overall network operation
     837               and connection management, and defines HTTP message framing and forwarding requirements.
     838               Our goal is to define all of the mechanisms necessary for HTTP message handling that
     839               are independent of message semantics, thereby defining the complete set of requirements
     840               for message parsers and message-forwarding intermediaries.
     841            </p>
     842         </div>
    779843         <div id="intro.requirements">
    780844            <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#intro.requirements">Requirements Notation</a></h2>
    781             <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    782                in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    783             </p>
    784             <p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>.
    785             </p>
     845            <div id="rfc.section.1.1.p.1">
     846               <p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
     847                  NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted
     848                  as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
     849               </p>
     850            </div>
     851            <div id="rfc.section.1.1.p.2">
     852               <p>Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>.
     853               </p>
     854            </div>
    786855         </div>
    787856         <div id="notation">
    788             <div id="rfc.iref.g.1"></div>
    789             <div id="rfc.iref.g.2"></div>
    790             <div id="rfc.iref.g.3"></div>
    791             <div id="rfc.iref.g.4"></div>
    792             <div id="rfc.iref.g.5"></div>
    793             <div id="rfc.iref.g.6"></div>
    794             <div id="rfc.iref.g.7"></div>
    795             <div id="rfc.iref.g.8"></div>
    796             <div id="rfc.iref.g.9"></div>
    797             <div id="rfc.iref.g.10"></div>
    798             <div id="rfc.iref.g.11"></div>
    799             <div id="rfc.iref.g.12"></div>
    800857            <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2>
    801             <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="#abnf.extension" title="ABNF List Extension: #rule">Section&nbsp;7</a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates
    802                repetition). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected grammar with all list operators expanded to standard ABNF notation.
    803             </p>
     858            <div id="rfc.section.1.2.p.1">
     859               <p>This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="#abnf.extension" title="ABNF List Extension: #rule">Section&nbsp;7</a>, that allows for compact definition of comma-separated lists using a '#' operator
     860                  (similar to how the '*' operator indicates repetition). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected grammar with all list operators expanded to standard ABNF notation.
     861               </p>
     862            </div>
    804863            <div id="core.rules">
    805                <p id="rfc.section.1.2.p.2">            The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
    806                   (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR
    807                   (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character).
    808                </p>
    809             </div>
    810             <p id="rfc.section.1.2.p.3">As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.</p>
     864               <div id="rfc.section.1.2.p.2">
     865                  <p>            The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal
     866                     0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab),
     867                     LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character).
     868                  </p>
     869               </div>
     870            </div>
     871            <div id="rfc.section.1.2.p.3">
     872               <p>As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules
     873                  that appear for historical reasons.
     874               </p>
     875            </div>
    811876         </div>
    812877      </div>
    813878      <div id="architecture">
    814879         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#architecture">Architecture</a></h1>
    815          <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a
    816             worldwide hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define
    817             HTTP.
    818          </p>
     880         <div id="rfc.section.2.p.1">
     881            <p>HTTP was created for the World Wide Web (WWW) architecture and has evolved over time
     882               to support the scalability needs of a worldwide hypertext system. Much of that architecture
     883               is reflected in the terminology and syntax productions used to define HTTP.
     884            </p>
     885         </div>
    819886         <div id="operation">
    820             <div id="rfc.iref.c.1"></div>
    821             <div id="rfc.iref.s.1"></div>
    822             <div id="rfc.iref.c.2"></div>
    823887            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#operation">Client/Server Messaging</a></h2>
    824             <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>" (<a href="#connection.management" title="Connection Management">Section&nbsp;6</a>). 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.
    825             </p>
     888            <div id="rfc.section.2.1.p.1">
     889               <p>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>" (<a href="#connection.management" title="Connection Management">Section&nbsp;6</a>). An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending
     890                  one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending
     891                  HTTP responses.
     892               </p>
     893            </div>
    826894            <div id="rfc.iref.u.1"></div>
    827895            <div id="rfc.iref.o.1"></div>
    828896            <div id="rfc.iref.b.1"></div>
     897            <div id="rfc.iref.s.1"></div>
    829898            <div id="rfc.iref.s.2"></div>
    830             <div id="rfc.iref.s.3"></div>
    831899            <div id="rfc.iref.r.1"></div>
    832             <p id="rfc.section.2.1.p.2">The terms "client" and "server" refer only to the roles that these programs perform for a particular connection. The same
    833                program might act as a client on some connections and a server on others. The term "<dfn>user agent</dfn>" refers to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders (web-based
    834                robots), command-line tools, custom applications, and mobile apps. The term "<dfn>origin server</dfn>" refers to the program that can originate authoritative responses for a given target resource. The terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" refer to any implementation that sends or receives a given message, respectively.
    835             </p>
    836             <p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for the differences between HTTP and MIME messages).
    837             </p>
    838             <p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
    839                the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and
    840                the origin server (O).
    841             </p>
    842             <div id="rfc.figure.u.1"></div><pre class="drawing">         request   &gt;
     900            <div id="rfc.section.2.1.p.2">
     901               <p>The terms "client" and "server" refer only to the roles that these programs perform
     902                  for a particular connection. The same program might act as a client on some connections
     903                  and a server on others. The term "<dfn>user agent</dfn>" refers to any of the various client programs that initiate a request, including
     904                  (but not limited to) browsers, spiders (web-based robots), command-line tools, custom
     905                  applications, and mobile apps. The term "<dfn>origin server</dfn>" refers to the program that can originate authoritative responses for a given target
     906                  resource. The terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" refer to any implementation that sends or receives a given message, respectively.
     907               </p>
     908            </div>
     909            <div id="rfc.section.2.1.p.3">
     910               <p>HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to
     911                  that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for the differences between HTTP and MIME messages).
     912               </p>
     913            </div>
     914            <div id="rfc.section.2.1.p.4">
     915               <p>Most HTTP communication consists of a retrieval request (GET) for a representation
     916                  of some resource identified by a URI. In the simplest case, this might be accomplished
     917                  via a single bidirectional connection (===) between the user agent (UA) and the origin
     918                  server (O).
     919               </p>
     920            </div>
     921            <div id="rfc.figure.u.1"><pre class="drawing">         request   &gt;
    843922    <b>UA</b> ======================================= <b>O</b>
    844923                                &lt;   response
    845 </pre><div id="rfc.iref.m.1"></div>
     924</pre></div>
     925            <div id="rfc.iref.m.1"></div>
    846926            <div id="rfc.iref.r.2"></div>
    847927            <div id="rfc.iref.r.3"></div>
    848             <p id="rfc.section.2.1.p.6">A client sends an HTTP request to a 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 header fields containing request modifiers, client information, and representation 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>).
    849             </p>
    850             <p id="rfc.section.2.1.p.7">A server responds to a client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason
    851                phrase (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>), possibly followed by header fields containing server information, resource metadata, and representation 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>).
    852             </p>
    853             <p id="rfc.section.2.1.p.8">A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>.
    854             </p>
    855             <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) on the URI "http://www.example.com/hello.txt":
    856             </p>
    857             <div id="rfc.figure.u.2"></div>
    858             <p>Client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
     928            <div id="rfc.section.2.1.p.5">
     929               <p>A client sends an HTTP request to a server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version
     930                  (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>), followed by header fields containing request modifiers, client information, and
     931                  representation 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
     932                  body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
     933               </p>
     934            </div>
     935            <div id="rfc.section.2.1.p.6">
     936               <p>A server responds to a client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a
     937                  success or error code, and textual reason phrase (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>), possibly followed by header fields containing server information, resource metadata,
     938                  and representation 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
     939                  body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
     940               </p>
     941            </div>
     942            <div id="rfc.section.2.1.p.7">
     943               <p>A connection might be used for multiple request/response exchanges, as defined in <a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>.
     944               </p>
     945            </div>
     946            <div id="rfc.section.2.1.p.8">
     947               <p>The following example illustrates a typical message exchange for a GET request (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) on the URI "http://www.example.com/hello.txt":
     948               </p>
     949            </div>
     950            <div id="rfc.figure.u.2">
     951               <p>Client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
    859952User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
    860953Host: www.example.com
    861954Accept-Language: en, mi
    862955
    863 </pre><div id="rfc.figure.u.3"></div>
    864             <p>Server response:</p><pre class="text">HTTP/1.1 200 OK
     956</pre></div>
     957            <div id="rfc.figure.u.3">
     958               <p>Server response:</p><pre class="text">HTTP/1.1 200 OK
    865959Date: Mon, 27 Jul 2009 12:28:53 GMT
    866960Server: Apache
     
    874968<span id="exbody">Hello World! My payload includes a trailing CRLF.
    875969</span></pre></div>
     970         </div>
    876971         <div id="implementation-diversity">
    877972            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#implementation-diversity">Implementation Diversity</a></h2>
    878             <p id="rfc.section.2.2.p.1">When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers
    879                and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household
    880                appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude
    881                of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components,
    882                office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video-delivery platforms.
    883             </p>
    884             <p id="rfc.section.2.2.p.2">The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of
    885                a request. In many cases, a user agent is installed or configured to run in the background and save its results for later
    886                inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically
    887                given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph.
    888             </p>
    889             <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that not all user agents can make interactive suggestions to their user or provide
    890                adequate warning for security or privacy concerns. In the few cases where this specification requires reporting of errors
    891                to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, requirements
    892                that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, run-time
    893                options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption
    894                of normal processing if the user has already made that choice.
    895             </p>
     973            <div id="rfc.section.2.2.p.1">
     974               <p>When considering the design of HTTP, it is easy to fall into a trap of thinking that
     975                  all user agents are general-purpose browsers and all origin servers are large public
     976                  websites. That is not the case in practice. Common HTTP user agents include household
     977                  appliances, stereos, scales, firmware update scripts, command-line programs, mobile
     978                  apps, and communication devices in a multitude of shapes and sizes. Likewise, common
     979                  HTTP origin servers include home automation units, configurable networking components,
     980                  office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and
     981                  video-delivery platforms.
     982               </p>
     983            </div>
     984            <div id="rfc.section.2.2.p.2">
     985               <p>The term "user agent" does not imply that there is a human user directly interacting
     986                  with the software agent at the time of a request. In many cases, a user agent is installed
     987                  or configured to run in the background and save its results for later inspection (or
     988                  save only a subset of those results that might be interesting or erroneous). Spiders,
     989                  for example, are typically given a start URI and configured to follow certain behavior
     990                  while crawling the Web as a hypertext graph.
     991               </p>
     992            </div>
     993            <div id="rfc.section.2.2.p.3">
     994               <p>The implementation diversity of HTTP means that not all user agents can make interactive
     995                  suggestions to their user or provide adequate warning for security or privacy concerns.
     996                  In the few cases where this specification requires reporting of errors to the user,
     997                  it is acceptable for such reporting to only be observable in an error console or log
     998                  file. Likewise, requirements that an automated action be confirmed by the user before
     999                  proceeding might be met via advance configuration choices, run-time options, or simple
     1000                  avoidance of the unsafe action; confirmation does not imply any specific user interface
     1001                  or interruption of normal processing if the user has already made that choice.
     1002               </p>
     1003            </div>
    8961004         </div>
    8971005         <div id="intermediaries">
    898             <div id="rfc.iref.i.1"></div>
    8991006            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a href="#intermediaries">Intermediaries</a></h2>
    900             <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of
    901                HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel,
    902                switching behavior based on the nature of each request.
    903             </p>
    904             <div id="rfc.figure.u.4"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
     1007            <div id="rfc.section.2.3.p.1">
     1008               <p>HTTP enables the use of intermediaries to satisfy requests through a chain of connections.
     1009                  There are three common forms of HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an
     1010                  origin server, proxy, gateway, or tunnel, switching behavior based on the nature of
     1011                  each request.
     1012               </p>
     1013            </div>
     1014            <div id="rfc.figure.u.4"><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
    9051015    <b>UA</b> =========== <b>A</b> =========== <b>B</b> =========== <b>C</b> =========== <b>O</b>
    9061016               &lt;             &lt;             &lt;             &lt;
    907 </pre><p id="rfc.section.2.3.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
    908                message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply
    909                only to the connection with the nearest, non-tunnel neighbor, only to the endpoints of the chain, or to all connections along
    910                the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For
    911                example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C,
    912                at the same time that it is handling A's request. Likewise, later requests might be sent through a different path of connections,
    913                often based on dynamic configuration for load balancing.
    914             </p>
    915             <p id="rfc.section.2.3.p.4"><span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> The terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" are used to describe directional requirements in relation to the message flow: all messages flow from upstream to downstream.
    916                The terms "inbound" and "outbound" are used to describe directional requirements in relation to the request route: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent.
    917             </p>
    918             <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message-forwarding agent that is selected by the client, usually via local configuration rules, to receive requests
    919                for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
    920                are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
    921                different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
    922                for the sake of security, annotation services, or shared caching. Some proxies are designed to apply transformations to selected
    923                messages or payloads while they are being forwarded, as described in <a href="#message.transformations" title="Transformations">Section&nbsp;5.7.2</a>.
    924             </p>
    925             <p id="rfc.section.2.3.p.6"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a. "<dfn>reverse proxy</dfn>") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards
    926                them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services,
    927                to improve server performance through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load balancing of HTTP services across multiple machines.
    928             </p>
    929             <p id="rfc.section.2.3.p.7">All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates
    930                with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of
    931                this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers ought to conform
    932                to user agent requirements on the gateway's inbound connection.
    933             </p>
    934             <p id="rfc.section.2.3.p.8"><span id="rfc.iref.t.1"></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
    935                to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    936                ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    937                when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy.
    938             </p>
    939             <p id="rfc.section.2.3.p.9">The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
    940                intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the
    941                knowledge or permission of message senders. Network intermediaries are indistinguishable (at a protocol level) from a man-in-the-middle
    942                attack, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.
    943             </p>
    944             <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.2"></span> <span id="rfc.iref.c.3"></span> For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects
    945                outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public
    946                network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services,
    947                and within corporate firewalls to enforce network usage policies.
    948             </p>
    949             <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
    950                depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple
    951                servers. Hence, a server <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
    952                to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems.
    953             </p>
     1017</pre></div>
     1018            <div id="rfc.section.2.3.p.2">
     1019               <p>The figure above shows three intermediaries (A, B, and C) between the user agent and
     1020                  origin server. A request or response message that travels the whole chain will pass
     1021                  through four separate connections. Some HTTP communication options might apply only
     1022                  to the connection with the nearest, non-tunnel neighbor, only to the endpoints of
     1023                  the chain, or to all connections along the chain. Although the diagram is linear,
     1024                  each participant might be engaged in multiple, simultaneous communications. For example,
     1025                  B might be receiving requests from many clients other than A, and/or forwarding requests
     1026                  to servers other than C, at the same time that it is handling A's request. Likewise,
     1027                  later requests might be sent through a different path of connections, often based
     1028                  on dynamic configuration for load balancing.
     1029               </p>
     1030            </div>
     1031            <div id="rfc.section.2.3.p.3">
     1032               <p><span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.1"></span><span id="rfc.iref.o.2"></span> The terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" are used to describe directional requirements in relation to the message flow: all
     1033                  messages flow from upstream to downstream. The terms "inbound" and "outbound" are
     1034                  used to describe directional requirements in relation to the request route: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent.
     1035               </p>
     1036            </div>
     1037            <div id="rfc.section.2.3.p.4">
     1038               <p><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message-forwarding agent that is selected by the client, usually via local
     1039                  configuration rules, to receive requests for some type(s) of absolute URI and attempt
     1040                  to satisfy those requests via translation through the HTTP interface. Some translations
     1041                  are minimal, such as for proxy requests for "http" URIs, whereas other requests might
     1042                  require translation to and from entirely different application-level protocols. Proxies
     1043                  are often used to group an organization's HTTP requests through a common intermediary
     1044                  for the sake of security, annotation services, or shared caching. Some proxies are
     1045                  designed to apply transformations to selected messages or payloads while they are
     1046                  being forwarded, as described in <a href="#message.transformations" title="Transformations">Section&nbsp;5.7.2</a>.
     1047               </p>
     1048            </div>
     1049            <div id="rfc.section.2.3.p.5">
     1050               <p><span id="rfc.iref.g.1"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a. "<dfn>reverse proxy</dfn>") is an intermediary that acts as an origin server for the outbound connection but
     1051                  translates received requests and forwards them inbound to another server or servers.
     1052                  Gateways are often used to encapsulate legacy or untrusted information services, to
     1053                  improve server performance through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load balancing of HTTP services across multiple
     1054                  machines.
     1055               </p>
     1056            </div>
     1057            <div id="rfc.section.2.3.p.6">
     1058               <p>All HTTP requirements applicable to an origin server also apply to the outbound communication
     1059                  of a gateway. A gateway communicates with inbound servers using any protocol that
     1060                  it desires, including private extensions to HTTP that are outside the scope of this
     1061                  specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party
     1062                  HTTP servers ought to conform to user agent requirements on the gateway's inbound
     1063                  connection.
     1064               </p>
     1065            </div>
     1066            <div id="rfc.section.2.3.p.7">
     1067               <p><span id="rfc.iref.t.1"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once
     1068                  active, a tunnel is not considered a party to the HTTP communication, though the tunnel
     1069                  might have been initiated by an HTTP request. A tunnel ceases to exist when both ends
     1070                  of the relayed connection are closed. Tunnels are used to extend a virtual connection
     1071                  through an intermediary, such as when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy.
     1072               </p>
     1073            </div>
     1074            <div id="rfc.section.2.3.p.8">
     1075               <p>The above categories for intermediary only consider those acting as participants in
     1076                  the HTTP communication. There are also intermediaries that can act on lower layers
     1077                  of the network protocol stack, filtering or redirecting HTTP traffic without the knowledge
     1078                  or permission of message senders. Network intermediaries are indistinguishable (at
     1079                  a protocol level) from a man-in-the-middle attack, often introducing security flaws
     1080                  or interoperability problems due to mistakenly violating HTTP semantics.
     1081               </p>
     1082            </div>
     1083            <div id="rfc.section.2.3.p.9">
     1084               <p><span id="rfc.iref.i.2"></span> <span id="rfc.iref.t.2"></span> <span id="rfc.iref.c.1"></span> For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an
     1085                  interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally
     1086                  other common port traffic). Interception proxies are commonly found on public network
     1087                  access points, as a means of enforcing account subscription prior to allowing use
     1088                  of non-local Internet services, and within corporate firewalls to enforce network
     1089                  usage policies.
     1090               </p>
     1091            </div>
     1092            <div id="rfc.section.2.3.p.10">
     1093               <p>HTTP is defined as a stateless protocol, meaning that each request message can be
     1094                  understood in isolation. Many implementations depend on HTTP's stateless design in
     1095                  order to reuse proxied connections or dynamically load balance requests across multiple
     1096                  servers. Hence, a server <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless
     1097                  the connection is secured and specific to that agent. Some non-standard HTTP extensions
     1098                  (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability
     1099                  problems.
     1100               </p>
     1101            </div>
    9541102         </div>
    9551103         <div id="caches">
    956             <div id="rfc.iref.c.4"></div>
    9571104            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a href="#caches">Caches</a></h2>
    958             <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
    959                A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
    960                requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.
    961             </p>
    962             <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
    963                response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response
    964                from O (via C) for a request that has not been cached by UA or A.
    965             </p>
    966             <div id="rfc.figure.u.5"></div><pre class="drawing">            &gt;             &gt;
     1105            <div id="rfc.section.2.4.p.1">
     1106               <p>A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its
     1107                  message storage, retrieval, and deletion. A cache stores cacheable responses in order
     1108                  to reduce the response time and network bandwidth consumption on future, equivalent
     1109                  requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a
     1110                  tunnel.
     1111               </p>
     1112            </div>
     1113            <div id="rfc.section.2.4.p.2">
     1114               <p>The effect of a cache is that the request/response chain is shortened if one of the
     1115                  participants along the chain has a cached response applicable to that request. The
     1116                  following illustrates the resulting chain if B has a cached copy of an earlier response
     1117                  from O (via C) for a request that has not been cached by UA or A.
     1118               </p>
     1119            </div>
     1120            <div id="rfc.figure.u.5"><pre class="drawing">            &gt;             &gt;
    9671121       <b>UA</b> =========== <b>A</b> =========== <b>B</b> - - - - - - <b>C</b> - - - - - - <b>O</b>
    9681122                  &lt;             &lt;
    969 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response
    970                is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
    971                can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
    972             </p>
    973             <p id="rfc.section.2.4.p.5">There is a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large
    974                organizations. These include national hierarchies of proxy caches to save transoceanic bandwidth, collaborative systems that
    975                broadcast or multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments,
    976                and so on.
    977             </p>
     1123</pre></div>
     1124            <div id="rfc.section.2.4.p.3">
     1125               <p><span id="rfc.iref.c.2"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering
     1126                  subsequent requests. Even when a response is cacheable, there might be additional
     1127                  constraints placed by the client or by the origin server on when that cached response
     1128                  can be used for a particular request. HTTP requirements for cache behavior and cacheable
     1129                  responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
     1130               </p>
     1131            </div>
     1132            <div id="rfc.section.2.4.p.4">
     1133               <p>There is a wide variety of architectures and configurations of caches deployed across
     1134                  the World Wide Web and inside large organizations. These include national hierarchies
     1135                  of proxy caches to save transoceanic bandwidth, collaborative systems that broadcast
     1136                  or multicast cache entries, archives of pre-fetched cache entries for use in off-line
     1137                  or high-latency environments, and so on.
     1138               </p>
     1139            </div>
    9781140         </div>
    9791141         <div id="conformance">
    9801142            <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2>
    981             <p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    982                requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    983                or caches, depending on what behavior is being constrained by the requirement. Additional (social) requirements are placed
    984                on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.
    985             </p>
    986             <p id="rfc.section.2.5.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
    987                forwarding a received element downstream.
    988             </p>
    989             <p id="rfc.section.2.5.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    990                in HTTP.
    991             </p>
    992             <p id="rfc.section.2.5.p.4">Conformance includes both the syntax and semantics of protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message,
    993                a sender <em class="bcp14">MUST NOT</em> generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e.,
    994                a role that the sender does not have for that message).
    995             </p>
    996             <p id="rfc.section.2.5.p.5">When a received protocol element is parsed, the recipient <em class="bcp14">MUST</em> be able to parse any value of reasonable length that is applicable to the recipient's role and that matches the grammar defined
    997                by the corresponding ABNF rules. Note, however, that some received protocol elements might not be parsed. For example, an
    998                intermediary forwarding a message might parse a header-field into generic field-name and field-value components, but then
    999                forward the header field without further parsing inside the field-value.
    1000             </p>
    1001             <p id="rfc.section.2.5.p.6">HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate
    1002                will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders
    1003                and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore,
    1004                what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two
    1005                decades of HTTP use and is expected to continue changing in the future.
    1006             </p>
    1007             <p id="rfc.section.2.5.p.7">At a minimum, a recipient <em class="bcp14">MUST</em> be able to parse and process protocol element lengths that are at least as long as the values that it generates for those
    1008                same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own
    1009                resources needs to be able to parse and process those same references when received as a request target.
    1010             </p>
    1011             <p id="rfc.section.2.5.p.8">A recipient <em class="bcp14">MUST</em> interpret a received protocol element according to the semantics defined for it by this specification, including extensions
    1012                to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly
    1013                implements what is implied by those semantics. For example, an origin server might disregard the contents of a received <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> header field if inspection of the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> header field indicates a specific implementation version that is known to fail on receipt of certain content codings.
    1014             </p>
    1015             <p id="rfc.section.2.5.p.9">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
    1016                except when they have a direct impact on security, since different applications of the protocol require different error handling
    1017                strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
    1018                to be dangerous.
    1019             </p>
     1143            <div id="rfc.section.2.5.p.1">
     1144               <p>This specification targets conformance criteria according to the role of a participant
     1145                  in HTTP communication. Hence, HTTP requirements are placed on senders, recipients,
     1146                  clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
     1147                  or caches, depending on what behavior is being constrained by the requirement. Additional
     1148                  (social) requirements are placed on implementations, resource owners, and protocol
     1149                  element registrations when they apply beyond the scope of a single communication.
     1150               </p>
     1151            </div>
     1152            <div id="rfc.section.2.5.p.2">
     1153               <p>The verb "generate" is used instead of "send" where a requirement differentiates between
     1154                  creating a protocol element and merely forwarding a received element downstream.
     1155               </p>
     1156            </div>
     1157            <div id="rfc.section.2.5.p.3">
     1158               <p>An implementation is considered conformant if it complies with all of the requirements
     1159                  associated with the roles it partakes in HTTP.
     1160               </p>
     1161            </div>
     1162            <div id="rfc.section.2.5.p.4">
     1163               <p>Conformance includes both the syntax and semantics of protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be
     1164                  false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the corresponding
     1165                  ABNF rules. Within a given message, a sender <em class="bcp14">MUST NOT</em> generate protocol elements or syntax alternatives that are only allowed to be generated
     1166                  by participants in other roles (i.e., a role that the sender does not have for that
     1167                  message).
     1168               </p>
     1169            </div>
     1170            <div id="rfc.section.2.5.p.5">
     1171               <p>When a received protocol element is parsed, the recipient <em class="bcp14">MUST</em> be able to parse any value of reasonable length that is applicable to the recipient's
     1172                  role and that matches the grammar defined by the corresponding ABNF rules. Note, however,
     1173                  that some received protocol elements might not be parsed. For example, an intermediary
     1174                  forwarding a message might parse a header-field into generic field-name and field-value
     1175                  components, but then forward the header field without further parsing inside the field-value.
     1176               </p>
     1177            </div>
     1178            <div id="rfc.section.2.5.p.6">
     1179               <p>HTTP does not have specific length limitations for many of its protocol elements because
     1180                  the lengths that might be appropriate will vary widely, depending on the deployment
     1181                  context and purpose of the implementation. Hence, interoperability between senders
     1182                  and recipients depends on shared expectations regarding what is a reasonable length
     1183                  for each protocol element. Furthermore, what is commonly understood to be a reasonable
     1184                  length for some protocol elements has changed over the course of the past two decades
     1185                  of HTTP use and is expected to continue changing in the future.
     1186               </p>
     1187            </div>
     1188            <div id="rfc.section.2.5.p.7">
     1189               <p>At a minimum, a recipient <em class="bcp14">MUST</em> be able to parse and process protocol element lengths that are at least as long as
     1190                  the values that it generates for those same protocol elements in other messages. For
     1191                  example, an origin server that publishes very long URI references to its own resources
     1192                  needs to be able to parse and process those same references when received as a request
     1193                  target.
     1194               </p>
     1195            </div>
     1196            <div id="rfc.section.2.5.p.8">
     1197               <p>A recipient <em class="bcp14">MUST</em> interpret a received protocol element according to the semantics defined for it by
     1198                  this specification, including extensions to this specification, unless the recipient
     1199                  has determined (through experience or configuration) that the sender incorrectly implements
     1200                  what is implied by those semantics. For example, an origin server might disregard
     1201                  the contents of a received <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> header field if inspection of the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> header field indicates a specific implementation version that is known to fail on
     1202                  receipt of certain content codings.
     1203               </p>
     1204            </div>
     1205            <div id="rfc.section.2.5.p.9">
     1206               <p>Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does
     1207                  not define specific error handling mechanisms except when they have a direct impact
     1208                  on security, since different applications of the protocol require different error
     1209                  handling strategies. For example, a Web browser might wish to transparently recover
     1210                  from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client
     1211                  might consider any form of error recovery to be dangerous.
     1212               </p>
     1213            </div>
    10201214         </div>
    10211215         <div id="http.version">
    10221216            <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a href="#http.version">Protocol Versioning</a></h2>
    1023             <p id="rfc.section.2.6.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1".
    1024                The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's
    1025                corresponding specification of HTTP.
    1026             </p>
    1027             <p id="rfc.section.2.6.p.2">The version of an HTTP message is indicated by an HTTP-version field in the first line of the message. HTTP-version is case-sensitive.</p>
    1028             <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#http.version" class="smpl">HTTP-version</a>  = <a href="#http.version" class="smpl">HTTP-name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>
     1217            <div id="rfc.section.2.6.p.1">
     1218               <p>HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol.
     1219                  This specification defines version "1.1". The protocol version as a whole indicates
     1220                  the sender's conformance with the set of requirements laid out in that version's corresponding
     1221                  specification of HTTP.
     1222               </p>
     1223            </div>
     1224            <div id="rfc.section.2.6.p.2">
     1225               <p>The version of an HTTP message is indicated by an HTTP-version field in the first
     1226                  line of the message. HTTP-version is case-sensitive.
     1227               </p>
     1228            </div>
     1229            <div id="rfc.figure.u.6"><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#http.version" class="smpl">HTTP-version</a>  = <a href="#http.version" class="smpl">HTTP-name</a> "/" <a href="#core.rules" class="smpl">DIGIT</a> "." <a href="#core.rules" class="smpl">DIGIT</a>
    10291230  <a href="#http.version" class="smpl">HTTP-name</a>     = %x48.54.54.50 ; "HTTP", case-sensitive
    1030 </pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
    1031                version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version
    1032                within that major version to which the sender is conformant and able to understand for future communication. The minor version
    1033                advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the
    1034                protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future
    1035                requests (by clients).
    1036             </p>
    1037             <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
    1038                message if all of the newer features are ignored. This specification places recipient-version requirements on some new features
    1039                so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt
    1040                of a message, that the recipient supports HTTP/1.1.
    1041             </p>
    1042             <p id="rfc.section.2.6.p.6">The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default
    1043                behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
    1044                are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.
    1045             </p>
    1046             <p id="rfc.section.2.6.p.7">New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely
    1047                ignored by recipients that do not recognize them. Header field extensibility is discussed in <a href="#field.extensibility" title="Field Extensibility">Section&nbsp;3.2.1</a>.
    1048             </p>
    1049             <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they are not allowed to blindly forward the first line
    1050                of an HTTP message without ensuring that the protocol version in that message matches a version to which that intermediary
    1051                is conformant for both the receiving and sending of messages. Forwarding an HTTP message without rewriting the HTTP-version
    1052                might result in communication errors when downstream recipients use the message sender's version to determine what features
    1053                are safe to use for later communication with that sender.
    1054             </p>
    1055             <p id="rfc.section.2.6.p.9">A client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher
    1056                than the highest version supported by the server, if this is known. A client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant.
    1057             </p>
    1058             <p id="rfc.section.2.6.p.10">A client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
    1059                the client has attempted at least one normal request and determined from the response status code or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
    1060             </p>
    1061             <p id="rfc.section.2.6.p.11">A server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant that has a major version less than
    1062                or equal to the one received in the request. A server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server can send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not Supported)</a> response if it wishes, for any reason, to refuse service of the client's major protocol version.
    1063             </p>
    1064             <p id="rfc.section.2.6.p.12">A server <em class="bcp14">MAY</em> send an HTTP/1.0 response to a request if it is known or suspected that the client incorrectly implements the HTTP specification
    1065                and is incapable of correctly processing later version responses, such as when a client fails to parse the version number
    1066                correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the given minor
    1067                version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
    1068             </p>
    1069             <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
    1070                is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding
    1071                to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented
    1072                for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision has specifically avoided any such changes to the protocol.
    1073             </p>
    1074             <p id="rfc.section.2.6.p.14">When an HTTP message is received with a major version number that the recipient implements, but a higher minor version number
    1075                than what the recipient implements, the recipient <em class="bcp14">SHOULD</em> process the message as if it were in the highest minor version within that major version to which the recipient is conformant.
    1076                A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support
    1077                for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major
    1078                version.
    1079             </p>
     1231</pre></div>
     1232            <div id="rfc.section.2.6.p.3">
     1233               <p>The HTTP version number consists of two decimal digits separated by a "." (period
     1234                  or decimal point). The first digit ("major version") indicates the HTTP messaging
     1235                  syntax, whereas the second digit ("minor version") indicates the highest minor version
     1236                  within that major version to which the sender is conformant and able to understand
     1237                  for future communication. The minor version advertises the sender's communication
     1238                  capabilities even when the sender is only using a backwards-compatible subset of the
     1239                  protocol, thereby letting the recipient know that more advanced features can be used
     1240                  in response (by servers) or in future requests (by clients).
     1241               </p>
     1242            </div>
     1243            <div id="rfc.section.2.6.p.4">
     1244               <p>When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such
     1245                  that it can be interpreted as a valid HTTP/1.0 message if all of the newer features
     1246                  are ignored. This specification places recipient-version requirements on some new
     1247                  features so that a conformant sender will only use compatible features until it has
     1248                  determined, through configuration or the receipt of a message, that the recipient
     1249                  supports HTTP/1.1.
     1250               </p>
     1251            </div>
     1252            <div id="rfc.section.2.6.p.5">
     1253               <p>The interpretation of a header field does not change between minor versions of the
     1254                  same major HTTP version, though the default behavior of a recipient in the absence
     1255                  of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
     1256                  are defined for all versions of HTTP/1.x. In particular, the <a href="#header.host" class="smpl">Host</a> and <a href="#header.connection" class="smpl">Connection</a> header fields ought to be implemented by all HTTP/1.x implementations whether or not
     1257                  they advertise conformance with HTTP/1.1.
     1258               </p>
     1259            </div>
     1260            <div id="rfc.section.2.6.p.6">
     1261               <p>New header fields can be introduced without changing the protocol version if their
     1262                  defined semantics allow them to be safely ignored by recipients that do not recognize
     1263                  them. Header field extensibility is discussed in <a href="#field.extensibility" title="Field Extensibility">Section&nbsp;3.2.1</a>.
     1264               </p>
     1265            </div>
     1266            <div id="rfc.section.2.6.p.7">
     1267               <p>Intermediaries that process HTTP messages (i.e., all intermediaries other than those
     1268                  acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-version in forwarded messages. In other words, they are not allowed
     1269                  to blindly forward the first line of an HTTP message without ensuring that the protocol
     1270                  version in that message matches a version to which that intermediary is conformant
     1271                  for both the receiving and sending of messages. Forwarding an HTTP message without
     1272                  rewriting the HTTP-version might result in communication errors when downstream recipients
     1273                  use the message sender's version to determine what features are safe to use for later
     1274                  communication with that sender.
     1275               </p>
     1276            </div>
     1277            <div id="rfc.section.2.6.p.8">
     1278               <p>A client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant
     1279                  and whose major version is no higher than the highest version supported by the server,
     1280                  if this is known. A client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant.
     1281               </p>
     1282            </div>
     1283            <div id="rfc.section.2.6.p.9">
     1284               <p>A client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements
     1285                  the HTTP specification, but only after the client has attempted at least one normal
     1286                  request and determined from the response status code or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
     1287               </p>
     1288            </div>
     1289            <div id="rfc.section.2.6.p.10">
     1290               <p>A server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant
     1291                  that has a major version less than or equal to the one received in the request. A
     1292                  server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server can send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not Supported)</a> response if it wishes, for any reason, to refuse service of the client's major protocol
     1293                  version.
     1294               </p>
     1295            </div>
     1296            <div id="rfc.section.2.6.p.11">
     1297               <p>A server <em class="bcp14">MAY</em> send an HTTP/1.0 response to a request if it is known or suspected that the client
     1298                  incorrectly implements the HTTP specification and is incapable of correctly processing
     1299                  later version responses, such as when a client fails to parse the version number correctly
     1300                  or when an intermediary is known to blindly forward the HTTP-version even when it
     1301                  doesn't conform to the given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more
     1302                  of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
     1303               </p>
     1304            </div>
     1305            <div id="rfc.section.2.6.p.12">
     1306               <p>The intention of HTTP's versioning design is that the major number will only be incremented
     1307                  if an incompatible message syntax is introduced, and that the minor number will only
     1308                  be incremented when changes made to the protocol have the effect of adding to the
     1309                  message semantics or implying additional capabilities of the sender. However, the
     1310                  minor version was not incremented for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision has specifically avoided any such changes to the protocol.
     1311               </p>
     1312            </div>
     1313            <div id="rfc.section.2.6.p.13">
     1314               <p>When an HTTP message is received with a major version number that the recipient implements,
     1315                  but a higher minor version number than what the recipient implements, the recipient <em class="bcp14">SHOULD</em> process the message as if it were in the highest minor version within that major version
     1316                  to which the recipient is conformant. A recipient can assume that a message with a
     1317                  higher minor version, when sent to a recipient that has not yet indicated support
     1318                  for that higher version, is sufficiently backwards-compatible to be safely processed
     1319                  by any implementation of the same major version.
     1320               </p>
     1321            </div>
    10801322         </div>
    10811323         <div id="uri">
    1082             <div id="rfc.iref.r.5"></div>
    10831324            <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a href="#uri">Uniform Resource Identifiers</a></h2>
    1084             <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
    1085             </p>
    1086             <p id="rfc.section.2.7.p.2">The definitions of "URI-reference", "absolute-URI", "relative-part", "scheme", "authority", "port", "host", "path-abempty",
    1087                "segment", "query", and "fragment" are adopted from the URI generic syntax. An "absolute-path" rule is defined for protocol
    1088                elements that can contain a non-empty path component. (This rule differs slightly from the path-abempty rule of RFC 3986,
    1089                which allows for an empty path to be used in references, and path-absolute rule, which does not allow paths that begin with
    1090                "//".) A "partial-URI" rule is defined for protocol elements that can contain a relative URI but not a fragment component.
    1091             </p>
    1092             <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, see <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
     1325            <div id="rfc.section.2.7.p.1">
     1326               <p>Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
     1327               </p>
     1328            </div>
     1329            <div id="rfc.section.2.7.p.2">
     1330               <p>The definitions of "URI-reference", "absolute-URI", "relative-part", "scheme", "authority",
     1331                  "port", "host", "path-abempty", "segment", "query", and "fragment" are adopted from
     1332                  the URI generic syntax. An "absolute-path" rule is defined for protocol elements that
     1333                  can contain a non-empty path component. (This rule differs slightly from the path-abempty
     1334                  rule of RFC 3986, which allows for an empty path to be used in references, and path-absolute
     1335                  rule, which does not allow paths that begin with "//".) A "partial-URI" rule is defined
     1336                  for protocol elements that can contain a relative URI but not a fragment component.
     1337               </p>
     1338            </div>
     1339            <div id="rfc.figure.u.7"><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, see <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
    10931340  <a href="#uri" class="smpl">absolute-URI</a>  = &lt;absolute-URI, see <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>&gt;
    10941341  <a href="#uri" class="smpl">relative-part</a> = &lt;relative-part, see <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>&gt;
     
    11041351  <a href="#uri" class="smpl">absolute-path</a> = 1*( "/" segment )
    11051352  <a href="#uri" class="smpl">partial-URI</a>   = relative-part [ "?" query ]
    1106 </pre><p id="rfc.section.2.7.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
    1107                any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components,
    1108                or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request
    1109                URI (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>).
    1110             </p>
     1353</pre></div>
     1354            <div id="rfc.section.2.7.p.3">
     1355               <p>Each protocol element in HTTP that allows a URI reference will indicate in its ABNF
     1356                  production whether the element allows any form of reference (URI-reference), only
     1357                  a URI in absolute form (absolute-URI), only the path and optional query components,
     1358                  or some combination of the above. Unless otherwise indicated, URI references are parsed
     1359                  relative to the effective request URI (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>).
     1360               </p>
     1361            </div>
    11111362            <div id="http.uri">
    11121363               <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;<a href="#http.uri">http URI Scheme</a></h3>
    1113                <div id="rfc.iref.h.1"></div>
    1114                <div id="rfc.iref.u.3"></div>
    1115                <p id="rfc.section.2.7.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
    1116                   namespace governed by a potential HTTP origin server listening for TCP (<a href="#RFC0793" id="rfc.xref.RFC0793.1"><cite title="Transmission Control Protocol">[RFC0793]</cite></a>) connections on a given port.
    1117                </p>
    1118                <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     1364               <div id="rfc.section.2.7.1.p.1">
     1365                  <p>The "http" URI scheme is hereby defined for the purpose of minting identifiers according
     1366                     to their association with the hierarchical namespace governed by a potential HTTP
     1367                     origin server listening for TCP (<a href="#RFC0793" id="rfc.xref.RFC0793.1"><cite title="Transmission Control Protocol">[RFC0793]</cite></a>) connections on a given port.
     1368                  </p>
     1369               </div>
     1370               <div id="rfc.figure.u.8"><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    11191371             [ "#" <a href="#uri" class="smpl">fragment</a> ]
    1120 </pre><p id="rfc.section.2.7.1.p.3">The origin server for an "http" URI is identified by the <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The hierarchical path component and optional query component serve as an identifier for a potential target resource within
    1121                   that origin server's name space. The optional fragment component allows for indirect identification of a secondary resource,
    1122                   independent of the URI scheme, as defined in <a href="https://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
    1123                </p>
    1124                <p id="rfc.section.2.7.1.p.4">A sender <em class="bcp14">MUST NOT</em> generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference <em class="bcp14">MUST</em> reject it as invalid.
    1125                </p>
    1126                <p id="rfc.section.2.7.1.p.5">If the host identifier is provided as an IP address, the origin server is the listener (if any) on the indicated TCP port
    1127                   at that IP address. If host is a registered name, the registered name is an indirect identifier for use with a name resolution
    1128                   service, such as DNS, to find an address for that origin server. If the port subcomponent is empty or not given, TCP port
    1129                   80 (the reserved port for WWW services) is the default.
    1130                </p>
    1131                <p id="rfc.section.2.7.1.p.6">Note that the presence of a URI with a given authority component does not imply that there is always an HTTP server listening
    1132                   for connections on that host and port. Anyone can mint a URI. What the authority component determines is who has the right
    1133                   to respond authoritatively to requests that target the identified resource. The delegated nature of registered names and IP
    1134                   addresses creates a federated namespace, based on control over the indicated host and port, whether or not an HTTP server
    1135                   is present. See <a href="#establishing.authority" title="Establishing Authority">Section&nbsp;9.1</a> for security considerations related to establishing authority.
    1136                </p>
    1137                <p id="rfc.section.2.7.1.p.7">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,
    1138                   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;5</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.codes" title="Response Status Codes">Section 6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, then that response is considered an authoritative answer to the client's request.
    1139                </p>
    1140                <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    1141                   delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
    1142                   would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that
    1143                   require an end-to-end secured connection. Other protocols might also be used to provide access to "http" identified resources
    1144                   — it is only the authoritative interface that is specific to TCP.
    1145                </p>
    1146                <p id="rfc.section.2.7.1.p.9">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
    1147                   configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
    1148                   even though such usage might expose a user identifier or password. A sender <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a
    1149                   request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing
    1150                   attacks.
    1151                </p>
     1372</pre></div>
     1373               <div id="rfc.section.2.7.1.p.2">
     1374                  <p>The origin server for an "http" URI is identified by the <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The hierarchical path component and optional query component serve as an identifier
     1375                     for a potential target resource within that origin server's name space. The optional
     1376                     fragment component allows for indirect identification of a secondary resource, independent
     1377                     of the URI scheme, as defined in <a href="https://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
     1378                  </p>
     1379               </div>
     1380               <div id="rfc.section.2.7.1.p.3">
     1381                  <p>A sender <em class="bcp14">MUST NOT</em> generate an "http" URI with an empty host identifier. A recipient that processes such
     1382                     a URI reference <em class="bcp14">MUST</em> reject it as invalid.
     1383                  </p>
     1384               </div>
     1385               <div id="rfc.section.2.7.1.p.4">
     1386                  <p>If the host identifier is provided as an IP address, the origin server is the listener
     1387                     (if any) on the indicated TCP port at that IP address. If host is a registered name,
     1388                     the registered name is an indirect identifier for use with a name resolution service,
     1389                     such as DNS, to find an address for that origin server. If the port subcomponent is
     1390                     empty or not given, TCP port 80 (the reserved port for WWW services) is the default.
     1391                  </p>
     1392               </div>
     1393               <div id="rfc.section.2.7.1.p.5">
     1394                  <p>Note that the presence of a URI with a given authority component does not imply that
     1395                     there is always an HTTP server listening for connections on that host and port. Anyone
     1396                     can mint a URI. What the authority component determines is who has the right to respond
     1397                     authoritatively to requests that target the identified resource. The delegated nature
     1398                     of registered names and IP addresses creates a federated namespace, based on control
     1399                     over the indicated host and port, whether or not an HTTP server is present. See <a href="#establishing.authority" title="Establishing Authority">Section&nbsp;9.1</a> for security considerations related to establishing authority.
     1400                  </p>
     1401               </div>
     1402               <div id="rfc.section.2.7.1.p.6">
     1403                  <p>When an "http" URI is used within a context that calls for access to the indicated
     1404                     resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection
     1405                     to that address on the indicated port, 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;5</a>) to the server. If the server responds to that request with a non-interim HTTP response
     1406                     message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1407                  </p>
     1408               </div>
     1409               <div id="rfc.section.2.7.1.p.7">
     1410                  <p>Although HTTP is independent of the transport protocol, the "http" scheme is specific
     1411                     to TCP-based services because the name delegation process depends on TCP for establishing
     1412                     authority. An HTTP service based on some other underlying connection protocol would
     1413                     presumably be identified using a different URI scheme, just as the "https" scheme
     1414                     (below) is used for resources that require an end-to-end secured connection. Other
     1415                     protocols might also be used to provide access to "http" identified resources — it
     1416                     is only the authoritative interface that is specific to TCP.
     1417                  </p>
     1418               </div>
     1419               <div id="rfc.section.2.7.1.p.8">
     1420                  <p>The URI generic syntax for authority also includes a deprecated userinfo subcomponent
     1421                     (<a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make
     1422                     use of the userinfo component for internal configuration of authentication information,
     1423                     such as within command invocation options, configuration files, or bookmark lists,
     1424                     even though such usage might expose a user identifier or password. A sender <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference
     1425                     is generated within a message as a request target or header field value. Before making
     1426                     use of an "http" URI reference received from an untrusted source, a recipient <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error; it is likely being used to
     1427                     obscure the authority for the sake of phishing attacks.
     1428                  </p>
     1429               </div>
    11521430            </div>
    11531431            <div id="https.uri">
    11541432               <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;<a href="#https.uri">https URI Scheme</a></h3>
    1155                <div id="rfc.iref.h.2"></div>
    1156                <div id="rfc.iref.u.4"></div>
    1157                <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical
    1158                   namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections (<a href="#RFC5246" id="rfc.xref.RFC5246.2"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>).
    1159                </p>
    1160                <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that TCP port
    1161                   443 is the default if the port subcomponent is empty or not given, and the user agent <em class="bcp14">MUST</em> ensure that its connection to the origin server is secured through the use of strong encryption, end-to-end, prior to sending
    1162                   the first HTTP request.
    1163                </p>
    1164                <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     1433               <div id="rfc.section.2.7.2.p.1">
     1434                  <p>The "https" URI scheme is hereby defined for the purpose of minting identifiers according
     1435                     to their association with the hierarchical namespace governed by a potential HTTP
     1436                     origin server listening to a given TCP port for TLS-secured connections (<a href="#RFC5246" id="rfc.xref.RFC5246.2"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>).
     1437                  </p>
     1438               </div>
     1439               <div id="rfc.section.2.7.2.p.2">
     1440                  <p>All of the requirements listed above for the "http" scheme are also requirements for
     1441                     the "https" scheme, except that TCP port 443 is the default if the port subcomponent
     1442                     is empty or not given, and the user agent <em class="bcp14">MUST</em> ensure that its connection to the origin server is secured through the use of strong
     1443                     encryption, end-to-end, prior to sending the first HTTP request.
     1444                  </p>
     1445               </div>
     1446               <div id="rfc.figure.u.9"><pre class="inline"><span id="rfc.iref.g.16"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    11651447              [ "#" <a href="#uri" class="smpl">fragment</a> ]
    1166 </pre><p id="rfc.section.2.7.2.p.4">Note that the "https" URI scheme depends on both TLS and TCP for establishing authority. Resources made available via the
    1167                   "https" scheme have no shared identity with the "http" scheme even if their resource identifiers indicate the same authority
    1168                   (the same host listening to the same TCP port). They are distinct namespaces and are considered to be distinct origin servers.
    1169                   However, an extension to HTTP that is defined to apply to entire host domains, such as the Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains.
    1170                </p>
    1171                <p id="rfc.section.2.7.2.p.5">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.2"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
    1172                </p>
     1448</pre></div>
     1449               <div id="rfc.section.2.7.2.p.3">
     1450                  <p>Note that the "https" URI scheme depends on both TLS and TCP for establishing authority.
     1451                     Resources made available via the "https" scheme have no shared identity with the "http"
     1452                     scheme even if their resource identifiers indicate the same authority (the same host
     1453                     listening to the same TCP port). They are distinct namespaces and are considered to
     1454                     be distinct origin servers. However, an extension to HTTP that is defined to apply
     1455                     to entire host domains, such as the Cookie protocol <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>, can allow information set by one service to impact communication with other services
     1456                     within a matching group of host domains.
     1457                  </p>
     1458               </div>
     1459               <div id="rfc.section.2.7.2.p.4">
     1460                  <p>The process for authoritative access to an "https" identified resource is defined
     1461                     in <a href="#RFC2818" id="rfc.xref.RFC2818.2"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
     1462                  </p>
     1463               </div>
    11731464            </div>
    11741465            <div id="uri.comparison">
    11751466               <h3 id="rfc.section.2.7.3"><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></h3>
    1176                <p id="rfc.section.2.7.3.p.1">Since the "http" and "https" schemes conform to the URI generic syntax, such URIs are normalized and compared according to
    1177                   the algorithm defined in <a href="https://tools.ietf.org/html/rfc3986#section-6">Section 6</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, using the defaults described above for each scheme.
    1178                </p>
    1179                <p id="rfc.section.2.7.3.p.2">If the port is equal to the default port for a scheme, the normal form is to omit the port subcomponent. When not being used
    1180                   in absolute form as the request target of an OPTIONS request, an empty path component is equivalent to an absolute path of
    1181                   "/", so the normal form is to provide a path of "/" instead. The scheme and host are case-insensitive and normally provided
    1182                   in lowercase; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved"
    1183                   set are equivalent to their percent-encoded octets: the normal form is to not encode them (see Sections <a href="https://tools.ietf.org/html/rfc3986#section-2.1" id="rfc.xref.RFC3986.18">2.1</a> and <a href="https://tools.ietf.org/html/rfc3986#section-2.2" id="rfc.xref.RFC3986.19">2.2</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>).
    1184                </p>
    1185                <p id="rfc.section.2.7.3.p.3">For example, the following three URIs are equivalent:</p>
    1186                <div id="rfc.figure.u.10"></div><pre class="text">   http://example.com:80/~smith/home.html
     1467               <div id="rfc.section.2.7.3.p.1">
     1468                  <p>Since the "http" and "https" schemes conform to the URI generic syntax, such URIs
     1469                     are normalized and compared according to the algorithm defined in <a href="https://tools.ietf.org/html/rfc3986#section-6">Section 6</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, using the defaults described above for each scheme.
     1470                  </p>
     1471               </div>
     1472               <div id="rfc.section.2.7.3.p.2">
     1473                  <p>If the port is equal to the default port for a scheme, the normal form is to omit
     1474                     the port subcomponent. When not being used in absolute form as the request target
     1475                     of an OPTIONS request, an empty path component is equivalent to an absolute path of
     1476                     "/", so the normal form is to provide a path of "/" instead. The scheme and host are
     1477                     case-insensitive and normally provided in lowercase; all other components are compared
     1478                     in a case-sensitive manner. Characters other than those in the "reserved" set are
     1479                     equivalent to their percent-encoded octets: the normal form is to not encode them
     1480                     (see Sections <a href="https://tools.ietf.org/html/rfc3986#section-2.1" id="rfc.xref.RFC3986.18">2.1</a> and <a href="https://tools.ietf.org/html/rfc3986#section-2.2" id="rfc.xref.RFC3986.19">2.2</a> of <a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>).
     1481                  </p>
     1482               </div>
     1483               <div id="rfc.section.2.7.3.p.3">
     1484                  <p>For example, the following three URIs are equivalent:</p>
     1485               </div>
     1486               <div id="rfc.figure.u.10"><pre class="text">   http://example.com:80/~smith/home.html
    11871487   http://EXAMPLE.com/%7Esmith/home.html
    11881488   http://EXAMPLE.com:/%7esmith/home.html
    11891489</pre></div>
     1490            </div>
    11901491         </div>
    11911492      </div>
    11921493      <div id="http.message">
    11931494         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#http.message">Message Format</a></h1>
    1194          <div id="rfc.iref.h.3"></div>
    1195          <div id="rfc.iref.h.4"></div>
    1196          <div id="rfc.iref.h.5"></div>
    1197          <p id="rfc.section.3.p.1">All HTTP/1.1 messages consist of a start-line followed by a sequence of octets in a format similar to the Internet Message
    1198             Format <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating
    1199             the end of the header section, and an optional message body.
    1200          </p>
    1201          <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#http.message" class="smpl">HTTP-message</a>   = <a href="#http.message" class="smpl">start-line</a>
     1495         <div id="rfc.section.3.p.1">
     1496            <p>All HTTP/1.1 messages consist of a start-line followed by a sequence of octets in
     1497               a format similar to the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>: zero or more header fields (collectively referred to as the "headers" or the "header
     1498               section"), an empty line indicating the end of the header section, and an optional
     1499               message body.
     1500            </p>
     1501         </div>
     1502         <div id="rfc.figure.u.11"><pre class="inline"><span id="rfc.iref.g.17"></span>  <a href="#http.message" class="smpl">HTTP-message</a>   = <a href="#http.message" class="smpl">start-line</a>
    12021503                   *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
    12031504                   <a href="#core.rules" class="smpl">CRLF</a>
    12041505                   [ <a href="#message.body" class="smpl">message-body</a> ]
    1205 </pre><p id="rfc.section.3.p.3">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a
    1206             hash table by field name until the empty line, and then use the parsed data to determine if a message body is expected. If
    1207             a message body has been indicated, then it is read as a stream until an amount of octets equal to the message body length
    1208             is read or the connection is closed.
    1209          </p>
    1210          <p id="rfc.section.3.p.4">A recipient <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities
    1211             due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet
    1212             LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from
    1213             the message, such as within a header field-value after message parsing has delineated the individual fields.
    1214          </p>
    1215          <p id="rfc.section.3.p.5">An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, recipients cannot
    1216             rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the
    1217             sake of network efficiency, security checks, or payload transformations.
    1218          </p>
    1219          <p id="rfc.section.3.p.6">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. A recipient that receives whitespace between the start-line
    1220             and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore
    1221             the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received
    1222             or the header section is terminated).
    1223          </p>
    1224          <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing
    1225             the line after it as a new request, either of which might result in a security vulnerability if other implementations within
    1226             the request chain interpret the same message differently. Likewise, the presence of such whitespace in a response might be
    1227             ignored by some clients or cause others to cease parsing.
    1228          </p>
     1506</pre></div>
     1507         <div id="rfc.section.3.p.2">
     1508            <p>The normal procedure for parsing an HTTP message is to read the start-line into a
     1509               structure, read each header field into a hash table by field name until the empty
     1510               line, and then use the parsed data to determine if a message body is expected. If
     1511               a message body has been indicated, then it is read as a stream until an amount of
     1512               octets equal to the message body length is read or the connection is closed.
     1513            </p>
     1514         </div>
     1515         <div id="rfc.section.3.p.3">
     1516            <p>A recipient <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of
     1517               US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the
     1518               specific encoding, creates security vulnerabilities due to the varying ways that string
     1519               processing libraries handle invalid multibyte character sequences that contain the
     1520               octet LF (%x0A). String-based parsers can only be safely used within protocol elements
     1521               after the element has been extracted from the message, such as within a header field-value
     1522               after message parsing has delineated the individual fields.
     1523            </p>
     1524         </div>
     1525         <div id="rfc.section.3.p.4">
     1526            <p>An HTTP message can be parsed as a stream for incremental processing or forwarding
     1527               downstream. However, recipients cannot rely on incremental delivery of partial messages,
     1528               since some implementations will buffer or delay message forwarding for the sake of
     1529               network efficiency, security checks, or payload transformations.
     1530            </p>
     1531         </div>
     1532         <div id="rfc.section.3.p.5">
     1533            <p>A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. A recipient that
     1534               receives whitespace between the start-line and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without
     1535               further processing of it (i.e., ignore the entire line, along with any subsequent
     1536               lines preceded by whitespace, until a properly formed header field is received or
     1537               the header section is terminated).
     1538            </p>
     1539         </div>
     1540         <div id="rfc.section.3.p.6">
     1541            <p>The presence of such whitespace in a request might be an attempt to trick a server
     1542               into ignoring that field or processing the line after it as a new request, either
     1543               of which might result in a security vulnerability if other implementations within
     1544               the request chain interpret the same message differently. Likewise, the presence of
     1545               such whitespace in a response might be ignored by some clients or cause others to
     1546               cease parsing.
     1547            </p>
     1548         </div>
    12291549         <div id="start.line">
    12301550            <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#start.line">Start Line</a></h2>
    1231             <p id="rfc.section.3.1.p.1">An HTTP message can be either a request from client to server or a response from server to client. Syntactically, the two
    1232                types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses),
    1233                and in the algorithm for determining the length of the message body (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
    1234             </p>
    1235             <p id="rfc.section.3.1.p.2">In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line
    1236                formats, but, in practice, servers are implemented to only expect a request (a response is interpreted as an unknown or invalid
    1237                request method) and clients are implemented to only expect a response.
    1238             </p>
    1239             <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.30"></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>
    1240 </pre><div id="request.line">
     1551            <div id="rfc.section.3.1.p.1">
     1552               <p>An HTTP message can be either a request from client to server or a response from server
     1553                  to client. Syntactically, the two types of message differ only in the start-line,
     1554                  which is either a request-line (for requests) or a status-line (for responses), and
     1555                  in the algorithm for determining the length of the message body (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
     1556               </p>
     1557            </div>
     1558            <div id="rfc.section.3.1.p.2">
     1559               <p>In theory, a client could receive requests and a server could receive responses, distinguishing
     1560                  them by their different start-line formats, but, in practice, servers are implemented
     1561                  to only expect a request (a response is interpreted as an unknown or invalid request
     1562                  method) and clients are implemented to only expect a response.
     1563               </p>
     1564            </div>
     1565            <div id="rfc.figure.u.12"><pre class="inline"><span id="rfc.iref.g.18"></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>
     1566</pre></div>
     1567            <div id="request.line">
    12411568               <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a href="#request.line">Request Line</a></h3>
    1242                <p id="rfc.section.3.1.1.p.1">A request-line begins with a method token, followed by a single space (SP), the request-target, another single space (SP),
    1243                   the protocol version, and ends with CRLF.
    1244                </p>
    1245                <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.31"></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>
    1246 </pre><div id="rfc.iref.m.2"></div>
     1569               <div id="rfc.section.3.1.1.p.1">
     1570                  <p>A request-line begins with a method token, followed by a single space (SP), the request-target,
     1571                     another single space (SP), the protocol version, and ends with CRLF.
     1572                  </p>
     1573               </div>
     1574               <div id="rfc.figure.u.13"><pre class="inline"><span id="rfc.iref.g.19"></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>
     1575</pre></div>
     1576               <div id="rfc.iref.m.2"></div>
    12471577               <div id="method">
    1248                   <p id="rfc.section.3.1.1.p.3">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    1249                </div>
    1250                <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1251 </pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    1252                </p>
    1253                <div id="rfc.iref.r.6"></div>
    1254                <p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
    1255                </p>
    1256                <p id="rfc.section.3.1.1.p.7">Recipients typically parse the request-line into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section&nbsp;3.5</a>), since no whitespace is allowed in the three components. Unfortunately, some user agents fail to properly encode or exclude
    1257                   whitespace found in hypertext references, resulting in those disallowed characters being sent in a request-target.
    1258                </p>
    1259                <p id="rfc.section.3.1.1.p.8">Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. A recipient <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
    1260                   crafted to bypass security filters along the request chain.
    1261                </p>
    1262                <p id="rfc.section.3.1.1.p.9">HTTP does not place a predefined limit on the length of a request-line, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. A server that receives a method longer than any that it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server that receives a request-target longer than any URI it wishes to parse <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    1263                </p>
    1264                <p id="rfc.section.3.1.1.p.10">Various ad hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
    1265                </p>
     1578                  <div id="rfc.section.3.1.1.p.2">
     1579                     <p>The method token indicates the request method to be performed on the target resource.
     1580                        The request method is case-sensitive.
     1581                     </p>
     1582                  </div>
     1583               </div>
     1584               <div id="rfc.figure.u.14"><pre class="inline"><span id="rfc.iref.g.20"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
     1585</pre></div>
     1586               <div id="rfc.section.3.1.1.p.3">
     1587                  <p>The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, along with information regarding the HTTP method registry and considerations for
     1588                     defining new methods.
     1589                  </p>
     1590               </div>
     1591               <div id="rfc.iref.r.5"></div>
     1592               <div id="rfc.section.3.1.1.p.4">
     1593                  <p>The request-target identifies the target resource upon which to apply the request,
     1594                     as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
     1595                  </p>
     1596               </div>
     1597               <div id="rfc.section.3.1.1.p.5">
     1598                  <p>Recipients typically parse the request-line into its component parts by splitting
     1599                     on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section&nbsp;3.5</a>), since no whitespace is allowed in the three components. Unfortunately, some user
     1600                     agents fail to properly encode or exclude whitespace found in hypertext references,
     1601                     resulting in those disallowed characters being sent in a request-target.
     1602                  </p>
     1603               </div>
     1604               <div id="rfc.section.3.1.1.p.6">
     1605                  <p>Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. A recipient <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the
     1606                     invalid request-line might be deliberately crafted to bypass security filters along
     1607                     the request chain.
     1608                  </p>
     1609               </div>
     1610               <div id="rfc.section.3.1.1.p.7">
     1611                  <p>HTTP does not place a predefined limit on the length of a request-line, as described
     1612                     in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. A server that receives a method longer than any that it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server that receives a request-target longer than any URI it wishes
     1613                     to parse <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
     1614                  </p>
     1615               </div>
     1616               <div id="rfc.section.3.1.1.p.8">
     1617                  <p>Various ad hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of
     1618                     8000 octets.
     1619                  </p>
     1620               </div>
    12661621            </div>
    12671622            <div id="status.line">
    12681623               <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a href="#status.line">Status Line</a></h3>
    1269                <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,
    1270                   another space, a possibly empty textual phrase describing the status code, and ending with CRLF.
    1271                </p>
    1272                <div id="rfc.figure.u.15"></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.line" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    1273 </pre><p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
    1274                   the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
    1275                   for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
    1276                   the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
    1277                </p>
    1278                <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#status.line" class="smpl">status-code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    1279 </pre><p id="rfc.section.3.1.2.p.5">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
    1280                   code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text
    1281                   clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content.
    1282                </p>
    1283                <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#status.line" class="smpl">reason-phrase</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> )
    1284 </pre></div>
     1624               <div id="rfc.section.3.1.2.p.1">
     1625                  <p>The first line of a response message is the status-line, consisting of the protocol
     1626                     version, a space (SP), the status code, another space, a possibly empty textual phrase
     1627                     describing the status code, and ending with CRLF.
     1628                  </p>
     1629               </div>
     1630               <div id="rfc.figure.u.15"><pre class="inline"><span id="rfc.iref.g.21"></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.line" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
     1631</pre></div>
     1632               <div id="rfc.section.3.1.2.p.2">
     1633                  <p>The status-code element is a 3-digit integer code describing the result of the server's
     1634                     attempt to understand and satisfy the client's corresponding request. The rest of
     1635                     the response message is to be interpreted in light of the semantics defined for that
     1636                     status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for information about the semantics of status codes, including the classes of status
     1637                     code (indicated by the first digit), the status codes defined by this specification,
     1638                     considerations for the definition of new status codes, and the IANA registry.
     1639                  </p>
     1640               </div>
     1641               <div id="rfc.figure.u.16"><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#status.line" class="smpl">status-code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
     1642</pre></div>
     1643               <div id="rfc.section.3.1.2.p.3">
     1644                  <p>The reason-phrase element exists for the sole purpose of providing a textual description
     1645                     associated with the numeric status code, mostly out of deference to earlier Internet
     1646                     application protocols that were more frequently used with interactive text clients.
     1647                     A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content.
     1648                  </p>
     1649               </div>
     1650               <div id="rfc.figure.u.17"><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#status.line" class="smpl">reason-phrase</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> )
     1651</pre></div>
     1652            </div>
    12851653         </div>
    12861654         <div id="header.fields">
    12871655            <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#header.fields">Header Fields</a></h2>
    1288             <p id="rfc.section.3.2.p.1">Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field
    1289                value, and optional trailing whitespace.
    1290             </p>
    1291             <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">OWS</a>
     1656            <div id="rfc.section.3.2.p.1">
     1657               <p>Each header field consists of a case-insensitive field name followed by a colon (":"),
     1658                  optional leading whitespace, the field value, and optional trailing whitespace.
     1659               </p>
     1660            </div>
     1661            <div id="rfc.figure.u.18"><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">OWS</a>
    12921662
    12931663  <a href="#header.fields" class="smpl">field-name</a>     = <a href="#rule.token.separators" class="smpl">token</a>
     
    12991669                 ; obsolete line folding
    13001670                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>
    1301 </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,
    1302                the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> as containing the origination timestamp for the message in which it appears.
    1303             </p>
     1671</pre></div>
     1672            <div id="rfc.section.3.2.p.2">
     1673               <p>The field-name token labels the corresponding field-value as having the semantics
     1674                  defined by that header field. For example, the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> as containing the origination timestamp for the message in which it appears.
     1675               </p>
     1676            </div>
    13041677            <div id="field.extensibility">
    13051678               <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a href="#field.extensibility">Field Extensibility</a></h3>
    1306                <p id="rfc.section.3.2.1.p.1">Header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new
    1307                   semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification
    1308                   and in many other specifications outside this document set.
    1309                </p>
    1310                <p id="rfc.section.3.2.1.p.2">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    1311                   of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses.
    1312                </p>
    1313                <p id="rfc.section.3.2.1.p.3">A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. These requirements allow HTTP's functionality to be enhanced without requiring prior update
    1314                   of deployed intermediaries.
    1315                </p>
    1316                <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the "Message Headers" registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.
    1317                </p>
     1679               <div id="rfc.section.3.2.1.p.1">
     1680                  <p>Header fields are fully extensible: there is no limit on the introduction of new field
     1681                     names, each presumably defining new semantics, nor on the number of header fields
     1682                     used in a given message. Existing fields are defined in each part of this specification
     1683                     and in many other specifications outside this document set.
     1684                  </p>
     1685               </div>
     1686               <div id="rfc.section.3.2.1.p.2">
     1687                  <p>New header fields can be defined such that, when they are understood by a recipient,
     1688                     they might override or enhance the interpretation of previously defined header fields,
     1689                     define preconditions on request evaluation, or refine the meaning of responses.
     1690                  </p>
     1691               </div>
     1692               <div id="rfc.section.3.2.1.p.3">
     1693                  <p>A proxy <em class="bcp14">MUST</em> forward unrecognized header fields unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block, or otherwise transform, such fields.
     1694                     Other recipients <em class="bcp14">SHOULD</em> ignore unrecognized header fields. These requirements allow HTTP's functionality to
     1695                     be enhanced without requiring prior update of deployed intermediaries.
     1696                  </p>
     1697               </div>
     1698               <div id="rfc.section.3.2.1.p.4">
     1699                  <p>All defined header fields ought to be registered with IANA in the "Message Headers"
     1700                     registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.
     1701                  </p>
     1702               </div>
    13181703            </div>
    13191704            <div id="field.order">
    13201705               <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a href="#field.order">Field Order</a></h3>
    1321                <p id="rfc.section.3.2.2.p.1">The order in which header fields with differing field names are received is not significant. However, it is good practice
    1322                   to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST NOT</em> apply a request to the target resource until the entire request header section is received, since later header fields might
    1323                   include conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request
    1324                   processing.
    1325                </p>
    1326                <p id="rfc.section.3.2.2.p.2">A sender <em class="bcp14">MUST NOT</em> generate multiple header fields with the same field name in a message unless either the entire field value for that header
    1327                   field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
    1328                </p>
    1329                <p id="rfc.section.3.2.2.p.3">A recipient <em class="bcp14">MAY</em> combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics
    1330                   of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order
    1331                   in which header fields with the same field name are received is therefore significant to the interpretation of the combined
    1332                   field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
    1333                </p>
    1334                <div class="note" id="rfc.section.3.2.2.p.4">
    1335                   <p><b>Note:</b> In practice, the "Set-Cookie" header field (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on
    1336                      multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle
    1337                      "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.)
    1338                   </p>
     1706               <div id="rfc.section.3.2.2.p.1">
     1707                  <p>The order in which header fields with differing field names are received is not significant.
     1708                     However, it is good practice to send header fields that contain control data first,
     1709                     such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early
     1710                     as possible. A server <em class="bcp14">MUST NOT</em> apply a request to the target resource until the entire request header section is
     1711                     received, since later header fields might include conditionals, authentication credentials,
     1712                     or deliberately misleading duplicate header fields that would impact request processing.
     1713                  </p>
     1714               </div>
     1715               <div id="rfc.section.3.2.2.p.2">
     1716                  <p>A sender <em class="bcp14">MUST NOT</em> generate multiple header fields with the same field name in a message unless either
     1717                     the entire field value for that header field is defined as a comma-separated list
     1718                     [i.e., #(values)] or the header field is a well-known exception (as noted below).
     1719                  </p>
     1720               </div>
     1721               <div id="rfc.section.3.2.2.p.3">
     1722                  <p>A recipient <em class="bcp14">MAY</em> combine multiple header fields with the same field name into one "field-name: field-value"
     1723                     pair, without changing the semantics of the message, by appending each subsequent
     1724                     field value to the combined field value in order, separated by a comma. The order
     1725                     in which header fields with the same field name are received is therefore significant
     1726                     to the interpretation of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
     1727                  </p>
     1728               </div>
     1729               <div class="note">
     1730                  <div id="rfc.section.3.2.2.p.4">
     1731                     <p><b>Note:</b> In practice, the "Set-Cookie" header field (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>) often appears multiple times in a response message and does not use the list syntax,
     1732                        violating the above requirements on multiple header fields with the same name. Since
     1733                        it cannot be combined into a single field-value, recipients ought to handle "Set-Cookie"
     1734                        as a special case while processing header fields. (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.)
     1735                     </p>
     1736                  </div>
    13391737               </div>
    13401738            </div>
     
    13421740               <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a href="#whitespace">Whitespace</a></h3>
    13431741               <div id="rule.LWS">
    1344                   <p id="rfc.section.3.2.3.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),
    1345                      and BWS ("bad" whitespace).
    1346                   </p>
     1742                  <div id="rfc.section.3.2.3.p.1">
     1743                     <p>This specification uses three rules to denote the use of linear whitespace: OWS (optional
     1744                        whitespace), RWS (required whitespace), and BWS ("bad" whitespace).
     1745                     </p>
     1746                  </div>
    13471747               </div>
    13481748               <div id="rule.OWS">
    1349                   <p id="rfc.section.3.2.3.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements where optional whitespace
    1350                      is preferred to improve readability, a sender <em class="bcp14">SHOULD</em> generate the optional whitespace as a single SP; otherwise, a sender <em class="bcp14">SHOULD NOT</em> generate optional whitespace except as needed to white out invalid or unwanted protocol elements during in-place message filtering.
    1351                   </p>
     1749                  <div id="rfc.section.3.2.3.p.2">
     1750                     <p>The OWS rule is used where zero or more linear whitespace octets might appear. For
     1751                        protocol elements where optional whitespace is preferred to improve readability, a
     1752                        sender <em class="bcp14">SHOULD</em> generate the optional whitespace as a single SP; otherwise, a sender <em class="bcp14">SHOULD NOT</em> generate optional whitespace except as needed to white out invalid or unwanted protocol
     1753                        elements during in-place message filtering.
     1754                     </p>
     1755                  </div>
    13521756               </div>
    13531757               <div id="rule.RWS">
    1354                   <p id="rfc.section.3.2.3.p.3">The RWS rule is used when at least one linear whitespace octet is required to separate field tokens. A sender <em class="bcp14">SHOULD</em> generate RWS as a single SP.
    1355                   </p>
     1758                  <div id="rfc.section.3.2.3.p.3">
     1759                     <p>The RWS rule is used when at least one linear whitespace octet is required to separate
     1760                        field tokens. A sender <em class="bcp14">SHOULD</em> generate RWS as a single SP.
     1761                     </p>
     1762                  </div>
    13561763               </div>
    13571764               <div id="rule.BWS">
    1358                   <p id="rfc.section.3.2.3.p.4">The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender <em class="bcp14">MUST NOT</em> generate BWS in messages. A recipient <em class="bcp14">MUST</em> parse for such bad whitespace and remove it before interpreting the protocol element.
    1359                   </p>
     1765                  <div id="rfc.section.3.2.3.p.4">
     1766                     <p>The BWS rule is used where the grammar allows optional whitespace only for historical
     1767                        reasons. A sender <em class="bcp14">MUST NOT</em> generate BWS in messages. A recipient <em class="bcp14">MUST</em> parse for such bad whitespace and remove it before interpreting the protocol element.
     1768                     </p>
     1769                  </div>
    13601770               </div>
    13611771               <div id="rule.whitespace">
    1362                   <p id="rfc.section.3.2.3.p.5">   </p>
    1363                </div>
    1364                <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span>  <a href="#rule.whitespace" class="smpl">OWS</a>            = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
     1772                  <div id="rfc.section.3.2.3.p.5"></div>
     1773               </div>
     1774               <div id="rfc.figure.u.19"><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span>  <a href="#rule.whitespace" class="smpl">OWS</a>            = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
    13651775                 ; optional whitespace
    13661776  <a href="#rule.whitespace" class="smpl">RWS</a>            = 1*( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
     
    13691779                 ; "bad" whitespace
    13701780</pre></div>
     1781            </div>
    13711782            <div id="field.parsing">
    13721783               <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a href="#field.parsing">Field Parsing</a></h3>
    1373                <p id="rfc.section.3.2.4.p.1">Messages are parsed using a generic algorithm, independent of the individual header field names. The contents within a given
    1374                   field value are not parsed until a later stage of message interpretation (usually after the message's entire header section
    1375                   has been processed). Consequently, this specification does not use ABNF rules to define each "Field-Name: Field Value" pair,
    1376                   as was done in previous editions. Instead, this specification uses ABNF rules that are named according to each registered
    1377                   field name, wherein the rule defines the valid grammar for that field's corresponding field values (i.e., after the field-value
    1378                   has been extracted from the header section by a generic field parser).
    1379                </p>
    1380                <p id="rfc.section.3.2.4.p.2">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
    1381                   have led to security vulnerabilities in request routing and response handling. A server <em class="bcp14">MUST</em> reject any received request message that contains whitespace between a header field-name and colon with a response code of <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>. A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
    1382                </p>
    1383                <p id="rfc.section.3.2.4.p.3">A field value might be preceded and/or followed by optional whitespace (OWS); a single SP preceding the field-value is preferred
    1384                   for consistent readability by humans. The field value does not include any leading or trailing whitespace: OWS occurring before
    1385                   the first non-whitespace octet of the field value or after the last non-whitespace octet of the field value ought to be excluded
    1386                   by parsers when extracting the field value from a header field.
    1387                </p>
    1388                <p id="rfc.section.3.2.4.p.4">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    1389                   space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1390                   (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;8.3.1</a>). A sender <em class="bcp14">MUST NOT</em> generate a message that includes line folding (i.e., that has any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type.
    1391                </p>
    1392                <p id="rfc.section.3.2.4.p.5">A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
    1393                </p>
    1394                <p id="rfc.section.3.2.4.p.6">A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
    1395                </p>
    1396                <p id="rfc.section.3.2.4.p.7">A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value.
    1397                </p>
    1398                <p id="rfc.section.3.2.4.p.8">Historically, HTTP has allowed field content with text in the ISO‑8859‑1 charset <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US‑ASCII octets. A recipient <em class="bcp14">SHOULD</em> treat other octets in field content (obs‑text) as opaque data.
    1399                </p>
     1784               <div id="rfc.section.3.2.4.p.1">
     1785                  <p>Messages are parsed using a generic algorithm, independent of the individual header
     1786                     field names. The contents within a given field value are not parsed until a later
     1787                     stage of message interpretation (usually after the message's entire header section
     1788                     has been processed). Consequently, this specification does not use ABNF rules to define
     1789                     each "Field-Name: Field Value" pair, as was done in previous editions. Instead, this
     1790                     specification uses ABNF rules that are named according to each registered field name,
     1791                     wherein the rule defines the valid grammar for that field's corresponding field values
     1792                     (i.e., after the field-value has been extracted from the header section by a generic
     1793                     field parser).
     1794                  </p>
     1795               </div>
     1796               <div id="rfc.section.3.2.4.p.2">
     1797                  <p>No whitespace is allowed between the header field-name and colon. In the past, differences
     1798                     in the handling of such whitespace have led to security vulnerabilities in request
     1799                     routing and response handling. A server <em class="bcp14">MUST</em> reject any received request message that contains whitespace between a header field-name
     1800                     and colon with a response code of <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>. A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
     1801                  </p>
     1802               </div>
     1803               <div id="rfc.section.3.2.4.p.3">
     1804                  <p>A field value might be preceded and/or followed by optional whitespace (OWS); a single
     1805                     SP preceding the field-value is preferred for consistent readability by humans. The
     1806                     field value does not include any leading or trailing whitespace: OWS occurring before
     1807                     the first non-whitespace octet of the field value or after the last non-whitespace
     1808                     octet of the field value ought to be excluded by parsers when extracting the field
     1809                     value from a header field.
     1810                  </p>
     1811               </div>
     1812               <div id="rfc.section.3.2.4.p.4">
     1813                  <p>Historically, HTTP header field values could be extended over multiple lines by preceding
     1814                     each extra line with at least one space or horizontal tab (obs-fold). This specification
     1815                     deprecates such line folding except within the message/http media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;8.3.1</a>). A sender <em class="bcp14">MUST NOT</em> generate a message that includes line folding (i.e., that has any field-value that
     1816                     contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type.
     1817                  </p>
     1818               </div>
     1819               <div id="rfc.section.3.2.4.p.5">
     1820                  <p>A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable,
     1821                     or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
     1822                  </p>
     1823               </div>
     1824               <div id="rfc.section.3.2.4.p.6">
     1825                  <p>A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding
     1826                     was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
     1827                  </p>
     1828               </div>
     1829               <div id="rfc.section.3.2.4.p.7">
     1830                  <p>A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value.
     1831                  </p>
     1832               </div>
     1833               <div id="rfc.section.3.2.4.p.8">
     1834                  <p>Historically, HTTP has allowed field content with text in the ISO‑8859‑1 charset <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII
     1835                     charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US‑ASCII octets. A recipient <em class="bcp14">SHOULD</em> treat other octets in field content (obs‑text) as opaque data.
     1836                  </p>
     1837               </div>
    14001838            </div>
    14011839            <div id="field.limits">
    14021840               <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a href="#field.limits">Field Limits</a></h3>
    1403                <p id="rfc.section.3.2.5.p.1">HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole,
    1404                   as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. Various ad hoc limitations on individual header field length are found in practice, often depending on the specific field
    1405                   semantics.
    1406                </p>
    1407                <p id="rfc.section.3.2.5.p.2">A server that receives a request header field, or set of fields, larger than it wishes to process <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (<a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>).
    1408                </p>
    1409                <p id="rfc.section.3.2.5.p.3">A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such
    1410                   that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
    1411                </p>
     1841               <div id="rfc.section.3.2.5.p.1">
     1842                  <p>HTTP does not place a predefined limit on the length of each header field or on the
     1843                     length of the header section as a whole, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. Various ad hoc limitations on individual header field length are found in practice,
     1844                     often depending on the specific field semantics.
     1845                  </p>
     1846               </div>
     1847               <div id="rfc.section.3.2.5.p.2">
     1848                  <p>A server that receives a request header field, or set of fields, larger than it wishes
     1849                     to process <em class="bcp14">MUST</em> respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code. Ignoring such header fields would increase the server's vulnerability
     1850                     to request smuggling attacks (<a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>).
     1851                  </p>
     1852               </div>
     1853               <div id="rfc.section.3.2.5.p.3">
     1854                  <p>A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes
     1855                     to process if the field semantics are such that the dropped value(s) can be safely
     1856                     ignored without changing the message framing or response semantics.
     1857                  </p>
     1858               </div>
    14121859            </div>
    14131860            <div id="field.components">
    14141861               <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;<a href="#field.components">Field Value Components</a></h3>
    14151862               <div id="rule.token.separators">
    1416                   <p id="rfc.section.3.2.6.p.1">  <span id="rfc.iref.d.2"></span> Most HTTP header field values are defined using common syntax components (token, quoted-string, and comment) separated by
    1417                      whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not allowed
    1418                      in a <a href="#rule.token.separators" class="smpl">token</a> (DQUOTE and "(),/:;&lt;=&gt;?@[\]{}").
    1419                   </p>
    1420                </div>
    1421                <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span>  <a href="#rule.token.separators" class="smpl">token</a>          = 1*<a href="#rule.token.separators" class="smpl">tchar</a>
     1863                  <div id="rfc.section.3.2.6.p.1">
     1864                     <p>  <span id="rfc.iref.d.2"></span> Most HTTP header field values are defined using common syntax components (token, quoted-string,
     1865                        and comment) separated by whitespace or specific delimiting characters. Delimiters
     1866                        are chosen from the set of US-ASCII visual characters not allowed in a <a href="#rule.token.separators" class="smpl">token</a> (DQUOTE and "(),/:;&lt;=&gt;?@[\]{}").
     1867                     </p>
     1868                  </div>
     1869               </div>
     1870               <div id="rfc.figure.u.20"><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span>  <a href="#rule.token.separators" class="smpl">token</a>          = 1*<a href="#rule.token.separators" class="smpl">tchar</a>
    14221871
    14231872  <a href="#rule.token.separators" class="smpl">tchar</a>          = "!" / "#" / "$" / "%" / "&amp;" / "'" / "*"
     
    14251874                 / <a href="#core.rules" class="smpl">DIGIT</a> / <a href="#core.rules" class="smpl">ALPHA</a>
    14261875                 ; any <a href="#core.rules" class="smpl">VCHAR</a>, except delimiters
    1427 </pre><div id="rule.quoted-string">
    1428                   <p id="rfc.section.3.2.6.p.3">   A string of text is parsed as a single value if it is quoted using double-quote marks.</p>
    1429                </div>
    1430                <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
     1876</pre></div>
     1877               <div id="rule.quoted-string">
     1878                  <div id="rfc.section.3.2.6.p.2">
     1879                     <p>   A string of text is parsed as a single value if it is quoted using double-quote marks.</p>
     1880                  </div>
     1881               </div>
     1882               <div id="rfc.figure.u.21"><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
    14311883  <a href="#rule.quoted-string" class="smpl">qdtext</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>
    14321884  <a href="#rule.quoted-string" class="smpl">obs-text</a>       = %x80-FF
    1433 </pre><div id="rule.comment">
    1434                   <p id="rfc.section.3.2.6.p.5">  Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
    1435                      in fields containing "comment" as part of their field value definition.
    1436                   </p>
    1437                </div>
    1438                <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
     1885</pre></div>
     1886               <div id="rule.comment">
     1887                  <div id="rfc.section.3.2.6.p.3">
     1888                     <p>  Comments can be included in some HTTP header fields by surrounding the comment text
     1889                        with parentheses. Comments are only allowed in fields containing "comment" as part
     1890                        of their field value definition.
     1891                     </p>
     1892                  </div>
     1893               </div>
     1894               <div id="rfc.figure.u.22"><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span>  <a href="#rule.comment" class="smpl">comment</a>        = "(" *( <a href="#rule.comment" class="smpl">ctext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> / <a href="#rule.comment" class="smpl">comment</a> ) ")"
    14391895  <a href="#rule.comment" class="smpl">ctext</a>          = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    1440 </pre><div id="rule.quoted-pair">
    1441                   <p id="rfc.section.3.2.6.p.7"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string and comment constructs. Recipients
    1442                      that process the value of a quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.
    1443                   </p>
    1444                </div>
    1445                <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-pair</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> )
    1446 </pre><p id="rfc.section.3.2.6.p.9">A sender <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that
    1447                   string. A sender <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a comment except where necessary to quote parentheses ["(" and ")"] and backslash octets occurring
    1448                   within that comment.
    1449                </p>
     1896</pre></div>
     1897               <div id="rule.quoted-pair">
     1898                  <div id="rfc.section.3.2.6.p.4">
     1899                     <p> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string
     1900                        and comment constructs. Recipients that process the value of a quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.
     1901                     </p>
     1902                  </div>
     1903               </div>
     1904               <div id="rfc.figure.u.23"><pre class="inline"><span id="rfc.iref.g.40"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-pair</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> )
     1905</pre></div>
     1906               <div id="rfc.section.3.2.6.p.5">
     1907                  <p>A sender <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and
     1908                     backslash octets occurring within that string. A sender <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a comment except where necessary to quote parentheses ["("
     1909                     and ")"] and backslash octets occurring within that comment.
     1910                  </p>
     1911               </div>
    14501912            </div>
    14511913         </div>
    14521914         <div id="message.body">
    14531915            <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a href="#message.body">Message Body</a></h2>
    1454             <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body
    1455                is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;3.3.1</a>.
    1456             </p>
    1457             <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
    1458 </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p>
    1459             <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if the method does not define any use for a
    1460                message body.
    1461             </p>
    1462             <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
    1463                status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to a CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero
    1464                length.
    1465             </p>
     1916            <div id="rfc.section.3.3.p.1">
     1917               <p>The message body (if any) of an HTTP message is used to carry the payload body of
     1918                  that request or response. The message body is identical to the payload body unless
     1919                  a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;3.3.1</a>.
     1920               </p>
     1921            </div>
     1922            <div id="rfc.figure.u.24"><pre class="inline"><span id="rfc.iref.g.41"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
     1923</pre></div>
     1924            <div id="rfc.section.3.3.p.2">
     1925               <p>The rules for when a message body is allowed in a message differ for requests and
     1926                  responses.
     1927               </p>
     1928            </div>
     1929            <div id="rfc.section.3.3.p.3">
     1930               <p>The presence of a message body in a request is signaled by a <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field. Request message framing is independent of method semantics, even if
     1931                  the method does not define any use for a message body.
     1932               </p>
     1933            </div>
     1934            <div id="rfc.section.3.3.p.4">
     1935               <p>The presence of a message body in a response depends on both the request method to
     1936                  which it is responding and the response status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request
     1937                  method had been GET (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to a CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message
     1938                  body, although the body might be of zero length.
     1939               </p>
     1940            </div>
    14661941            <div id="header.transfer-encoding">
    1467                <div id="rfc.iref.t.3"></div>
    1468                <div id="rfc.iref.c.6"></div>
    14691942               <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></h3>
    1470                <p id="rfc.section.3.3.1.p.1">The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that
    1471                   have been (or will be) applied to the payload body in order to form the message body. Transfer codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>.
    1472                </p>
    1473                <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    1474 </pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport
    1475                   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="https://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's case, Transfer-Encoding is
    1476                   primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only
    1477                   applied for transport efficiency or security from those that are characteristics of the selected resource.
    1478                </p>
    1479                <p id="rfc.section.3.3.1.p.4">A recipient <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer
    1480                   coding other than chunked is applied to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than
    1481                   chunked is applied to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection.
    1482                </p>
    1483                <div id="rfc.figure.u.26"></div>
    1484                <p>For example,</p><pre class="text">  Transfer-Encoding: gzip, chunked
    1485 </pre><p>indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while
    1486                   forming the message body.
    1487                </p>
    1488                <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
    1489                   chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding
    1490                   changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters can be provided
    1491                   by other header fields not defined by this specification.
    1492                </p>
    1493                <p id="rfc.section.3.3.1.p.7">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
    1494                   coding to the message body if the request had been an unconditional GET. This indication is not required, however, because
    1495                   any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
    1496                </p>
    1497                <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    1498                </p>
    1499                <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
    1500                   not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge
    1501                   might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later).
    1502                </p>
    1503                <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a>.
    1504                </p>
     1943               <div id="rfc.section.3.3.1.p.1">
     1944                  <p>The Transfer-Encoding header field lists the transfer coding names corresponding to
     1945                     the sequence of transfer codings that have been (or will be) applied to the payload
     1946                     body in order to form the message body. Transfer codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>.
     1947                  </p>
     1948               </div>
     1949               <div id="rfc.figure.u.25"><pre class="inline"><span id="rfc.iref.g.42"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
     1950</pre></div>
     1951               <div id="rfc.section.3.3.1.p.2">
     1952                  <p>Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which
     1953                     was designed to enable safe transport of binary data over a 7-bit transport service
     1954                     (<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="https://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol.
     1955                     In HTTP's case, Transfer-Encoding is primarily intended to accurately delimit a dynamically
     1956                     generated payload and to distinguish payload encodings that are only applied for transport
     1957                     efficiency or security from those that are characteristics of the selected resource.
     1958                  </p>
     1959               </div>
     1960               <div id="rfc.section.3.3.1.p.3">
     1961                  <p>A recipient <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is
     1962                     not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked
     1963                     message is not allowed). If any transfer coding other than chunked is applied to a
     1964                     request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly
     1965                     framed. If any transfer coding other than chunked is applied to a response payload
     1966                     body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing
     1967                     the connection.
     1968                  </p>
     1969               </div>
     1970               <div id="rfc.figure.u.26">
     1971                  <p>For example,</p><pre class="text">  Transfer-Encoding: gzip, chunked
     1972</pre><p>indicates that the payload body has been compressed using the gzip coding and then
     1973                     chunked using the chunked coding while forming the message body.
     1974                  </p>
     1975               </div>
     1976               <div id="rfc.section.3.3.1.p.4">
     1977                  <p>Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and
     1978                     any recipient along the request/response chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the
     1979                     message body, assuming that corresponding changes are made to the Transfer-Encoding
     1980                     field-value. Additional information about the encoding parameters can be provided
     1981                     by other header fields not defined by this specification.
     1982                  </p>
     1983               </div>
     1984               <div id="rfc.section.3.3.1.p.5">
     1985                  <p>Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the
     1986                     origin server would have applied a transfer coding to the message body if the request
     1987                     had been an unconditional GET. This indication is not required, however, because any
     1988                     recipient on the response chain (including the origin server) can remove transfer
     1989                     codings when they are not needed.
     1990                  </p>
     1991               </div>
     1992               <div id="rfc.section.3.3.1.p.6">
     1993                  <p>A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
     1994                  </p>
     1995               </div>
     1996               <div id="rfc.section.3.3.1.p.7">
     1997                  <p>Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations
     1998                     advertising only HTTP/1.0 support will not understand how to process a transfer-encoded
     1999                     payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle
     2000                     HTTP/1.1 (or later) requests; such knowledge might be in the form of specific user
     2001                     configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates
     2002                     HTTP/1.1 (or later).
     2003                  </p>
     2004               </div>
     2005               <div id="rfc.section.3.3.1.p.8">
     2006                  <p>A server that receives a request message with a transfer coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a>.
     2007                  </p>
     2008               </div>
    15052009            </div>
    15062010            <div id="header.content-length">
    1507                <div id="rfc.iref.c.7"></div>
    15082011               <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a href="#header.content-length">Content-Length</a></h3>
    1509                <p id="rfc.section.3.3.2.p.1">When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential
    1510                   payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information
    1511                   necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length
    1512                   indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    1513                </p>
    1514                <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    1515 </pre><p id="rfc.section.3.3.2.p.3">An example is</p>
    1516                <div id="rfc.figure.u.28"></div><pre class="text">  Content-Length: 3495
    1517 </pre><p id="rfc.section.3.3.2.p.5">A sender <em class="bcp14">MUST NOT</em> send a Content-Length header field in any message that contains a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field.
    1518                </p>
    1519                <p id="rfc.section.3.3.2.p.6">A user agent <em class="bcp14">SHOULD</em> send a Content-Length in a request message when no <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> is sent and the request method defines a meaning for an enclosed payload body. For example, a Content-Length header field
    1520                   is normally sent in a POST request even when the value is 0 (indicating an empty payload body). A user agent <em class="bcp14">SHOULD NOT</em> send a Content-Length header field when the request message does not contain a payload body and the method semantics do not
    1521                   anticipate such a body.
    1522                </p>
    1523                <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    1524                   in the payload body of a response if the same request had used the GET method.
    1525                </p>
    1526                <p id="rfc.section.3.3.2.p.8">A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    1527                   in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    1528                </p>
    1529                <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    1530                </p>
    1531                <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This
    1532                   will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
    1533                   the connection for additional requests.
    1534                </p>
    1535                <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
    1536                   a payload, a recipient <em class="bcp14">MUST</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.length" title="Attacks via Protocol Element Length">Section&nbsp;9.3</a>).
    1537                </p>
    1538                <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value,
    1539                   or a single Content-Length header field with a field value containing a list of identical decimal values (e.g., "Content-Length:
    1540                   42, 42"), indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor,
    1541                   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
    1542                   that decimal value prior to determining the message body length or forwarding the message.
    1543                </p>
    1544                <div class="note" id="rfc.section.3.3.2.p.13">
    1545                   <p><b>Note:</b> HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional
    1546                      field used only within the "message/external-body" media-type.
    1547                   </p>
     2012               <div id="rfc.section.3.3.2.p.1">
     2013                  <p>When a message does not have a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field, a Content-Length header field can provide the anticipated size, as a
     2014                     decimal number of octets, for a potential payload body. For messages that do include
     2015                     a payload body, the Content-Length field-value provides the framing information necessary
     2016                     for determining where the body (and message) ends. For messages that do not include
     2017                     a payload body, the Content-Length indicates the size of the selected representation
     2018                     (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
     2019                  </p>
     2020               </div>
     2021               <div id="rfc.figure.u.27"><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     2022</pre></div>
     2023               <div id="rfc.section.3.3.2.p.2">
     2024                  <p>An example is</p>
     2025               </div>
     2026               <div id="rfc.figure.u.28"><pre class="text">  Content-Length: 3495
     2027</pre></div>
     2028               <div id="rfc.section.3.3.2.p.3">
     2029                  <p>A sender <em class="bcp14">MUST NOT</em> send a Content-Length header field in any message that contains a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field.
     2030                  </p>
     2031               </div>
     2032               <div id="rfc.section.3.3.2.p.4">
     2033                  <p>A user agent <em class="bcp14">SHOULD</em> send a Content-Length in a request message when no <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> is sent and the request method defines a meaning for an enclosed payload body. For
     2034                     example, a Content-Length header field is normally sent in a POST request even when
     2035                     the value is 0 (indicating an empty payload body). A user agent <em class="bcp14">SHOULD NOT</em> send a Content-Length header field when the request message does not contain a payload
     2036                     body and the method semantics do not anticipate such a body.
     2037                  </p>
     2038               </div>
     2039               <div id="rfc.section.3.3.2.p.5">
     2040                  <p>A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number
     2041                     of octets that would have been sent in the payload body of a response if the same
     2042                     request had used the GET method.
     2043                  </p>
     2044               </div>
     2045               <div id="rfc.section.3.3.2.p.6">
     2046                  <p>A server <em class="bcp14">MAY</em> send a Content-Length header field in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to a conditional GET request (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number
     2047                     of octets that would have been sent in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
     2048                  </p>
     2049               </div>
     2050               <div id="rfc.section.3.3.2.p.7">
     2051                  <p>A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
     2052                  </p>
     2053               </div>
     2054               <div id="rfc.section.3.3.2.p.8">
     2055                  <p>Aside from the cases defined above, in the absence of Transfer-Encoding, an origin
     2056                     server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending
     2057                     the complete header section. This will allow downstream recipients to measure transfer
     2058                     progress, know when a received message is complete, and potentially reuse the connection
     2059                     for additional requests.
     2060                  </p>
     2061               </div>
     2062               <div id="rfc.section.3.3.2.p.9">
     2063                  <p>Any Content-Length field value greater than or equal to zero is valid. Since there
     2064                     is no predefined limit to the length of a payload, a recipient <em class="bcp14">MUST</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer
     2065                     conversion overflows (<a href="#attack.protocol.element.length" title="Attacks via Protocol Element Length">Section&nbsp;9.3</a>).
     2066                  </p>
     2067               </div>
     2068               <div id="rfc.section.3.3.2.p.10">
     2069                  <p>If a message is received that has multiple Content-Length header fields with field-values
     2070                     consisting of the same decimal value, or a single Content-Length header field with
     2071                     a field value containing a list of identical decimal values (e.g., "Content-Length:
     2072                     42, 42"), indicating that duplicate Content-Length header fields have been generated
     2073                     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
     2074                     single valid Content-Length field containing that decimal value prior to determining
     2075                     the message body length or forwarding the message.
     2076                  </p>
     2077               </div>
     2078               <div class="note">
     2079                  <div id="rfc.section.3.3.2.p.11">
     2080                     <p><b>Note:</b> HTTP's use of Content-Length for message framing differs significantly from the same
     2081                        field's use in MIME, where it is an optional field used only within the "message/external-body"
     2082                        media-type.
     2083                     </p>
     2084                  </div>
    15482085               </div>
    15492086            </div>
    15502087            <div id="message.body.length">
    1551                <div id="rfc.iref.c.8"></div>
    15522088               <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a href="#message.body.length">Message Body Length</a></h3>
    1553                <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p>
    1554                <p id="rfc.section.3.3.3.p.2"></p>
    1555                <ol>
    1556                   <li>
    1557                      <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present
    1558                         in the message, and thus cannot contain a message body.
    1559                      </p>
    1560                   </li>
    1561                   <li>
    1562                      <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes
    1563                         the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message.
    1564                      </p>
    1565                   </li>
    1566                   <li>
    1567                      <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer
    1568                         coding indicates the data is complete.
    1569                      </p>
    1570                      <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is
    1571                         determined by reading the connection until it is closed by the server. If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot
    1572                         be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
    1573                      </p>
    1574                      <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request
    1575                         smuggling (<a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>) or response splitting (<a href="#response.splitting" title="Response Splitting">Section&nbsp;9.4</a>) and ought to be handled as an error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream.
    1576                      </p>
    1577                   </li>
    1578                   <li>
    1579                      <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field having an invalid value, then the message
    1580                         framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable error. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response.
    1581                      </p>
    1582                   </li>
    1583                   <li>
    1584                      <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient
    1585                         times out before the indicated number of octets are received, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and close the connection.
    1586                      </p>
    1587                   </li>
    1588                   <li>
    1589                      <p>If this is a request message and none of the above are true, then the message body length is zero (no message body is present).</p>
    1590                   </li>
    1591                   <li>
    1592                      <p>Otherwise, this is a response message without a declared message body length, so the message body length is determined by
    1593                         the number of octets received prior to the server closing the connection.
    1594                      </p>
    1595                   </li>
    1596                </ol>
    1597                <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially received message interrupted
    1598                   by network failure, a server <em class="bcp14">SHOULD</em> generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards
    1599                   compatibility with HTTP/1.0.
    1600                </p>
    1601                <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
    1602                </p>
    1603                <p id="rfc.section.3.3.3.p.5">Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing
    1604                   services respond to chunked with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked transfer coding. This is typically because such services are implemented
    1605                   via a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the
    1606                   entire request before processing.
    1607                </p>
    1608                <p id="rfc.section.3.3.3.p.6">A user agent that sends a request containing a message body <em class="bcp14">MUST</em> send a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of
    1609                   specific user configuration or by remembering the version of a prior received response.
    1610                </p>
    1611                <p id="rfc.section.3.3.3.p.7">If the final response to the last request on a connection has been completely received and there remains additional data to
    1612                   read, a user agent <em class="bcp14">MAY</em> discard the remaining data or attempt to determine if that data belongs as part of the prior response body, which might be
    1613                   the case if the prior message's Content-Length value is incorrect. A client <em class="bcp14">MUST NOT</em> process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning.
    1614                </p>
     2089               <div id="rfc.section.3.3.3.p.1">
     2090                  <p>The length of a message body is determined by one of the following (in order of precedence):</p>
     2091               </div>
     2092               <div id="rfc.section.3.3.3.p.2">
     2093                  <ol>
     2094                     <li>
     2095                        <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields,
     2096                           regardless of the header fields present in the message, and thus cannot contain a
     2097                           message body.
     2098                        </p>
     2099                     </li>
     2100                     <li>
     2101                        <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately
     2102                           after the empty line that concludes the header fields. A client <em class="bcp14">MUST</em> ignore any <a href="#header.content-length" class="smpl">Content-Length</a> or <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header fields received in such a message.
     2103                        </p>
     2104                     </li>
     2105                     <li>
     2106                        <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present and the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) is the final encoding, the message body length is determined by reading and decoding
     2107                           the chunked data until the transfer coding indicates the data is complete.
     2108                        </p>
     2109                        <p>If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a response and the chunked transfer coding is not the final
     2110                           encoding, the message body length is determined by reading the connection until it
     2111                           is closed by the server. If a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field is present in a request and the chunked transfer coding is not the final
     2112                           encoding, the message body length cannot be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
     2113                        </p>
     2114                        <p>If a message is received with both a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and a <a href="#header.content-length" class="smpl">Content-Length</a> header field, the Transfer-Encoding overrides the Content-Length. Such a message might
     2115                           indicate an attempt to perform request smuggling (<a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>) or response splitting (<a href="#response.splitting" title="Response Splitting">Section&nbsp;9.4</a>) and ought to be handled as an error. A sender <em class="bcp14">MUST</em> remove the received Content-Length field prior to forwarding such a message downstream.
     2116                        </p>
     2117                     </li>
     2118                     <li>
     2119                        <p>If a message is received without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and with either multiple <a href="#header.content-length" class="smpl">Content-Length</a> header fields having differing field-values or a single Content-Length header field
     2120                           having an invalid value, then the message framing is invalid and the recipient <em class="bcp14">MUST</em> treat it as an unrecoverable error. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received
     2121                           by a proxy, the proxy <em class="bcp14">MUST</em> close the connection to the server, discard the received response, and send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response to the client. If this is a response message received by a user agent, the
     2122                           user agent <em class="bcp14">MUST</em> close the connection to the server and discard the received response.
     2123                        </p>
     2124                     </li>
     2125                     <li>
     2126                        <p>If a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field is present without <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, its decimal value defines the expected message body length in octets. If the sender
     2127                           closes the connection or the recipient times out before the indicated number of octets
     2128                           are received, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and close the connection.
     2129                        </p>
     2130                     </li>
     2131                     <li>
     2132                        <p>If this is a request message and none of the above are true, then the message body
     2133                           length is zero (no message body is present).
     2134                        </p>
     2135                     </li>
     2136                     <li>
     2137                        <p>Otherwise, this is a response message without a declared message body length, so the
     2138                           message body length is determined by the number of octets received prior to the server
     2139                           closing the connection.
     2140                        </p>
     2141                     </li>
     2142                  </ol>
     2143               </div>
     2144               <div id="rfc.section.3.3.3.p.3">
     2145                  <p>Since there is no way to distinguish a successfully completed, close-delimited message
     2146                     from a partially received message interrupted by network failure, a server <em class="bcp14">SHOULD</em> generate encoding or length-delimited messages whenever possible. The close-delimiting
     2147                     feature exists primarily for backwards compatibility with HTTP/1.0.
     2148                  </p>
     2149               </div>
     2150               <div id="rfc.section.3.3.3.p.4">
     2151                  <p>A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
     2152                  </p>
     2153               </div>
     2154               <div id="rfc.section.3.3.3.p.5">
     2155                  <p>Unless a transfer coding other than chunked has been applied, a client that sends
     2156                     a request containing a message body <em class="bcp14">SHOULD</em> use a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if the message body length is known in advance, rather than the chunked
     2157                     transfer coding, since some existing services respond to chunked with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked transfer coding. This is typically
     2158                     because such services are implemented via a gateway that requires a content-length
     2159                     in advance of being called and the server is unable or unwilling to buffer the entire
     2160                     request before processing.
     2161                  </p>
     2162               </div>
     2163               <div id="rfc.section.3.3.3.p.6">
     2164                  <p>A user agent that sends a request containing a message body <em class="bcp14">MUST</em> send a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests;
     2165                     such knowledge can be in the form of specific user configuration or by remembering
     2166                     the version of a prior received response.
     2167                  </p>
     2168               </div>
     2169               <div id="rfc.section.3.3.3.p.7">
     2170                  <p>If the final response to the last request on a connection has been completely received
     2171                     and there remains additional data to read, a user agent <em class="bcp14">MAY</em> discard the remaining data or attempt to determine if that data belongs as part of
     2172                     the prior response body, which might be the case if the prior message's Content-Length
     2173                     value is incorrect. A client <em class="bcp14">MUST NOT</em> process, cache, or forward such extra data as a separate response, since such behavior
     2174                     would be vulnerable to cache poisoning.
     2175                  </p>
     2176               </div>
    16152177            </div>
    16162178         </div>
    16172179         <div id="incomplete.messages">
    16182180            <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a href="#incomplete.messages">Handling Incomplete Messages</a></h2>
    1619             <p id="rfc.section.3.4.p.1">A server that receives an incomplete request message, usually due to a canceled request or a triggered timeout exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection.
    1620             </p>
    1621             <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding
    1622                a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
    1623             </p>
    1624             <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might
    1625                rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;
    1626                the client might need to repeat the request in order to determine what action to take next.
    1627             </p>
    1628             <p id="rfc.section.3.4.p.4">A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has
    1629                not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response
    1630                that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection and, thus, is considered
    1631                complete regardless of the number of message body octets received, provided that the header section was received intact.
    1632             </p>
     2181            <div id="rfc.section.3.4.p.1">
     2182               <p>A server that receives an incomplete request message, usually due to a canceled request
     2183                  or a triggered timeout exception, <em class="bcp14">MAY</em> send an error response prior to closing the connection.
     2184               </p>
     2185            </div>
     2186            <div id="rfc.section.3.4.p.2">
     2187               <p>A client that receives an incomplete response message, which can occur when a connection
     2188                  is closed prematurely or when decoding a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are
     2189                  defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
     2190               </p>
     2191            </div>
     2192            <div id="rfc.section.3.4.p.3">
     2193               <p>If a response terminates in the middle of the header section (before the empty line
     2194                  is received) and the status code might rely on header fields to convey the full meaning
     2195                  of the response, then the client cannot assume that meaning has been conveyed; the
     2196                  client might need to repeat the request in order to determine what action to take
     2197                  next.
     2198               </p>
     2199            </div>
     2200            <div id="rfc.section.3.4.p.4">
     2201               <p>A message body that uses the chunked transfer coding is incomplete if the zero-sized
     2202                  chunk that terminates the encoding has not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the
     2203                  value given by Content-Length. A response that has neither chunked transfer coding
     2204                  nor Content-Length is terminated by closure of the connection and, thus, is considered
     2205                  complete regardless of the number of message body octets received, provided that the
     2206                  header section was received intact.
     2207               </p>
     2208            </div>
    16332209         </div>
    16342210         <div id="message.robustness">
    16352211            <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a href="#message.robustness">Message Parsing Robustness</a></h2>
    1636             <p id="rfc.section.3.5.p.1">Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server
    1637                applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then
    1638                the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length.
    1639             </p>
    1640             <p id="rfc.section.3.5.p.2">In the interest of robustness, a server that is expecting to receive and parse a request-line <em class="bcp14">SHOULD</em> ignore at least one empty line (CRLF) received prior to the request-line.
    1641             </p>
    1642             <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR.
    1643             </p>
    1644             <p id="rfc.section.3.5.p.4">Although the request-line and status-line grammar rules require that each of the component elements be separated by a single
    1645                SP octet, recipients <em class="bcp14">MAY</em> instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator, treat any form of whitespace as
    1646                the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets:
    1647                SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can result in security vulnerabilities if there are multiple
    1648                recipients of the message and each has its own unique interpretation of robustness (see <a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>).
    1649             </p>
    1650             <p id="rfc.section.3.5.p.5">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request
    1651                message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed
    1652                above, the server <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response.
    1653             </p>
     2212            <div id="rfc.section.3.5.p.1">
     2213               <p>Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request
     2214                  as a workaround for some early server applications that failed to read message body
     2215                  content that was not terminated by a line-ending. An HTTP/1.1 user agent <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message
     2216                  body with a line-ending is desired, then the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length.
     2217               </p>
     2218            </div>
     2219            <div id="rfc.section.3.5.p.2">
     2220               <p>In the interest of robustness, a server that is expecting to receive and parse a request-line <em class="bcp14">SHOULD</em> ignore at least one empty line (CRLF) received prior to the request-line.
     2221               </p>
     2222            </div>
     2223            <div id="rfc.section.3.5.p.3">
     2224               <p>Although the line terminator for the start-line and header fields is the sequence
     2225                  CRLF, a recipient <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR.
     2226               </p>
     2227            </div>
     2228            <div id="rfc.section.3.5.p.4">
     2229               <p>Although the request-line and status-line grammar rules require that each of the component
     2230                  elements be separated by a single SP octet, recipients <em class="bcp14">MAY</em> instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator,
     2231                  treat any form of whitespace as the SP separator while ignoring preceding or trailing
     2232                  whitespace; such whitespace includes one or more of the following octets: SP, HTAB,
     2233                  VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can result in security
     2234                  vulnerabilities if there are multiple recipients of the message and each has its own
     2235                  unique interpretation of robustness (see <a href="#request.smuggling" title="Request Smuggling">Section&nbsp;9.5</a>).
     2236               </p>
     2237            </div>
     2238            <div id="rfc.section.3.5.p.5">
     2239               <p>When a server listening only for HTTP request messages, or processing what appears
     2240                  from the start-line to be an HTTP request message, receives a sequence of octets that
     2241                  does not match the HTTP-message grammar aside from the robustness exceptions listed
     2242                  above, the server <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response.
     2243               </p>
     2244            </div>
    16542245         </div>
    16552246      </div>
    16562247      <div id="transfer.codings">
    16572248         <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#transfer.codings">Transfer Codings</a></h1>
    1658          <p id="rfc.section.4.p.1">Transfer coding names are used to indicate an encoding transformation that has been, can be, or might need to be applied to
    1659             a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer
    1660             coding is a property of the message rather than a property of the representation that is being transferred.
    1661          </p>
    1662          <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>    = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>
     2249         <div id="rfc.section.4.p.1">
     2250            <p>Transfer coding names are used to indicate an encoding transformation that has been,
     2251               can be, or might need to be applied to a payload body in order to ensure "safe transport"
     2252               through the network. This differs from a content coding in that the transfer coding
     2253               is a property of the message rather than a property of the representation that is
     2254               being transferred.
     2255            </p>
     2256         </div>
     2257         <div id="rfc.figure.u.29"><pre class="inline"><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>    = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>
    16632258                     / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;4.2.1</a>
    16642259                     / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>
     
    16662261                     / <a href="#transfer.codings" class="smpl">transfer-extension</a>
    16672262  <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> )
    1668 </pre><div id="rule.parameter">
    1669             <p id="rfc.section.4.p.3"> Parameters are in the form of a name or name=value pair.</p>
    1670          </div>
    1671          <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.58"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.token.separators" class="smpl">token</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> ( <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> )
    1672 </pre><p id="rfc.section.4.p.5">All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined
    1673             in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;8.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>) header fields.
    1674          </p>
     2263</pre></div>
     2264         <div id="rule.parameter">
     2265            <div id="rfc.section.4.p.2">
     2266               <p> Parameters are in the form of a name or name=value pair.</p>
     2267            </div>
     2268         </div>
     2269         <div id="rfc.figure.u.30"><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.token.separators" class="smpl">token</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> ( <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> )
     2270</pre></div>
     2271         <div id="rfc.section.4.p.3">
     2272            <p>All transfer-coding names are case-insensitive and ought to be registered within the
     2273               HTTP Transfer Coding registry, as defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;8.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>) header fields.
     2274            </p>
     2275         </div>
    16752276         <div id="chunked.encoding">
    1676             <div id="rfc.iref.c.9"></div>
    16772277            <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a></h2>
    1678             <p id="rfc.section.4.1.p.1">The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator,
    1679                followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited
    1680                buffers, which enables the sender to retain connection persistence and the recipient to know when it has received the entire
    1681                message.
    1682             </p>
    1683             <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span>  <a href="#chunked.encoding" class="smpl">chunked-body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
     2278            <div id="rfc.section.4.1.p.1">
     2279               <p>The chunked transfer coding wraps the payload body in order to transfer it as a series
     2280                  of chunks, each with its own size indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. Chunked enables content streams of unknown size
     2281                  to be transferred as a sequence of length-delimited buffers, which enables the sender
     2282                  to retain connection persistence and the recipient to know when it has received the
     2283                  entire message.
     2284               </p>
     2285            </div>
     2286            <div id="rfc.figure.u.31"><pre class="inline"><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>  <a href="#chunked.encoding" class="smpl">chunked-body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
    16842287                   <a href="#chunked.encoding" class="smpl">last-chunk</a>
    16852288                   <a href="#chunked.trailer.part" class="smpl">trailer-part</a>
     
    16922295 
    16932296  <a href="#chunked.encoding" class="smpl">chunk-data</a>     = 1*<a href="#core.rules" class="smpl">OCTET</a> ; a sequence of chunk-size octets
    1694 </pre><p id="rfc.section.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked transfer coding
    1695                is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer, and finally terminated by
    1696                an empty line.
    1697             </p>
    1698             <p id="rfc.section.4.1.p.4">A recipient <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding.
    1699             </p>
     2297</pre></div>
     2298            <div id="rfc.section.4.1.p.2">
     2299               <p>The chunk-size field is a string of hex digits indicating the size of the chunk-data
     2300                  in octets. The chunked transfer coding is complete when a chunk with a chunk-size
     2301                  of zero is received, possibly followed by a trailer, and finally terminated by an
     2302                  empty line.
     2303               </p>
     2304            </div>
     2305            <div id="rfc.section.4.1.p.3">
     2306               <p>A recipient <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding.
     2307               </p>
     2308            </div>
    17002309            <div id="chunked.extension">
    17012310               <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;<a href="#chunked.extension">Chunk Extensions</a></h3>
    1702                <p id="rfc.section.4.1.1.p.1">The chunked encoding allows each chunk to include zero or more chunk extensions, immediately following the <a href="#chunked.encoding" class="smpl">chunk-size</a>, for the sake of supplying per-chunk metadata (such as a signature or hash), mid-message control information, or randomization
    1703                   of message body size.
    1704                </p>
    1705                <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  <a href="#chunked.extension" class="smpl">chunk-ext</a>      = *( ";" <a href="#chunked.extension" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.extension" class="smpl">chunk-ext-val</a> ] )
     2311               <div id="rfc.section.4.1.1.p.1">
     2312                  <p>The chunked encoding allows each chunk to include zero or more chunk extensions, immediately
     2313                     following the <a href="#chunked.encoding" class="smpl">chunk-size</a>, for the sake of supplying per-chunk metadata (such as a signature or hash), mid-message
     2314                     control information, or randomization of message body size.
     2315                  </p>
     2316               </div>
     2317               <div id="rfc.figure.u.32"><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span>  <a href="#chunked.extension" class="smpl">chunk-ext</a>      = *( ";" <a href="#chunked.extension" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.extension" class="smpl">chunk-ext-val</a> ] )
    17062318
    17072319  <a href="#chunked.extension" class="smpl">chunk-ext-name</a> = <a href="#rule.token.separators" class="smpl">token</a>
    17082320  <a href="#chunked.extension" class="smpl">chunk-ext-val</a>  = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a>
    1709 </pre><p id="rfc.section.4.1.1.p.3">The chunked encoding is specific to each connection and is likely to be removed or recoded by each recipient (including intermediaries)
    1710                   before any higher-level application would have a chance to inspect the extensions. Hence, use of chunk extensions is generally
    1711                   limited to specialized HTTP services such as "long polling" (where client and server can have shared expectations regarding
    1712                   the use of chunk extensions) or for padding within an end-to-end secured connection.
    1713                </p>
    1714                <p id="rfc.section.4.1.1.p.4">A recipient <em class="bcp14">MUST</em> ignore unrecognized chunk extensions. A server ought to limit the total length of chunk extensions received in a request to
    1715                   an amount reasonable for the services provided, in the same way that it applies length limitations and timeouts for other
    1716                   parts of a message, and generate an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> response if that amount is exceeded.
    1717                </p>
     2321</pre></div>
     2322               <div id="rfc.section.4.1.1.p.2">
     2323                  <p>The chunked encoding is specific to each connection and is likely to be removed or
     2324                     recoded by each recipient (including intermediaries) before any higher-level application
     2325                     would have a chance to inspect the extensions. Hence, use of chunk extensions is generally
     2326                     limited to specialized HTTP services such as "long polling" (where client and server
     2327                     can have shared expectations regarding the use of chunk extensions) or for padding
     2328                     within an end-to-end secured connection.
     2329                  </p>
     2330               </div>
     2331               <div id="rfc.section.4.1.1.p.3">
     2332                  <p>A recipient <em class="bcp14">MUST</em> ignore unrecognized chunk extensions. A server ought to limit the total length of
     2333                     chunk extensions received in a request to an amount reasonable for the services provided,
     2334                     in the same way that it applies length limitations and timeouts for other parts of
     2335                     a message, and generate an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> response if that amount is exceeded.
     2336                  </p>
     2337               </div>
    17182338            </div>
    17192339            <div id="chunked.trailer.part">
    17202340               <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a href="#chunked.trailer.part">Chunked Trailer Part</a></h3>
    1721                <p id="rfc.section.4.1.2.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that
    1722                   might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing
    1723                   status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's
    1724                   header section.
    1725                </p>
    1726                <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span>  <a href="#chunked.trailer.part" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
    1727 </pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field necessary for message framing (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and <a href="#header.content-length" class="smpl">Content-Length</a>), routing (e.g., <a href="#header.host" class="smpl">Host</a>), request modifiers (e.g., controls and conditionals in <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 5</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), authentication (e.g., see <a href="#RFC7235" id="rfc.xref.RFC7235.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a> and <a href="#RFC6265" id="rfc.xref.RFC6265.3"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>), response control data (e.g., see <a href="p2-semantics.html#response.control.data" title="Control Data">Section 7.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), or determining how to process the payload (e.g., <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a>, and <a href="#header.trailer" class="smpl">Trailer</a>).
    1728                </p>
    1729                <p id="rfc.section.4.1.2.p.4">When a chunked message containing a non-empty trailer is received, the recipient <em class="bcp14">MAY</em> process the fields (aside from those forbidden above) as if they were appended to the message's header section. A recipient <em class="bcp14">MUST</em> ignore (or consider as an error) any fields that are forbidden to be sent in a trailer, since processing them as if they were
    1730                   present in the header section might bypass external security filters.
    1731                </p>
    1732                <p id="rfc.section.4.1.2.p.5">Unless the request includes a <a href="#header.te" class="smpl">TE</a> header field indicating "trailers" is acceptable, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.3</a>, a server <em class="bcp14">SHOULD NOT</em> generate trailer fields that it believes are necessary for the user agent to receive. Without a TE containing "trailers",
    1733                   the server ought to assume that the trailer fields might be silently discarded along the path to the user agent. This requirement
    1734                   allows intermediaries to forward a de-chunked message to an HTTP/1.0 recipient without buffering the entire response.
    1735                </p>
     2341               <div id="rfc.section.4.1.2.p.1">
     2342                  <p>A trailer allows the sender to include additional fields at the end of a chunked message
     2343                     in order to supply metadata that might be dynamically generated while the message
     2344                     body is sent, such as a message integrity check, digital signature, or post-processing
     2345                     status. The trailer fields are identical to header fields, except they are sent in
     2346                     a chunked trailer instead of the message's header section.
     2347                  </p>
     2348               </div>
     2349               <div id="rfc.figure.u.33"><pre class="inline"><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span>  <a href="#chunked.trailer.part" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
     2350</pre></div>
     2351               <div id="rfc.section.4.1.2.p.2">
     2352                  <p>A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field necessary for message framing (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and <a href="#header.content-length" class="smpl">Content-Length</a>), routing (e.g., <a href="#header.host" class="smpl">Host</a>), request modifiers (e.g., controls and conditionals in <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 5</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), authentication (e.g., see <a href="#RFC7235" id="rfc.xref.RFC7235.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a> and <a href="#RFC6265" id="rfc.xref.RFC6265.3"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>), response control data (e.g., see <a href="p2-semantics.html#response.control.data" title="Control Data">Section 7.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), or determining how to process the payload (e.g., <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a>, and <a href="#header.trailer" class="smpl">Trailer</a>).
     2353                  </p>
     2354               </div>
     2355               <div id="rfc.section.4.1.2.p.3">
     2356                  <p>When a chunked message containing a non-empty trailer is received, the recipient <em class="bcp14">MAY</em> process the fields (aside from those forbidden above) as if they were appended to
     2357                     the message's header section. A recipient <em class="bcp14">MUST</em> ignore (or consider as an error) any fields that are forbidden to be sent in a trailer,
     2358                     since processing them as if they were present in the header section might bypass external
     2359                     security filters.
     2360                  </p>
     2361               </div>
     2362               <div id="rfc.section.4.1.2.p.4">
     2363                  <p>Unless the request includes a <a href="#header.te" class="smpl">TE</a> header field indicating "trailers" is acceptable, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.3</a>, a server <em class="bcp14">SHOULD NOT</em> generate trailer fields that it believes are necessary for the user agent to receive.
     2364                     Without a TE containing "trailers", the server ought to assume that the trailer fields
     2365                     might be silently discarded along the path to the user agent. This requirement allows
     2366                     intermediaries to forward a de-chunked message to an HTTP/1.0 recipient without buffering
     2367                     the entire response.
     2368                  </p>
     2369               </div>
    17362370            </div>
    17372371            <div id="decoding.chunked">
    17382372               <h3 id="rfc.section.4.1.3"><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;<a href="#decoding.chunked">Decoding Chunked</a></h3>
    1739                <p id="rfc.section.4.1.3.p.1">A process for decoding the chunked transfer coding can be represented in pseudo-code as:</p>
    1740                <div id="rfc.figure.u.34"></div><pre class="text">  length := 0
     2373               <div id="rfc.section.4.1.3.p.1">
     2374                  <p>A process for decoding the chunked transfer coding can be represented in pseudo-code
     2375                     as:
     2376                  </p>
     2377               </div>
     2378               <div id="rfc.figure.u.34"><pre class="text">  length := 0
    17412379  read chunk-size, chunk-ext (if any), and CRLF
    17422380  while (chunk-size &gt; 0) {
     
    17572395  Remove Trailer from existing header fields
    17582396</pre></div>
     2397            </div>
    17592398         </div>
    17602399         <div id="compression.codings">
    17612400            <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#compression.codings">Compression Codings</a></h2>
    1762             <p id="rfc.section.4.2.p.1">The codings defined below can be used to compress the payload of a message.</p>
     2401            <div id="rfc.section.4.2.p.1">
     2402               <p>The codings defined below can be used to compress the payload of a message.</p>
     2403            </div>
    17632404            <div id="compress.coding">
    1764                <div id="rfc.iref.c.10"></div>
    17652405               <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a href="#compress.coding">Compress Coding</a></h3>
    1766                <p id="rfc.section.4.2.1.p.1">The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding <a href="#Welch" id="rfc.xref.Welch.1"><cite title="A Technique for High-Performance Data Compression">[Welch]</cite></a> that is commonly produced by the UNIX file compression program "compress". A recipient <em class="bcp14">SHOULD</em> consider "x-compress" to be equivalent to "compress".
    1767                </p>
     2406               <div id="rfc.section.4.2.1.p.1">
     2407                  <p>The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding <a href="#Welch" id="rfc.xref.Welch.1"><cite title="A Technique for High-Performance Data Compression">[Welch]</cite></a> that is commonly produced by the UNIX file compression program "compress". A recipient <em class="bcp14">SHOULD</em> consider "x-compress" to be equivalent to "compress".
     2408                  </p>
     2409               </div>
    17682410            </div>
    17692411            <div id="deflate.coding">
    1770                <div id="rfc.iref.d.3"></div>
    17712412               <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a href="#deflate.coding">Deflate Coding</a></h3>
    1772                <p id="rfc.section.4.2.2.p.1">The "deflate" coding is a "zlib" data format <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> containing a "deflate" compressed data stream <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a> that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
    1773                </p>
    1774                <div class="note" id="rfc.section.4.2.2.p.2">
    1775                   <p><b>Note:</b> Some non-conformant implementations send the "deflate" compressed data without the zlib wrapper.
    1776                   </p>
     2413               <div id="rfc.section.4.2.2.p.1">
     2414                  <p>The "deflate" coding is a "zlib" data format <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> containing a "deflate" compressed data stream <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a> that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman
     2415                     coding.
     2416                  </p>
     2417               </div>
     2418               <div class="note">
     2419                  <div id="rfc.section.4.2.2.p.2">
     2420                     <p><b>Note:</b> Some non-conformant implementations send the "deflate" compressed data without the
     2421                        zlib wrapper.
     2422                     </p>
     2423                  </div>
    17772424               </div>
    17782425            </div>
    17792426            <div id="gzip.coding">
    1780                <div id="rfc.iref.g.72"></div>
    17812427               <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a href="#gzip.coding">Gzip Coding</a></h3>
    1782                <p id="rfc.section.4.2.3.p.1">The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file
    1783                   compression program <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. A recipient <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip".
    1784                </p>
     2428               <div id="rfc.section.4.2.3.p.1">
     2429                  <p>The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that
     2430                     is commonly produced by the gzip file compression program <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. A recipient <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip".
     2431                  </p>
     2432               </div>
    17852433            </div>
    17862434         </div>
    17872435         <div id="header.te">
    1788             <div id="rfc.iref.t.4"></div>
    17892436            <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#header.te">TE</a></h2>
    1790             <p id="rfc.section.4.3.p.1">The "TE" header field in a request indicates what transfer codings, besides chunked, the client is willing to accept in response,
    1791                and whether or not the client is willing to accept trailer fields in a chunked transfer coding.
    1792             </p>
    1793             <p id="rfc.section.4.3.p.2">The TE field-value consists of a comma-separated list of transfer coding names, each allowing for optional parameters (as
    1794                described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), and/or the keyword "trailers". A client <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.
    1795             </p>
    1796             <div id="rfc.figure.u.35"></div><pre class="inline"><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="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     2437            <div id="rfc.section.4.3.p.1">
     2438               <p>The "TE" header field in a request indicates what transfer codings, besides chunked,
     2439                  the client is willing to accept in response, and whether or not the client is willing
     2440                  to accept trailer fields in a chunked transfer coding.
     2441               </p>
     2442            </div>
     2443            <div id="rfc.section.4.3.p.2">
     2444               <p>The TE field-value consists of a comma-separated list of transfer coding names, each
     2445                  allowing for optional parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), and/or the keyword "trailers". A client <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1
     2446                  recipients.
     2447               </p>
     2448            </div>
     2449            <div id="rfc.figure.u.35"><pre class="inline"><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>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
    17972450  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-coding</a> [ <a href="#header.te" class="smpl">t-ranking</a> ] )
    17982451  <a href="#header.te" class="smpl">t-ranking</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#header.te" class="smpl">rank</a>
    17992452  <a href="#header.te" class="smpl">rank</a>      = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    18002453             / ( "1" [ "." 0*3("0") ] )
    1801 </pre><p id="rfc.section.4.3.p.4">Three examples of TE use are below.</p>
    1802             <div id="rfc.figure.u.36"></div><pre class="text">  TE: deflate
     2454</pre></div>
     2455            <div id="rfc.section.4.3.p.3">
     2456               <p>Three examples of TE use are below.</p>
     2457            </div>
     2458            <div id="rfc.figure.u.36"><pre class="text">  TE: deflate
    18032459  TE:
    18042460  TE: trailers, deflate;q=0.5
    1805 </pre><p id="rfc.section.4.3.p.6">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer
    1806                coding, as defined in <a href="#chunked.trailer.part" title="Chunked Trailer Part">Section&nbsp;4.1.2</a>, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that either: (a) all downstream
    1807                clients are willing to accept trailer fields in the forwarded response; or, (b) the intermediary will attempt to buffer the
    1808                response on behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response
    1809                such that an intermediary can be assured of buffering the entire response.
    1810             </p>
    1811             <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation
    1812                fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
    1813                a value of 0 means "not acceptable".
    1814             </p>
    1815             <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer coding is chunked. A message with
    1816                no transfer coding is always acceptable.
    1817             </p>
    1818             <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.
    1819             </p>
     2461</pre></div>
     2462            <div id="rfc.section.4.3.p.4">
     2463               <p>The presence of the keyword "trailers" indicates that the client is willing to accept
     2464                  trailer fields in a chunked transfer coding, as defined in <a href="#chunked.trailer.part" title="Chunked Trailer Part">Section&nbsp;4.1.2</a>, on behalf of itself and any downstream clients. For requests from an intermediary,
     2465                  this implies that either: (a) all downstream clients are willing to accept trailer
     2466                  fields in the forwarded response; or, (b) the intermediary will attempt to buffer
     2467                  the response on behalf of downstream recipients. Note that HTTP/1.1 does not define
     2468                  any means to limit the size of a chunked response such that an intermediary can be
     2469                  assured of buffering the entire response.
     2470               </p>
     2471            </div>
     2472            <div id="rfc.section.4.3.p.5">
     2473               <p>When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to
     2474                  the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least
     2475                  preferred and 1 is the most preferred; a value of 0 means "not acceptable".
     2476               </p>
     2477            </div>
     2478            <div id="rfc.section.4.3.p.6">
     2479               <p>If the TE field-value is empty or if no TE field is present, the only acceptable transfer
     2480                  coding is chunked. A message with no transfer coding is always acceptable.
     2481               </p>
     2482            </div>
     2483            <div id="rfc.section.4.3.p.7">
     2484               <p>Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do
     2485                  not support its semantics.
     2486               </p>
     2487            </div>
    18202488         </div>
    18212489         <div id="header.trailer">
    1822             <div id="rfc.iref.t.5"></div>
    18232490            <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#header.trailer">Trailer</a></h2>
    1824             <p id="rfc.section.4.4.p.1">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in
    1825                the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to
    1826                prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed
    1827                and the recipient wishes to confirm an integrity check on the fly.
    1828             </p>
    1829             <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    1830 </pre></div>
     2491            <div id="rfc.section.4.4.p.1">
     2492               <p>When a message includes a message body encoded with the chunked transfer coding and
     2493                  the sender desires to send metadata in the form of trailer fields at the end of the
     2494                  message, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the
     2495                  trailers. This allows the recipient to prepare for receipt of that metadata before
     2496                  it starts processing the body, which is useful if the message is being streamed and
     2497                  the recipient wishes to confirm an integrity check on the fly.
     2498               </p>
     2499            </div>
     2500            <div id="rfc.figure.u.37"><pre class="inline"><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
     2501</pre></div>
     2502         </div>
    18312503      </div>
    18322504      <div id="message.routing">
    18332505         <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#message.routing">Message Routing</a></h1>
    1834          <p id="rfc.section.5.p.1">HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration,
    1835             and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain
    1836             back to the client.
    1837          </p>
     2506         <div id="rfc.section.5.p.1">
     2507            <p>HTTP request message routing is determined by each client based on the target resource,
     2508               the client's proxy configuration, and establishment or reuse of an inbound connection.
     2509               The corresponding response routing follows the same connection chain back to the client.
     2510            </p>
     2511         </div>
    18382512         <div id="target-resource">
    1839             <div id="rfc.iref.t.6"></div>
    1840             <div id="rfc.iref.t.7"></div>
    18412513            <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#target-resource">Identifying a Target Resource</a></h2>
    1842             <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases,
    1843                communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification
    1844                mechanism and configuration techniques as general-purpose Web browsers.
    1845             </p>
    1846             <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1847                are defined in <a href="#RFC7231" id="rfc.xref.RFC7231.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
    1848                processing (<a href="#RFC3986" id="rfc.xref.RFC3986.21"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    1849             </p>
     2514            <div id="rfc.section.5.1.p.1">
     2515               <p>HTTP is used in a wide variety of applications, ranging from general-purpose computers
     2516                  to home appliances. In some cases, communication options are hard-coded in a client's
     2517                  configuration. However, most HTTP clients rely on the same resource identification
     2518                  mechanism and configuration techniques as general-purpose Web browsers.
     2519               </p>
     2520            </div>
     2521            <div id="rfc.section.5.1.p.2">
     2522               <p>HTTP communication is initiated by a user agent for some purpose. The purpose is a
     2523                  combination of request semantics, which are defined in <a href="#RFC7231" id="rfc.xref.RFC7231.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment
     2524                  identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.21"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="https://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
     2525               </p>
     2526            </div>
    18502527         </div>
    18512528         <div id="connecting.inbound">
    18522529            <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a href="#connecting.inbound">Connecting Inbound</a></h2>
    1853             <p id="rfc.section.5.2.p.1">Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired
    1854                semantics and, if so, where that request is to be directed.
    1855             </p>
    1856             <p id="rfc.section.5.2.p.2">If the client has a cache <a href="#RFC7234" id="rfc.xref.RFC7234.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a> and the request can be satisfied by it, then the request is usually directed there first.
    1857             </p>
    1858             <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy
    1859                is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching,
    1860                selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy
    1861                is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy.
    1862             </p>
    1863             <p id="rfc.section.5.2.p.4">If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to
    1864                connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and
    1865                defined by its associated specification, similar to how this specification defines origin server access for resolution of
    1866                the "http" (<a href="#http.uri" title="http URI Scheme">Section&nbsp;2.7.1</a>) and "https" (<a href="#https.uri" title="https URI Scheme">Section&nbsp;2.7.2</a>) schemes.
    1867             </p>
    1868             <p id="rfc.section.5.2.p.5">HTTP requirements regarding connection management are defined in <a href="#connection.management" title="Connection Management">Section&nbsp;6</a>.
    1869             </p>
     2530            <div id="rfc.section.5.2.p.1">
     2531               <p>Once the target URI is determined, a client needs to decide whether a network request
     2532                  is necessary to accomplish the desired semantics and, if so, where that request is
     2533                  to be directed.
     2534               </p>
     2535            </div>
     2536            <div id="rfc.section.5.2.p.2">
     2537               <p>If the client has a cache <a href="#RFC7234" id="rfc.xref.RFC7234.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a> and the request can be satisfied by it, then the request is usually directed there
     2538                  first.
     2539               </p>
     2540            </div>
     2541            <div id="rfc.section.5.2.p.3">
     2542               <p>If the request is not satisfied by a cache, then a typical client will check its configuration
     2543                  to determine whether a proxy is to be used to satisfy the request. Proxy configuration
     2544                  is implementation-dependent, but is often based on URI prefix matching, selective
     2545                  authority matching, or both, and the proxy itself is usually identified by an "http"
     2546                  or "https" URI. If a proxy is applicable, the client connects inbound by establishing
     2547                  (or reusing) a connection to that proxy.
     2548               </p>
     2549            </div>
     2550            <div id="rfc.section.5.2.p.4">
     2551               <p>If no proxy is applicable, a typical client will invoke a handler routine, usually
     2552                  specific to the target URI's scheme, to connect directly to an authority for the target
     2553                  resource. How that is accomplished is dependent on the target URI scheme and defined
     2554                  by its associated specification, similar to how this specification defines origin
     2555                  server access for resolution of the "http" (<a href="#http.uri" title="http URI Scheme">Section&nbsp;2.7.1</a>) and "https" (<a href="#https.uri" title="https URI Scheme">Section&nbsp;2.7.2</a>) schemes.
     2556               </p>
     2557            </div>
     2558            <div id="rfc.section.5.2.p.5">
     2559               <p>HTTP requirements regarding connection management are defined in <a href="#connection.management" title="Connection Management">Section&nbsp;6</a>.
     2560               </p>
     2561            </div>
    18702562         </div>
    18712563         <div id="request-target">
    18722564            <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a href="#request-target">Request Target</a></h2>
    1873             <p id="rfc.section.5.3.p.1">Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on
    1874                both the method being requested and whether the request is to a proxy.
    1875             </p>
    1876             <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span>  <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>
     2565            <div id="rfc.section.5.3.p.1">
     2566               <p>Once an inbound connection is obtained, the client sends an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) with a request-target derived from the target URI. There are four distinct formats
     2567                  for the request-target, depending on both the method being requested and whether the
     2568                  request is to a proxy.
     2569               </p>
     2570            </div>
     2571            <div id="rfc.figure.u.38"><pre class="inline"><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span>  <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>
    18772572                 / <a href="#absolute-form" class="smpl">absolute-form</a>
    18782573                 / <a href="#authority-form" class="smpl">authority-form</a>
    18792574                 / <a href="#asterisk-form" class="smpl">asterisk-form</a>
    1880 </pre><div id="origin-form">
    1881                <div id="rfc.iref.o.3"></div>
     2575</pre></div>
     2576            <div id="origin-form">
    18822577               <h3 id="rfc.section.5.3.1"><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;<a href="#origin-form">origin-form</a></h3>
    1883                <p id="rfc.section.5.3.1.p.1">The most common form of request-target is the <dfn>origin-form</dfn>.
    1884                </p>
    1885                <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.84"></span>  <a href="#origin-form" class="smpl">origin-form</a>    = <a href="#uri" class="smpl">absolute-path</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    1886 </pre><p id="rfc.section.5.3.1.p.3">When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below),
    1887                   a client <em class="bcp14">MUST</em> send only the absolute path and query components of the target URI as the request-target. If the target URI's path component
    1888                   is empty, the client <em class="bcp14">MUST</em> send "/" as the path within the origin-form of request-target. A <a href="#header.host" class="smpl">Host</a> header field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;5.4</a>.
    1889                </p>
    1890                <p id="rfc.section.5.3.1.p.4">For example, a client wishing to retrieve a representation of the resource identified as</p>
    1891                <div id="rfc.figure.u.40"></div><pre class="text">http://www.example.org/where?q=now
    1892 </pre><p id="rfc.section.5.3.1.p.6">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the
    1893                   lines:
    1894                </p>
    1895                <div id="rfc.figure.u.41"></div><pre class="text2">GET /where?q=now HTTP/1.1
     2578               <div id="rfc.section.5.3.1.p.1">
     2579                  <p>The most common form of request-target is the <dfn>origin-form</dfn>.
     2580                  </p>
     2581               </div>
     2582               <div id="rfc.figure.u.39"><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#origin-form" class="smpl">origin-form</a>    = <a href="#uri" class="smpl">absolute-path</a> [ "?" <a href="#uri" class="smpl">query</a> ]
     2583</pre></div>
     2584               <div id="rfc.section.5.3.1.p.2">
     2585                  <p>When making a request directly to an origin server, other than a CONNECT or server-wide
     2586                     OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send only the absolute path and query components of the target URI as the request-target.
     2587                     If the target URI's path component is empty, the client <em class="bcp14">MUST</em> send "/" as the path within the origin-form of request-target. A <a href="#header.host" class="smpl">Host</a> header field is also sent, as defined in <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;5.4</a>.
     2588                  </p>
     2589               </div>
     2590               <div id="rfc.section.5.3.1.p.3">
     2591                  <p>For example, a client wishing to retrieve a representation of the resource identified
     2592                     as
     2593                  </p>
     2594               </div>
     2595               <div id="rfc.figure.u.40"><pre class="text">http://www.example.org/where?q=now
     2596</pre></div>
     2597               <div id="rfc.section.5.3.1.p.4">
     2598                  <p>directly from the origin server would open (or reuse) a TCP connection to port 80
     2599                     of the host "www.example.org" and send the lines:
     2600                  </p>
     2601               </div>
     2602               <div id="rfc.figure.u.41"><pre class="text2">GET /where?q=now HTTP/1.1
    18962603Host: www.example.org
    1897 </pre><p id="rfc.section.5.3.1.p.8">followed by the remainder of the request message.</p>
     2604</pre></div>
     2605               <div id="rfc.section.5.3.1.p.5">
     2606                  <p>followed by the remainder of the request message.</p>
     2607               </div>
    18982608            </div>
    18992609            <div id="absolute-form">
    1900                <div id="rfc.iref.a.2"></div>
    19012610               <h3 id="rfc.section.5.3.2"><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;<a href="#absolute-form">absolute-form</a></h3>
    1902                <p id="rfc.section.5.3.2.p.1">When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send the target URI in <dfn>absolute-form</dfn> as the request-target.
    1903                </p>
    1904                <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.85"></span>  <a href="#absolute-form" class="smpl">absolute-form</a>  = <a href="#uri" class="smpl">absolute-URI</a>
    1905 </pre><p id="rfc.section.5.3.2.p.3">The proxy is requested to either service that request from a valid cache, if possible, or make the same request on the client's
    1906                   behalf to either the next inbound proxy server or directly to the origin server indicated by the request-target. Requirements
    1907                   on such "forwarding" of messages are defined in <a href="#message.forwarding" title="Message Forwarding">Section&nbsp;5.7</a>.
    1908                </p>
    1909                <p id="rfc.section.5.3.2.p.4">An example absolute-form of request-line would be:</p>
    1910                <div id="rfc.figure.u.43"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1911 </pre><p id="rfc.section.5.3.2.p.6">To allow for transition to the absolute-form for all requests in some future version of HTTP, a server <em class="bcp14">MUST</em> accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies.
    1912                </p>
     2611               <div id="rfc.section.5.3.2.p.1">
     2612                  <p>When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request
     2613                     (as detailed below), a client <em class="bcp14">MUST</em> send the target URI in <dfn>absolute-form</dfn> as the request-target.
     2614                  </p>
     2615               </div>
     2616               <div id="rfc.figure.u.42"><pre class="inline"><span id="rfc.iref.g.72"></span>  <a href="#absolute-form" class="smpl">absolute-form</a>  = <a href="#uri" class="smpl">absolute-URI</a>
     2617</pre></div>
     2618               <div id="rfc.section.5.3.2.p.2">
     2619                  <p>The proxy is requested to either service that request from a valid cache, if possible,
     2620                     or make the same request on the client's behalf to either the next inbound proxy server
     2621                     or directly to the origin server indicated by the request-target. Requirements on
     2622                     such "forwarding" of messages are defined in <a href="#message.forwarding" title="Message Forwarding">Section&nbsp;5.7</a>.
     2623                  </p>
     2624               </div>
     2625               <div id="rfc.section.5.3.2.p.3">
     2626                  <p>An example absolute-form of request-line would be:</p>
     2627               </div>
     2628               <div id="rfc.figure.u.43"><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     2629</pre></div>
     2630               <div id="rfc.section.5.3.2.p.4">
     2631                  <p>To allow for transition to the absolute-form for all requests in some future version
     2632                     of HTTP, a server <em class="bcp14">MUST</em> accept the absolute-form in requests, even though HTTP/1.1 clients will only send
     2633                     them in requests to proxies.
     2634                  </p>
     2635               </div>
    19132636            </div>
    19142637            <div id="authority-form">
    1915                <div id="rfc.iref.a.3"></div>
    19162638               <h3 id="rfc.section.5.3.3"><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;<a href="#authority-form">authority-form</a></h3>
    1917                <p id="rfc.section.5.3.3.p.1">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    1918                </p>
    1919                <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.86"></span>  <a href="#authority-form" class="smpl">authority-form</a> = <a href="#uri" class="smpl">authority</a>
    1920 </pre><p id="rfc.section.5.3.3.p.3">When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
    1921                </p>
    1922                <div id="rfc.figure.u.45"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    1923 </pre></div>
     2639               <div id="rfc.section.5.3.3.p.1">
     2640                  <p>The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
     2641                  </p>
     2642               </div>
     2643               <div id="rfc.figure.u.44"><pre class="inline"><span id="rfc.iref.g.73"></span>  <a href="#authority-form" class="smpl">authority-form</a> = <a href="#uri" class="smpl">authority</a>
     2644</pre></div>
     2645               <div id="rfc.section.5.3.3.p.2">
     2646                  <p>When making a CONNECT request to establish a tunnel through one or more proxies, a
     2647                     client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@"
     2648                     delimiter) as the request-target. For example,
     2649                  </p>
     2650               </div>
     2651               <div id="rfc.figure.u.45"><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
     2652</pre></div>
     2653            </div>
    19242654            <div id="asterisk-form">
    1925                <div id="rfc.iref.a.4"></div>
    19262655               <h3 id="rfc.section.5.3.4"><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;<a href="#asterisk-form">asterisk-form</a></h3>
    1927                <p id="rfc.section.5.3.4.p.1">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    1928                </p>
    1929                <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.87"></span>  <a href="#asterisk-form" class="smpl">asterisk-form</a>  = "*"
    1930 </pre><p id="rfc.section.5.3.4.p.3">When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    1931                   the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    1932                </p>
    1933                <div id="rfc.figure.u.47"></div><pre class="text2">OPTIONS * HTTP/1.1
    1934 </pre><p id="rfc.section.5.3.4.p.5">If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query
    1935                   component, then the last proxy on the request chain <em class="bcp14">MUST</em> send a request-target of "*" when it forwards the request to the indicated origin server.
    1936                </p>
    1937                <div id="rfc.figure.u.48"></div>
    1938                <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
    1939 </pre><div id="rfc.figure.u.49"></div>
    1940                <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
     2656               <div id="rfc.section.5.3.4.p.1">
     2657                  <p>The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
     2658                  </p>
     2659               </div>
     2660               <div id="rfc.figure.u.46"><pre class="inline"><span id="rfc.iref.g.74"></span>  <a href="#asterisk-form" class="smpl">asterisk-form</a>  = "*"
     2661</pre></div>
     2662               <div id="rfc.section.5.3.4.p.2">
     2663                  <p>When a client wishes to request OPTIONS for the server as a whole, as opposed to a
     2664                     specific named resource of that server, the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
     2665                  </p>
     2666               </div>
     2667               <div id="rfc.figure.u.47"><pre class="text2">OPTIONS * HTTP/1.1
     2668</pre></div>
     2669               <div id="rfc.section.5.3.4.p.3">
     2670                  <p>If a proxy receives an OPTIONS request with an absolute-form of request-target in
     2671                     which the URI has an empty path and no query component, then the last proxy on the
     2672                     request chain <em class="bcp14">MUST</em> send a request-target of "*" when it forwards the request to the indicated origin
     2673                     server.
     2674                  </p>
     2675               </div>
     2676               <div id="rfc.figure.u.48">
     2677                  <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1
     2678</pre></div>
     2679               <div id="rfc.figure.u.49">
     2680                  <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1
    19412681Host: www.example.org:8001
    19422682</pre><p>after connecting to port 8001 of host "www.example.org".</p>
     2683               </div>
    19432684            </div>
    19442685         </div>
    19452686         <div id="header.host">
    1946             <div id="rfc.iref.h.6"></div>
    19472687            <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a href="#header.host">Host</a></h2>
    1948             <p id="rfc.section.5.4.p.1">The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server
    1949                to distinguish among resources while servicing requests for multiple host names on a single IP address.
    1950             </p>
    1951             <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.88"></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>
    1952 </pre><p id="rfc.section.5.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 URI includes an authority component, then a client <em class="bcp14">MUST</em> send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@"
    1953                delimiter (<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 URI, then a client <em class="bcp14">MUST</em> send a Host header field with an empty field-value.
    1954             </p>
    1955             <p id="rfc.section.5.4.p.4">Since the Host field-value is critical information for handling a request, a user agent <em class="bcp14">SHOULD</em> generate Host as the first header field following the request-line.
    1956             </p>
    1957             <p id="rfc.section.5.4.p.5">For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    1958             <div id="rfc.figure.u.51"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
     2688            <div id="rfc.section.5.4.p.1">
     2689               <p>The "Host" header field in a request provides the host and port information from the
     2690                  target URI, enabling the origin server to distinguish among resources while servicing
     2691                  requests for multiple host names on a single IP address.
     2692               </p>
     2693            </div>
     2694            <div id="rfc.figure.u.50"><pre class="inline"><span id="rfc.iref.g.75"></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>
     2695</pre></div>
     2696            <div id="rfc.section.5.4.p.2">
     2697               <p>A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes
     2698                  an authority component, then a client <em class="bcp14">MUST</em> send a field-value for Host that is identical to that authority component, excluding
     2699                  any userinfo subcomponent and its "@" delimiter (<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 URI, then a client <em class="bcp14">MUST</em> send a Host header field with an empty field-value.
     2700               </p>
     2701            </div>
     2702            <div id="rfc.section.5.4.p.3">
     2703               <p>Since the Host field-value is critical information for handling a request, a user
     2704                  agent <em class="bcp14">SHOULD</em> generate Host as the first header field following the request-line.
     2705               </p>
     2706            </div>
     2707            <div id="rfc.section.5.4.p.4">
     2708               <p>For example, a GET request to the origin server for &lt;http://www.example.org/pub/WWW/&gt;
     2709                  would begin with:
     2710               </p>
     2711            </div>
     2712            <div id="rfc.figure.u.51"><pre class="text2">GET /pub/WWW/ HTTP/1.1
    19592713Host: www.example.org
    1960 </pre><p id="rfc.section.5.4.p.7">A client <em class="bcp14">MUST</em> send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the
    1961                Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
    1962             </p>
    1963             <p id="rfc.section.5.4.p.8">When a proxy receives a request with an absolute-form of request-target, 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. A proxy
    1964                that forwards such a request <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value.
    1965             </p>
    1966             <p id="rfc.section.5.4.p.9">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to
    1967                poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it
    1968                relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache,
    1969                without first verifying that the intercepted connection is targeting a valid IP address for that host.
    1970             </p>
    1971             <p id="rfc.section.5.4.p.10">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than
    1972                one Host header field or a Host header field with an invalid field-value.
    1973             </p>
     2714</pre></div>
     2715            <div id="rfc.section.5.4.p.5">
     2716               <p>A client <em class="bcp14">MUST</em> send a Host header field in an HTTP/1.1 request even if the request-target is in the
     2717                  absolute-form, since this allows the Host information to be forwarded through ancient
     2718                  HTTP/1.0 proxies that might not have implemented Host.
     2719               </p>
     2720            </div>
     2721            <div id="rfc.section.5.4.p.6">
     2722               <p>When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host
     2723                  information of the request-target. A proxy that forwards such a request <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward
     2724                  the received Host field-value.
     2725               </p>
     2726            </div>
     2727            <div id="rfc.section.5.4.p.7">
     2728               <p>Since the Host header field acts as an application-level routing mechanism, it is
     2729                  a frequent target for malware seeking to poison a shared cache or redirect a request
     2730                  to an unintended server. An interception proxy is particularly vulnerable if it relies
     2731                  on the Host field-value for redirecting requests to internal servers, or for use as
     2732                  a cache key in a shared cache, without first verifying that the intercepted connection
     2733                  is targeting a valid IP address for that host.
     2734               </p>
     2735            </div>
     2736            <div id="rfc.section.5.4.p.8">
     2737               <p>A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to
     2738                  any request message that contains more than one Host header field or a Host header
     2739                  field with an invalid field-value.
     2740               </p>
     2741            </div>
    19742742         </div>
    19752743         <div id="effective.request.uri">
    1976             <div id="rfc.iref.e.1"></div>
    19772744            <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a href="#effective.request.uri">Effective Request URI</a></h2>
    1978             <p id="rfc.section.5.5.p.1">Since the request-target often contains only part of the user agent's target URI, a server reconstructs the intended target
    1979                as an "<dfn>effective request URI</dfn>" to properly service the request. This reconstruction involves both the server's local configuration and information communicated
    1980                in the <a href="#request-target" class="smpl">request-target</a>, <a href="#header.host" class="smpl">Host</a> header field, and connection context.
    1981             </p>
    1982             <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p>
    1983             <p id="rfc.section.5.5.p.3">If the <a href="#request-target" class="smpl">request-target</a> is in <a href="#absolute-form" class="smpl">absolute-form</a>, the effective request URI is the same as the request-target. Otherwise, the effective request URI is constructed as follows:
    1984             </p>
    1985             <ul class="empty">
    1986                <li>If the server's configuration (or outbound gateway) provides a fixed URI <a href="#uri" class="smpl">scheme</a>, that scheme is used for the effective request URI. Otherwise, if the request is received over a TLS-secured TCP connection,
    1987                   the effective request URI's scheme is "https"; if not, the scheme is "http".
    1988                </li>
    1989                <li>If the server's configuration (or outbound gateway) provides a fixed URI <a href="#uri" class="smpl">authority</a> component, that authority is used for the effective request URI. If not, then if the request-target is in <a href="#authority-form" class="smpl">authority-form</a>, the effective request URI's authority component is the same as the request-target. If not, then if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, the authority component is the same as the Host field-value. Otherwise,
    1990                   the authority component is assigned the default name configured for the server and, if the connection's incoming TCP port
    1991                   number differs from the default port for the effective request URI's scheme, then a colon (":") and the incoming port number
    1992                   (in decimal form) are appended to the authority component.
    1993                </li>
    1994                <li>If the request-target is in <a href="#authority-form" class="smpl">authority-form</a> or <a href="#asterisk-form" class="smpl">asterisk-form</a>, the effective request URI's combined <a href="#uri" class="smpl">path</a> and <a href="#uri" class="smpl">query</a> component is empty. Otherwise, the combined <a href="#uri" class="smpl">path</a> and <a href="#uri" class="smpl">query</a> component is the same as the request-target.
    1995                </li>
    1996                <li>The components of the effective request URI, once determined as above, can be combined into <a href="#uri" class="smpl">absolute-URI</a> form by concatenating the scheme, "://", authority, and combined path and query component.
    1997                </li>
    1998             </ul>
    1999             <div id="rfc.figure.u.52"></div>
    2000             <p>Example 1: the following message received over an insecure TCP connection</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
     2745            <div id="rfc.section.5.5.p.1">
     2746               <p>Since the request-target often contains only part of the user agent's target URI,
     2747                  a server reconstructs the intended target as an "<dfn>effective request URI</dfn>" to properly service the request. This reconstruction involves both the server's
     2748                  local configuration and information communicated in the <a href="#request-target" class="smpl">request-target</a>, <a href="#header.host" class="smpl">Host</a> header field, and connection context.
     2749               </p>
     2750            </div>
     2751            <div id="rfc.section.5.5.p.2">
     2752               <p>For a user agent, the effective request URI is the target URI.</p>
     2753            </div>
     2754            <div id="rfc.section.5.5.p.3">
     2755               <p>If the <a href="#request-target" class="smpl">request-target</a> is in <a href="#absolute-form" class="smpl">absolute-form</a>, the effective request URI is the same as the request-target. Otherwise, the effective
     2756                  request URI is constructed as follows:
     2757               </p>
     2758               <ul class="empty">
     2759                  <li>If the server's configuration (or outbound gateway) provides a fixed URI <a href="#uri" class="smpl">scheme</a>, that scheme is used for the effective request URI. Otherwise, if the request is
     2760                     received over a TLS-secured TCP connection, the effective request URI's scheme is
     2761                     "https"; if not, the scheme is "http".
     2762                  </li>
     2763                  <li>If the server's configuration (or outbound gateway) provides a fixed URI <a href="#uri" class="smpl">authority</a> component, that authority is used for the effective request URI. If not, then if the
     2764                     request-target is in <a href="#authority-form" class="smpl">authority-form</a>, the effective request URI's authority component is the same as the request-target.
     2765                     If not, then if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, the authority component is
     2766                     the same as the Host field-value. Otherwise, the authority component is assigned the
     2767                     default name configured for the server and, if the connection's incoming TCP port
     2768                     number differs from the default port for the effective request URI's scheme, then
     2769                     a colon (":") and the incoming port number (in decimal form) are appended to the authority
     2770                     component.
     2771                  </li>
     2772                  <li>If the request-target is in <a href="#authority-form" class="smpl">authority-form</a> or <a href="#asterisk-form" class="smpl">asterisk-form</a>, the effective request URI's combined <a href="#uri" class="smpl">path</a> and <a href="#uri" class="smpl">query</a> component is empty. Otherwise, the combined <a href="#uri" class="smpl">path</a> and <a href="#uri" class="smpl">query</a> component is the same as the request-target.
     2773                  </li>
     2774                  <li>The components of the effective request URI, once determined as above, can be combined
     2775                     into <a href="#uri" class="smpl">absolute-URI</a> form by concatenating the scheme, "://", authority, and combined path and query component.
     2776                  </li>
     2777               </ul>
     2778            </div>
     2779            <div id="rfc.figure.u.52">
     2780               <p>Example 1: the following message received over an insecure TCP connection</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    20012781Host: www.example.org:8080
    2002 </pre><div id="rfc.figure.u.53"></div>
    2003             <p>has an effective request URI of</p><pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html
    2004 </pre><div id="rfc.figure.u.54"></div>
    2005             <p>Example 2: the following message received over a TLS-secured TCP connection</p><pre class="text">OPTIONS * HTTP/1.1
     2782</pre></div>
     2783            <div id="rfc.figure.u.53">
     2784               <p>has an effective request URI of</p><pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html
     2785</pre></div>
     2786            <div id="rfc.figure.u.54">
     2787               <p>Example 2: the following message received over a TLS-secured TCP connection</p><pre class="text">OPTIONS * HTTP/1.1
    20062788Host: www.example.org
    2007 </pre><div id="rfc.figure.u.55"></div>
    2008             <p>has an effective request URI of</p><pre class="text">https://www.example.org
    2009 </pre><p id="rfc.section.5.5.p.8">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field might need to use heuristics (e.g., examination of the URI path for something unique to a particular host) in
    2010                order to guess the effective request URI's authority component.
    2011             </p>
    2012             <p id="rfc.section.5.5.p.9">Once the effective request URI has been constructed, an origin server needs to decide whether or not to provide service for
    2013                that URI via the connection in which the request was received. For example, the request might have been misdirected, deliberately
    2014                or accidentally, such that the information within a received <a href="#request-target" class="smpl">request-target</a> or <a href="#header.host" class="smpl">Host</a> header field differs from the host or port upon which the connection has been made. If the connection is from a trusted gateway,
    2015                that inconsistency might be expected; otherwise, it might indicate an attempt to bypass security filters, trick the server
    2016                into delivering non-public content, or poison a cache. See <a href="#security.considerations" title="Security Considerations">Section&nbsp;9</a> for security considerations regarding message routing.
    2017             </p>
     2789</pre></div>
     2790            <div id="rfc.figure.u.55">
     2791               <p>has an effective request URI of</p><pre class="text">https://www.example.org
     2792</pre></div>
     2793            <div id="rfc.section.5.5.p.4">
     2794               <p>Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field might need to use heuristics (e.g., examination of the URI path for something
     2795                  unique to a particular host) in order to guess the effective request URI's authority
     2796                  component.
     2797               </p>
     2798            </div>
     2799            <div id="rfc.section.5.5.p.5">
     2800               <p>Once the effective request URI has been constructed, an origin server needs to decide
     2801                  whether or not to provide service for that URI via the connection in which the request
     2802                  was received. For example, the request might have been misdirected, deliberately or
     2803                  accidentally, such that the information within a received <a href="#request-target" class="smpl">request-target</a> or <a href="#header.host" class="smpl">Host</a> header field differs from the host or port upon which the connection has been made.
     2804                  If the connection is from a trusted gateway, that inconsistency might be expected;
     2805                  otherwise, it might indicate an attempt to bypass security filters, trick the server
     2806                  into delivering non-public content, or poison a cache. See <a href="#security.considerations" title="Security Considerations">Section&nbsp;9</a> for security considerations regarding message routing.
     2807               </p>
     2808            </div>
    20182809         </div>
    20192810         <div id="associating.response.to.request">
    20202811            <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    2021             <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    2022                messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    2023                on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) precede a final response to the same request.
    2024             </p>
    2025             <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final
    2026                (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
    2027             </p>
     2812            <div id="rfc.section.5.6.p.1">
     2813               <p>HTTP does not include a request identifier for associating a given request message
     2814                  with its corresponding one or more response messages. Hence, it relies on the order
     2815                  of response arrival to correspond exactly to the order in which requests are made
     2816                  on the same connection. More than one response message per request only occurs when
     2817                  one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) precede a final response to the same request.
     2818               </p>
     2819            </div>
     2820            <div id="rfc.section.5.6.p.2">
     2821               <p>A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered
     2822                  request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
     2823               </p>
     2824            </div>
    20282825         </div>
    20292826         <div id="message.forwarding">
    20302827            <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a href="#message.forwarding">Message Forwarding</a></h2>
    2031             <p id="rfc.section.5.7.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
    2032                to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has
    2033                characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can
    2034                enhance (or interfere) with either direction of the stream.
    2035             </p>
    2036             <p id="rfc.section.5.7.p.2">An intermediary not acting as a tunnel <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>, and exclude fields from being forwarded that are only intended for the incoming connection.
    2037             </p>
    2038             <p id="rfc.section.5.7.p.3">An intermediary <em class="bcp14">MUST NOT</em> forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize
    2039                its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.
    2040             </p>
     2828            <div id="rfc.section.5.7.p.1">
     2829               <p>As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.3</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and
     2830                  responses. Some intermediaries are used to improve performance or availability. Others
     2831                  are used for access control or to filter content. Since an HTTP stream has characteristics
     2832                  similar to a pipe-and-filter architecture, there are no inherent limits to the extent
     2833                  an intermediary can enhance (or interfere) with either direction of the stream.
     2834               </p>
     2835            </div>
     2836            <div id="rfc.section.5.7.p.2">
     2837               <p>An intermediary not acting as a tunnel <em class="bcp14">MUST</em> implement the <a href="#header.connection" class="smpl">Connection</a> header field, as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>, and exclude fields from being forwarded that are only intended for the incoming
     2838                  connection.
     2839               </p>
     2840            </div>
     2841            <div id="rfc.section.5.7.p.3">
     2842               <p>An intermediary <em class="bcp14">MUST NOT</em> forward a message to itself unless it is protected from an infinite request loop.
     2843                  In general, an intermediary ought to recognize its own server names, including any
     2844                  aliases, local variations, or literal IP addresses, and respond to such requests directly.
     2845               </p>
     2846            </div>
    20412847            <div id="header.via">
    2042                <div id="rfc.iref.v.1"></div>
    20432848               <h3 id="rfc.section.5.7.1"><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;<a href="#header.via">Via</a></h3>
    2044                <p id="rfc.section.5.7.1.p.1">The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server
    2045                   (on requests) or between the origin server and the client (on responses), similar to the "Received" header field in email
    2046                   (<a href="https://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders
    2047                   along the request/response chain.
    2048                </p>
    2049                <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></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> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
     2849               <div id="rfc.section.5.7.1.p.1">
     2850                  <p>The "Via" header field indicates the presence of intermediate protocols and recipients
     2851                     between the user agent and the server (on requests) or between the origin server and
     2852                     the client (on responses), similar to the "Received" header field in email (<a href="https://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>). Via can be used for tracking message forwards, avoiding request loops, and identifying
     2853                     the protocol capabilities of senders along the request/response chain.
     2854                  </p>
     2855               </div>
     2856               <div id="rfc.figure.u.56"><pre class="inline"><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span>  <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> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    20502857
    20512858  <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a>
     
    20532860  <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>
    20542861  <a href="#header.via" class="smpl">pseudonym</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    2055 </pre><p id="rfc.section.5.7.1.p.3">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each intermediary appends its own
    2056                   information about how the message was received, such that the end result is ordered according to the sequence of forwarding
    2057                   recipients.
    2058                </p>
    2059                <p id="rfc.section.5.7.1.p.4">A proxy <em class="bcp14">MUST</em> send an appropriate Via header field, as described below, in each message that it forwards. An HTTP-to-HTTP gateway <em class="bcp14">MUST</em> send an appropriate Via header field in each inbound request message and <em class="bcp14">MAY</em> send a Via header field in forwarded response messages.
    2060                </p>
    2061                <p id="rfc.section.5.7.1.p.5">For each intermediary, the received-protocol indicates the protocol and protocol version used by the upstream sender of the
    2062                   message. Hence, the Via field value records the advertised protocol capabilities of the request/response chain such that they
    2063                   remain visible to downstream recipients; this can be useful for determining what backwards-incompatible features might be
    2064                   safe to use in response, or within a later request, as described in <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a>. For brevity, the protocol-name is omitted when the received protocol is HTTP.
    2065                </p>
    2066                <p id="rfc.section.5.7.1.p.6">The received-by portion of the field value is normally the host and optional port number of a recipient server or client that
    2067                   subsequently forwarded the message. However, if the real host is considered to be sensitive information, a sender <em class="bcp14">MAY</em> replace it with a pseudonym. If a port is not provided, a recipient <em class="bcp14">MAY</em> interpret that as meaning it was received on the default TCP port, if any, for the received-protocol.
    2068                </p>
    2069                <p id="rfc.section.5.7.1.p.7">A sender <em class="bcp14">MAY</em> generate comments in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional, and a recipient <em class="bcp14">MAY</em> remove them prior to forwarding the message.
    2070                </p>
    2071                <p id="rfc.section.5.7.1.p.8">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    2072                   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
    2073                   server at www.example.com. The request received by www.example.com would then have the following Via header field:
    2074                </p>
    2075                <div id="rfc.figure.u.57"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net
    2076 </pre><p id="rfc.section.5.7.1.p.10">An intermediary 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,
    2077                   such an intermediary <em class="bcp14">SHOULD</em> replace each received-by host of any host behind the firewall by an appropriate pseudonym for that host.
    2078                </p>
    2079                <p id="rfc.section.5.7.1.p.11">An intermediary <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol
    2080                   values. For example,
    2081                </p>
    2082                <div id="rfc.figure.u.58"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    2083 </pre><p id="rfc.section.5.7.1.p.13">could be collapsed to</p>
    2084                <div id="rfc.figure.u.59"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    2085 </pre><p id="rfc.section.5.7.1.p.15">A sender <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
    2086                   by pseudonyms. A sender <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values.
    2087                </p>
     2862</pre></div>
     2863               <div id="rfc.section.5.7.1.p.2">
     2864                  <p>Multiple Via field values represent each proxy or gateway that has forwarded the message.
     2865                     Each intermediary appends its own information about how the message was received,
     2866                     such that the end result is ordered according to the sequence of forwarding recipients.
     2867                  </p>
     2868               </div>
     2869               <div id="rfc.section.5.7.1.p.3">
     2870                  <p>A proxy <em class="bcp14">MUST</em> send an appropriate Via header field, as described below, in each message that it
     2871                     forwards. An HTTP-to-HTTP gateway <em class="bcp14">MUST</em> send an appropriate Via header field in each inbound request message and <em class="bcp14">MAY</em> send a Via header field in forwarded response messages.
     2872                  </p>
     2873               </div>
     2874               <div id="rfc.section.5.7.1.p.4">
     2875                  <p>For each intermediary, the received-protocol indicates the protocol and protocol version
     2876                     used by the upstream sender of the message. Hence, the Via field value records the
     2877                     advertised protocol capabilities of the request/response chain such that they remain
     2878                     visible to downstream recipients; this can be useful for determining what backwards-incompatible
     2879                     features might be safe to use in response, or within a later request, as described
     2880                     in <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a>. For brevity, the protocol-name is omitted when the received protocol is HTTP.
     2881                  </p>
     2882               </div>
     2883               <div id="rfc.section.5.7.1.p.5">
     2884                  <p>The received-by portion of the field value is normally the host and optional port
     2885                     number of a recipient server or client that subsequently forwarded the message. However,
     2886                     if the real host is considered to be sensitive information, a sender <em class="bcp14">MAY</em> replace it with a pseudonym. If a port is not provided, a recipient <em class="bcp14">MAY</em> interpret that as meaning it was received on the default TCP port, if any, for the
     2887                     received-protocol.
     2888                  </p>
     2889               </div>
     2890               <div id="rfc.section.5.7.1.p.6">
     2891                  <p>A sender <em class="bcp14">MAY</em> generate comments in the Via header field to identify the software of each recipient,
     2892                     analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional, and a recipient <em class="bcp14">MAY</em> remove them prior to forwarding the message.
     2893                  </p>
     2894               </div>
     2895               <div id="rfc.section.5.7.1.p.7">
     2896                  <p>For example, a request message could be sent from an HTTP/1.0 user agent to an internal
     2897                     proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy
     2898                     at p.example.net, which completes the request by forwarding it to the origin server
     2899                     at www.example.com. The request received by www.example.com would then have the following
     2900                     Via header field:
     2901                  </p>
     2902               </div>
     2903               <div id="rfc.figure.u.57"><pre class="text">  Via: 1.0 fred, 1.1 p.example.net
     2904</pre></div>
     2905               <div id="rfc.section.5.7.1.p.8">
     2906                  <p>An intermediary 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
     2907                     enabled to do so. If not enabled, such an intermediary <em class="bcp14">SHOULD</em> replace each received-by host of any host behind the firewall by an appropriate pseudonym
     2908                     for that host.
     2909                  </p>
     2910               </div>
     2911               <div id="rfc.section.5.7.1.p.9">
     2912                  <p>An intermediary <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry
     2913                     if the entries have identical received-protocol values. For example,
     2914                  </p>
     2915               </div>
     2916               <div id="rfc.figure.u.58"><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2917</pre></div>
     2918               <div id="rfc.section.5.7.1.p.10">
     2919                  <p>could be collapsed to</p>
     2920               </div>
     2921               <div id="rfc.figure.u.59"><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2922</pre></div>
     2923               <div id="rfc.section.5.7.1.p.11">
     2924                  <p>A sender <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control
     2925                     and the hosts have already been replaced by pseudonyms. A sender <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values.
     2926                  </p>
     2927               </div>
    20882928            </div>
    20892929            <div id="message.transformations">
    2090                <div id="rfc.iref.t.8"></div>
    2091                <div id="rfc.iref.n.1"></div>
    20922930               <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a href="#message.transformations">Transformations</a></h3>
    2093                <p id="rfc.section.5.7.2.p.1">Some intermediaries include features for transforming messages and their payloads. A proxy might, for example, convert between
    2094                   image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational problems
    2095                   might occur when these transformations are applied to payloads intended for critical applications, such as medical imaging
    2096                   or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the payload
    2097                   received is identical to the original.
    2098                </p>
    2099                <p id="rfc.section.5.7.2.p.2">An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify messages in a semantically meaningful way (i.e., modifications, beyond those required
    2100                   by normal HTTP processing, that change the message in a way that would be significant to the original sender or potentially
    2101                   significant to downstream recipients). For example, a transforming proxy might be acting as a shared annotation server (modifying
    2102                   responses to include references to a local annotation database), a malware filter, a format transcoder, or a privacy filter.
    2103                   Such transformations are presumed to be desired by whichever client (or client organization) selected the proxy.
    2104                </p>
    2105                <p id="rfc.section.5.7.2.p.3">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if the request-target contains a fully qualified domain name.
    2106                </p>
    2107                <p id="rfc.section.5.7.2.p.4">A proxy <em class="bcp14">MUST NOT</em> modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server,
    2108                   except as noted above to replace an empty path with "/" or "*".
    2109                </p>
    2110                <p id="rfc.section.5.7.2.p.5">A proxy <em class="bcp14">MAY</em> modify the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    2111                </p>
    2112                <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> transform the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).
    2113                </p>
    2114                <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain a no-transform cache-control directive. A proxy that transforms a
    2115                   payload <em class="bcp14">MUST</em> add a <a href="p6-cache.html#header.warning" class="smpl">Warning</a> header field with the warn-code of 214 ("Transformation Applied") if one is not already in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>). A proxy that transforms the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response can further inform downstream recipients that a transformation has been applied by changing the response status code
    2116                   to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    2117                </p>
    2118                <p id="rfc.section.5.7.2.p.8">A proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the endpoints of the communication chain, the resource state, or the selected
    2119                   representation (other than the payload) unless the field's definition specifically allows such modification or the modification
    2120                   is deemed necessary for privacy or security.
    2121                </p>
     2931               <div id="rfc.section.5.7.2.p.1">
     2932                  <p>Some intermediaries include features for transforming messages and their payloads.
     2933                     A proxy might, for example, convert between image formats in order to save cache space
     2934                     or to reduce the amount of traffic on a slow link. However, operational problems might
     2935                     occur when these transformations are applied to payloads intended for critical applications,
     2936                     such as medical imaging or scientific data analysis, particularly when integrity checks
     2937                     or digital signatures are used to ensure that the payload received is identical to
     2938                     the original.
     2939                  </p>
     2940               </div>
     2941               <div id="rfc.section.5.7.2.p.2">
     2942                  <p>An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify messages in a semantically meaningful
     2943                     way (i.e., modifications, beyond those required by normal HTTP processing, that change
     2944                     the message in a way that would be significant to the original sender or potentially
     2945                     significant to downstream recipients). For example, a transforming proxy might be
     2946                     acting as a shared annotation server (modifying responses to include references to
     2947                     a local annotation database), a malware filter, a format transcoder, or a privacy
     2948                     filter. Such transformations are presumed to be desired by whichever client (or client
     2949                     organization) selected the proxy.