Changeset 1859


Ignore:
Timestamp:
Sep 3, 2012, 3:12:40 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) move Expect 100-continue discussion to p2

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1845 r1859  
    449449  }
    450450  @bottom-center {
    451        content: "Expires March 5, 2013";
     451       content: "Expires March 7, 2013";
    452452  }
    453453  @bottom-right {
     
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-09-01">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-09-03">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: March 5, 2013</td>
     526               <td class="left">Expires: March 7, 2013</td>
    527527               <td class="right">greenbytes</td>
    528528            </tr>
    529529            <tr>
    530530               <td class="left"></td>
    531                <td class="right">September 1, 2012</td>
     531               <td class="right">September 3, 2012</td>
    532532            </tr>
    533533         </tbody>
     
    556556         in progress”.
    557557      </p>
    558       <p>This Internet-Draft will expire on March 5, 2013.</p>
     558      <p>This Internet-Draft will expire on March 7, 2013.</p>
    559559      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    560560      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    658658                  </ul>
    659659               </li>
    660                <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
    661                <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
     660               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
    662661            </ul>
    663662         </li>
     
    908907         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    909908         that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform
    910          a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 5.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
     909         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    911910      </p>
    912911      <p id="rfc.section.2.3.p.7"><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 a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
     
    10781077      </p>
    10791078      <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    1080          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 5</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1079         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 7</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    10811080      </p>
    10821081      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     
    11761175      </div>
    11771176      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1178 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1177</pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    11791178      </p>
    11801179      <div id="rfc.iref.r.6"></div>
     
    11891188      </p>
    11901189      <p id="rfc.section.3.1.1.p.10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    1191          it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 5.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
     1190         it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
    11921191      </p>
    11931192      <p id="rfc.section.3.1.1.p.11">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 up to 8000 octets.
     
    12021201      <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
    12031202         the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
    1204          for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
     1203         for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
    12051204         the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
    12061205      </p>
     
    12231222                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
    12241223</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,
    1225          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 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1224         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 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12261225      </p>
    12271226      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
     
    12311230         them.
    12321231      </p>
    1233       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy 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.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1232      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.new.header.fields" title="Considerations for New Header Fields">Section 10.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy 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.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    12341233      </p>
    12351234      <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
     
    13831382      <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    13841383      </p>
    1385       <p id="rfc.section.3.3.1.p.7">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 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1384      <p id="rfc.section.3.3.1.p.7">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 9.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    13861385      </p>
    13871386      <p id="rfc.section.3.3.1.p.8">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="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
     
    16631662         that a client can be assured of buffering the entire response.
    16641663      </p>
    1665       <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 "q" parameter (similar to the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</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;
     1664      <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 "q" parameter (similar to the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</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;
    16661665         a value of 0 means "not acceptable".
    16671666      </p>
     
    17431742      </p>
    17441743      <div id="authority-form">
    1745          <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 3.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). 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) as the request-target. For example,
     1744         <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). 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) as the request-target. For example,
    17461745         </p>
    17471746      </div>
    17481747      <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    17491748</pre><div id="asterisk-form">
    1750          <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 3.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1749         <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    17511750            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    17521751         </p>
     
    18941893      </p>
    18951894      <ul>
    1896          <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 10.5</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    1897          </li>
    1898          <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 10.8</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
     1895         <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
     1896         </li>
     1897         <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    18991898         </li>
    19001899         <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)
     
    19041903         <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>)
    19051904         </li>
    1906          <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 10.17</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
     1905         <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    19071906         </li>
    19081907      </ul>
     
    19121911      </p>
    19131912      <ul>
    1914          <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 10.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
     1913         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    19151914         </li>
    19161915         <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>)
    19171916         </li>
    1918          <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 10.9</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
     1917         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)
    19191918         </li>
    19201919      </ul>
     
    19291928      <p id="rfc.section.5.9.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19301929         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1931          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 5.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request.
     1930         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 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request.
    19321931      </p>
    19331932      <p id="rfc.section.5.9.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
     
    20382037      <p id="rfc.section.6.2.2.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    20392038      </p>
    2040       <p id="rfc.section.6.2.2.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2039      <p id="rfc.section.6.2.2.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    20412040         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    20422041      </p>
    20432042      <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4>
    20442043      <p id="rfc.section.6.2.2.2.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2045          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     2044         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    20462045         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    20472046      </p>
     
    20932092         by the HTTP application.
    20942093      </p>
    2095       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h2>
    2096       <p id="rfc.section.6.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    2097          to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    2098          either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    2099          looking at the body.
    2100       </p>
    2101       <p id="rfc.section.6.3.p.2">Requirements for HTTP/1.1 clients: </p>
    2102       <ul>
    2103          <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) with the "100-continue" expectation.
    2104          </li>
    2105          <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.
    2106          </li>
    2107       </ul>
    2108       <p id="rfc.section.6.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    2109          100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has
    2110          never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    2111       </p>
    2112       <p id="rfc.section.6.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    2113       <ul>
    2114          <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    2115          </li>
    2116          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
    2117             with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"
    2118             expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared
    2119             wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
    2120          </li>
    2121          <li>An origin server <em class="bcp14">MAY</em> omit a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request.
    2122          </li>
    2123          <li>An origin server that sends a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection
    2124             prematurely.
    2125          </li>
    2126          <li>If an origin server receives a request that does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final
    2127             status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
    2128             the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
    2129             a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
    2130          </li>
    2131       </ul>
    2132       <p id="rfc.section.6.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    2133       <ul>
    2134          <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1
    2135             or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
    2136          </li>
    2137          <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code.
    2138          </li>
    2139          <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
    2140          </li>
    2141          <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 5.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
    2142          </li>
    2143       </ul>
    21442094      <div id="rfc.iref.u.5"></div>
    21452095      <div id="rfc.iref.h.14"></div>
    2146       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2147       <p id="rfc.section.6.4.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
     2096      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
     2097      <p id="rfc.section.6.3.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the
    21482098         server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to.
    21492099      </p>
     
    21532103  <a href="#header.upgrade" class="smpl">protocol-name</a>    = <a href="#rule.token.separators" class="smpl">token</a>
    21542104  <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
    2155 </pre><p id="rfc.section.6.4.p.3">For example,</p>
     2105</pre><p id="rfc.section.6.3.p.3">For example,</p>
    21562106      <div id="rfc.figure.u.58"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2157 </pre><p id="rfc.section.6.4.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
     2107</pre><p id="rfc.section.6.3.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
    21582108         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    21592109         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
     
    21622112         the server, possibly according to the nature of the request method or target resource).
    21632113      </p>
    2164       <p id="rfc.section.6.4.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
     2114      <p id="rfc.section.6.3.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
    21652115         Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    21662116         and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen,
    21672117         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field.
    21682118      </p>
    2169       <p id="rfc.section.6.4.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
    2170       </p>
    2171       <p id="rfc.section.6.4.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2172          is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
    2173       </p>
    2174       <p id="rfc.section.6.4.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
     2119      <p id="rfc.section.6.3.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section&nbsp;6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
     2120      </p>
     2121      <p id="rfc.section.6.3.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
     2122         is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
     2123      </p>
     2124      <p id="rfc.section.6.3.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
    21752125            Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    21762126      </p>
    2177       <p id="rfc.section.6.4.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     2127      <p id="rfc.section.6.3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    21782128         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    21792129         in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
     
    22442194                  <td class="left">http</td>
    22452195                  <td class="left">standard</td>
    2246                   <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.4</a>
     2196                  <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;6.3</a>
    22472197                  </td>
    22482198               </tr>
     
    24342384         <li>Pointer to specification text</li>
    24352385      </ul>
    2436       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2386      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 9.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    24372387      </p>
    24382388      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. Use of program names for the identification of encoding
     
    25902540         that most implementations will choose substantially higher limits.
    25912541      </p>
    2592       <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 5.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 5.5</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
     2542      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).
    25932543      </p>
    25942544      <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
    25952545      </p>
    25962546      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2597       <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.5">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari
     2547      <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.4">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari
    25982548         Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Mark Nottingham.
    25992549         See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions.
     
    28542804      <p id="rfc.section.A.1.2.p.1">In HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the
    28552805         response. However, some implementations implement the explicitly negotiated ("Keep-Alive") version of persistent connections
    2856          described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     2806         described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    28572807      </p>
    28582808      <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly
     
    29082858      <p id="rfc.section.A.2.p.14">Clarify exactly when "close" connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
    29092859      </p>
    2910       <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.4</a>)
     2860      <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section&nbsp;6.3</a>)
    29112861      </p>
    29122862      <p id="rfc.section.A.2.p.16">Take over the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>)
     
    34973447                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    34983448                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3499                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
     3449                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
    35003450                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li>
    35013451               </ul>
     
    35983548                        <li><tt>transfer-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.56"><b>4</b></a></li>
    35993549                        <li><tt>transfer-parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>4</b></a></li>
    3600                         <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.4</b></a></li>
     3550                        <li><tt>Upgrade</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.93"><b>6.3</b></a></li>
    36013551                        <li><tt>uri-host</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>2.7</b></a></li>
    36023552                        <li><tt>URI-reference</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>2.7</b></a></li>
     
    36143564                  <li>Header Fields&nbsp;&nbsp;
    36153565                     <ul>
    3616                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
     3566                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>
    36173567                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li>
    36183568                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>
     
    36203570                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.iref.h.8"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li>
    36213571                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li>
    3622                         <li>Upgrade&nbsp;&nbsp;<a href="#rfc.iref.h.14"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
     3572                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.iref.h.14"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
    36233573                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.h.12"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li>
    36243574                     </ul>
     
    36653615            </li>
    36663616            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3667                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a>, <a href="#rfc.xref.Part2.24">6.3</a>, <a href="#rfc.xref.Part2.25">6.3</a>, <a href="#rfc.xref.Part2.26">6.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    3668                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a></li>
    3669                         <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a></li>
    3670                         <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
    3671                         <li><em>Section 3.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    3672                         <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    3673                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li>
    3674                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.26">6.3</a></li>
    3675                         <li><em>Section 5.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3</a></li>
    3676                         <li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3677                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.4</a></li>
    3678                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">8.6</a></li>
    3679                         <li><em>Section 5.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.29">8.6</a></li>
    3680                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.28">7.4</a></li>
    3681                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3</a></li>
    3682                         <li><em>Section 10.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.8</a></li>
    3683                         <li><em>Section 10.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">5.8</a></li>
    3684                         <li><em>Section 10.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">5.8</a></li>
    3685                         <li><em>Section 10.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
    3686                         <li><em>Section 10.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3687                         <li><em>Section 10.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.3</a></li>
    3688                         <li><em>Section 10.17</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.8</a></li>
     3617                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a>, <a href="#rfc.xref.Part2.24">6.3</a>, <a href="#rfc.xref.Part2.25">7.4</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3618                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
     3619                        <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">5.8</a></li>
     3620                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">5.8</a></li>
     3621                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a></li>
     3622                        <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a></li>
     3623                        <li><em>Section 5.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
     3624                        <li><em>Section 5.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
     3625                        <li><em>Section 6.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3</a></li>
     3626                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li>
     3627                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.9</a></li>
     3628                        <li><em>Section 7.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
     3629                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3</a></li>
     3630                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">8.6</a></li>
     3631                        <li><em>Section 7.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.26">8.6</a></li>
     3632                        <li><em>Section 8.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
     3633                        <li><em>Section 8.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.8</a></li>
     3634                        <li><em>Section 8.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.8</a></li>
     3635                        <li><em>Section 9.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.25">7.4</a></li>
     3636                        <li><em>Section 10.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    36893637                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    36903638                     </ul>
     
    37293677                  </li>
    37303678                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li>
    3731                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.4">6.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>
    3732                         <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a></li>
     3679                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.4">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul>
     3680                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li>
    37333681                     </ul>
    37343682                  </li>
     
    38003748            </li>
    38013749            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3802                   <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.iref.u.5"><b>6.4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
     3750                  <li>Upgrade header field&nbsp;&nbsp;<a href="#rfc.iref.u.5"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
    38033751                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    38043752                  <li>URI scheme&nbsp;&nbsp;
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1845 r1859  
    3434  <!ENTITY header-date            "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3535  <!ENTITY header-etag            "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    36   <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3736  <!ENTITY header-expires         "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3837  <!ENTITY header-last-modified   "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    4847  <!ENTITY qvalue                 "<xref target='Part2' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4948  <!ENTITY status-codes           "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    50   <!ENTITY status-100             "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5149  <!ENTITY status-1xx             "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5250  <!ENTITY status-203             "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    5553  <!ENTITY status-4xx             "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5654  <!ENTITY status-414             "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    57   <!ENTITY cons-new-header-fields "<xref target='Part2' x:rel='#considerations.for.creating.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     55  <!ENTITY cons-new-header-fields "<xref target='Part2' x:rel='#considerations.for.new.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    5856]>
    5957<?rfc toc="yes" ?>
     
    30103008</t>
    30113009</section>
    3012 </section>
    3013 
    3014 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
    3015 <t>
    3016    The purpose of the <x:ref>100 (Continue)</x:ref> status code (see &status-100;)
    3017    is to allow a client that is sending a request message with a request body
    3018    to determine if the origin server is willing to accept the request
    3019    (based on the request header fields) before the client sends the request
    3020    body. In some cases, it might either be inappropriate or highly
    3021    inefficient for the client to send the body if the server will reject
    3022    the message without looking at the body.
    3023 </t>
    3024 <t>
    3025    Requirements for HTTP/1.1 clients:
    3026   <list style="symbols">
    3027     <t>
    3028         If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    3029         sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
    3030         field (&header-expect;) with the "100-continue" expectation.
    3031     </t>
    3032     <t>
    3033         A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
    3034         the "100-continue" expectation if it does not intend to send a request
    3035         body.
    3036     </t>
    3037   </list>
    3038 </t>
    3039 <t>
    3040    Because of the presence of older implementations, the protocol allows
    3041    ambiguous situations in which a client might send "Expect: 100-continue"
    3042    without receiving either a <x:ref>417 (Expectation Failed)</x:ref>
    3043    or a <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends this
    3044    header field to an origin server (possibly via a proxy) from which it
    3045    has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 
    3046    wait for an indefinite period before sending the request body.
    3047 </t>
    3048 <t>
    3049    Requirements for HTTP/1.1 origin servers:
    3050   <list style="symbols">
    3051     <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
    3052         field with the "100-continue" expectation, an origin server &MUST;
    3053         either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
    3054         from the input stream, or respond with a final status code. The
    3055         origin server &MUST-NOT; wait for the request body before sending
    3056         the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
    3057         code, it &MAY; close the transport connection or it &MAY; continue
    3058         to read and discard the rest of the request.  It &MUST-NOT;
    3059         perform the request method if it returns a final status code.
    3060     </t>
    3061     <t> An origin server &SHOULD-NOT;  send a <x:ref>100 (Continue)</x:ref> response if
    3062         the request message does not include an <x:ref>Expect</x:ref> header
    3063         field with the "100-continue" expectation, and &MUST-NOT; send a
    3064         <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0
    3065         (or earlier) client. There is an exception to this rule: for
    3066         compatibility with <xref target="RFC2068"/>, a server &MAY; send a <x:ref>100 (Continue)</x:ref>
    3067         status code in response to an HTTP/1.1 PUT or POST request that does
    3068         not include an Expect header field with the "100-continue"
    3069         expectation. This exception, the purpose of which is
    3070         to minimize any client processing delays associated with an
    3071         undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to
    3072         HTTP/1.1 requests, and not to requests with any other HTTP-version
    3073         value.
    3074     </t>
    3075     <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
    3076         already received some or all of the request body for the
    3077         corresponding request.
    3078     </t>
    3079     <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
    3080         ultimately send a final status code, once the request body is
    3081         received and processed, unless it terminates the transport
    3082         connection prematurely.
    3083     </t>
    3084     <t> If an origin server receives a request that does not include an
    3085         <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
    3086         the request includes a request body, and the server responds
    3087         with a final status code before reading the entire request body
    3088         from the transport connection, then the server &SHOULD-NOT;  close
    3089         the transport connection until it has read the entire request,
    3090         or until the client closes the connection. Otherwise, the client
    3091         might not reliably receive the response message. However, this
    3092         requirement ought not be construed as preventing a server from
    3093         defending itself against denial-of-service attacks, or from
    3094         badly broken client implementations.
    3095       </t>
    3096     </list>
    3097 </t>
    3098 <t>
    3099    Requirements for HTTP/1.1 proxies:
    3100   <list style="symbols">
    3101     <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>
    3102         header field with the "100-continue" expectation, and the proxy
    3103         either knows that the next-hop server complies with HTTP/1.1 or
    3104         higher, or does not know the HTTP version of the next-hop
    3105         server, it &MUST; forward the request, including the Expect header
    3106         field.
    3107     </t>
    3108     <t> If the proxy knows that the version of the next-hop server is
    3109         HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
    3110         respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.
    3111     </t>
    3112     <t> Proxies &SHOULD; maintain a record of the HTTP version
    3113         numbers received from recently-referenced next-hop servers.
    3114     </t>
    3115     <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the
    3116         request message was received from an HTTP/1.0 (or earlier)
    3117         client and did not include an <x:ref>Expect</x:ref> header field with
    3118         the "100-continue" expectation. This requirement overrides the
    3119         general rule for forwarding of <x:ref>1xx</x:ref> responses (see &status-1xx;).
    3120     </t>
    3121   </list>
    3122 </t>
    31233010</section>
    31243011
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1858 r1859  
    632632               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.controls">Controls</a><ul>
    633633                     <li><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li>
    634                      <li><a href="#rfc.section.6.1.2">6.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li>
     634                     <li><a href="#rfc.section.6.1.2">6.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a><ul>
     635                           <li><a href="#rfc.section.6.1.2.1">6.1.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
     636                        </ul>
     637                     </li>
    635638                  </ul>
    636639               </li>
     
    16391642      </p>
    16401643      <ul class="empty">
    1641          <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. It does not support any expect-params.
    1642          </li>
     1644         <li>The "100-continue" expectation is defined below. It does not support any expect-params.</li>
    16431645      </ul>
    16441646      <p id="rfc.section.6.1.2.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>
     
    16471649      </p>
    16481650      <p id="rfc.section.6.1.2.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
     1651      <h4 id="rfc.section.6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4>
     1652      <p id="rfc.section.6.1.2.1.p.1">The purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;7.2.1</a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     1653         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
     1654         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
     1655         looking at the body.
     1656      </p>
     1657      <p id="rfc.section.6.1.2.1.p.2">Requirements for HTTP/1.1 clients: </p>
     1658      <ul>
     1659         <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation.
     1660         </li>
     1661         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.
     1662         </li>
     1663      </ul>
     1664      <p id="rfc.section.6.1.2.1.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
     1665         100-continue" without receiving either a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has
     1666         never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
     1667      </p>
     1668      <p id="rfc.section.6.1.2.1.p.4">Requirements for HTTP/1.1 origin servers: </p>
     1669      <ul>
     1670         <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
     1671         </li>
     1672         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
     1673            with <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"
     1674            expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared
     1675            wait for <a href="#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
     1676         </li>
     1677         <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request.
     1678         </li>
     1679         <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection
     1680            prematurely.
     1681         </li>
     1682         <li>If an origin server receives a request that does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final
     1683            status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
     1684            the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
     1685            a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
     1686         </li>
     1687      </ul>
     1688      <p id="rfc.section.6.1.2.1.p.5">Requirements for HTTP/1.1 proxies: </p>
     1689      <ul>
     1690         <li>If a proxy receives a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1
     1691            or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
     1692         </li>
     1693         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code.
     1694         </li>
     1695         <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
     1696         </li>
     1697         <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="#status.1xx" class="smpl">1xx</a> responses (see <a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section&nbsp;7.2.1</a>).
     1698         </li>
     1699      </ul>
    16491700      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="request.conditionals" href="#request.conditionals">Conditionals</a></h2>
    16501701      <p id="rfc.section.6.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the
     
    19612012               <tr>
    19622013                  <td class="left">TE</td>
    1963                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
     2014                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
    19642015               </tr>
    19652016               <tr>
     
    20182069         user agent limitations.
    20192070      </p>
    2020       <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     2071      <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    20212072         for identifying the application.
    20222073      </p>
     
    20742125                  <td class="left">100</td>
    20752126                  <td class="left">Continue</td>
    2076                   <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;7.2.1</a></td>
     2127                  <td class="left"><a href="#status.100" id="rfc.xref.status.100.3" title="100 Continue">Section&nbsp;7.2.1</a></td>
    20772128               </tr>
    20782129               <tr>
     
    22992350      <p id="rfc.section.7.2.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    23002351         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    2301          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     2352         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section&nbsp;6.1.2.1</a> for detailed discussion of the use and handling of this status code.
    23022353      </p>
    23032354      <div id="rfc.iref.77"></div>
    23042355      <div id="rfc.iref.s.5"></div>
    23052356      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    2306       <p id="rfc.section.7.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     2357      <p id="rfc.section.7.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    23072358         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    23082359      </p>
     
    23592410      <div id="rfc.iref.s.10"></div>
    23602411      <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    2361       <p id="rfc.section.7.3.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     2412      <p id="rfc.section.7.3.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    23622413      </p>
    23632414      <p id="rfc.section.7.3.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code
     
    23942445         another input action.
    23952446      </p>
    2396       <p id="rfc.section.7.3.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     2447      <p id="rfc.section.7.3.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    23972448      </p>
    23982449      <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
     
    24282479      <div class="note" id="rfc.section.7.4.p.3">
    24292480         <p> <b>Note:</b> In HTTP/1.0, only the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="#status.302" class="smpl">302 (Found)</a> were defined for the first type of redirect, and the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to
    2430             retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code <a href="#status.303" class="smpl">303 (See Other)</a> (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added
     2481            retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code <a href="#status.303" class="smpl">303 (See Other)</a> (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added
    24312482            yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>, therefore this specification makes that behavior conformant in case the original request was POST.
    24322483         </p>
     
    24402491      </p>
    24412492      <div class="note" id="rfc.section.7.4.p.7">
    2442          <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.
     2493         <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.
    24432494         </p>
    24442495      </div>
     
    26532704      <div id="rfc.iref.s.36"></div>
    26542705      <h3 id="rfc.section.7.5.15"><a href="#rfc.section.7.5.15">7.5.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    2655       <p id="rfc.section.7.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) specifying the required protocols.
     2706      <p id="rfc.section.7.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) specifying the required protocols.
    26562707      </p>
    26572708      <div id="rfc.figure.u.33"></div>
     
    27182769      <p id="rfc.section.7.6.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    27192770         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    2720          in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
     2771         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
    27212772      </p>
    27222773      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
    27232774      <p id="rfc.section.8.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    2724          status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     2775         status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    27252776      </p>
    27262777      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="response.control.data" href="#response.control.data">Control Data</a></h2>
     
    29162967      <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h3>
    29172968      <p id="rfc.section.8.4.2.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    2918       <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     2969      <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;9.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    29192970         identifying the application.
    29202971      </p>
     
    29222973</pre><p id="rfc.section.8.4.2.p.4">Example:</p>
    29232974      <div id="rfc.figure.u.45"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2924 </pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     2975</pre><p id="rfc.section.8.4.2.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    29252976      </p>
    29262977      <div class="note" id="rfc.section.8.4.2.p.7">
     
    30573108      </p>
    30583109      <ul class="empty">
    3059          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3110         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    30603111         </li>
    30613112      </ul>
     
    30633114      </p>
    30643115      <ul class="empty">
    3065          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3116         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    30663117         </li>
    30673118      </ul>
     
    30693120      </p>
    30703121      <ul class="empty">
    3071          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3122         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    30723123         </li>
    30733124      </ul>
     
    31633214         specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
    31643215      </p>
    3165       <p id="rfc.section.10.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
     3216      <p id="rfc.section.10.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
    31663217         algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods
    31673218         can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain
     
    32863337                  <td class="left">100</td>
    32873338                  <td class="left">Continue</td>
    3288                   <td class="left"> <a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section&nbsp;7.2.1</a>
     3339                  <td class="left"> <a href="#status.100" id="rfc.xref.status.100.4" title="100 Continue">Section&nbsp;7.2.1</a>
    32893340                  </td>
    32903341               </tr>
     
    35073558      <h3 id="rfc.section.10.3.1"><a href="#rfc.section.10.3.1">10.3.1</a>&nbsp;<a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3>
    35083559      <p id="rfc.section.10.3.1.p.1">Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource,
    3509          or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
     3560         or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
    35103561      </p>
    35113562      <p id="rfc.section.10.3.1.p.2">The requirements for header field names are defined in <a href="http://tools.ietf.org/html/rfc3864#section-4.1">Section 4.1</a> of <a href="#RFC3864" id="rfc.xref.RFC3864.2"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them
    35123563         with "X-" if they are to be registered (either immediately or in the future).
    35133564      </p>
    3514       <p id="rfc.section.10.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     3565      <p id="rfc.section.10.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
    35153566         can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
    35163567      </p>
    35173568      <p id="rfc.section.10.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
    35183569         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    3519          quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3570         quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    35203571      </p>
    35213572      <p id="rfc.section.10.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like
     
    35353586      <ul>
    35363587         <li>
    3537             <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3588            <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    35383589            </p>
    35393590            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
     
    35513602         </li>
    35523603         <li>
    3553             <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3604            <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    35543605            </p>
    35553606         </li>
     
    35623613         </li>
    35633614         <li>
    3564             <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3615            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    35653616            </p>
    35663617         </li>
     
    37213772      <p id="rfc.section.10.3.2.p.2">The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    37223773      <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h2>
    3723       <p id="rfc.section.10.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). The content coding registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     3774      <p id="rfc.section.10.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). The content coding registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    37243775      </p>
    37253776      <h3 id="rfc.section.10.4.1"><a href="#rfc.section.10.4.1">10.4.1</a>&nbsp;<a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3>
     
    37313782         <li>Pointer to specification text</li>
    37323783      </ul>
    3733       <p id="rfc.section.10.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3784      <p id="rfc.section.10.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    37343785      </p>
    37353786      <p id="rfc.section.10.4.1.p.3">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.3"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
     
    37513802                  <td class="left">compress</td>
    37523803                  <td class="left">UNIX "compress" program method</td>
    3753                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
     3804                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
    37543805                  </td>
    37553806               </tr>
     
    37583809                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    37593810                  </td>
    3760                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
     3811                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
    37613812                  </td>
    37623813               </tr>
     
    37643815                  <td class="left">gzip</td>
    37653816                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    3766                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
     3817                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>
    37673818                  </td>
    37683819               </tr>
     
    38563907      </p>
    38573908      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    3858       <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     3909      <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    38593910      </p>
    38603911      <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References
     
    41224173      </p>
    41234174      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="additional.features" href="#additional.features">Additional Features</a></h1>
    4124       <p id="rfc.section.B.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1
     4175      <p id="rfc.section.B.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1
    41254176         applications. Implementers are advised to be aware of these features, but cannot rely upon their presence in, or interoperability
    41264177         with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that
     
    41684219      <p id="rfc.section.C.p.16">Allow <a href="#header.referer" class="smpl">Referer</a> field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;6.5.2</a>)
    41694220      </p>
    4170       <p id="rfc.section.C.p.17">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.46"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
     4221      <p id="rfc.section.C.p.17">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
    41714222      </p>
    41724223      <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;9.3</a>)
     
    41954246         (any visible US-ASCII character).
    41964247      </p>
    4197       <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>:
    4198       </p>
    4199       <div id="rfc.figure.u.63"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4200   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4201   <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4202   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4203   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4204   <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4248      <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>:
     4249      </p>
     4250      <div id="rfc.figure.u.63"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     4251  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     4252  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     4253  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4254  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4255  <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    42054256
    4206   <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4207   <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4208   <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4209   <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.57"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4257  <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4258  <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4259  <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     4260  <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    42104261</pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    42114262      <div id="rfc.figure.u.64"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     
    49134964         <ul class="ind">
    49144965            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    4915                   <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">7.1</a>, <a href="#rfc.iref.76"><b>7.2.1</b></a>, <a href="#rfc.xref.status.100.2">10.2.3</a></li>
     4966                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">6.1.2.1</a>, <a href="#rfc.xref.status.100.2">6.1.2.1</a>, <a href="#rfc.xref.status.100.3">7.1</a>, <a href="#rfc.iref.76"><b>7.2.1</b></a>, <a href="#rfc.xref.status.100.4">10.2.3</a></li>
    49164967                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.46"><b>6.1.2</b></a></li>
    49174968                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">7.1</a>, <a href="#rfc.iref.77"><b>7.2.2</b></a>, <a href="#rfc.xref.status.101.2">10.2.3</a></li>
     
    51415192            </li>
    51425193            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    5143                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2.4</a>, <a href="#rfc.xref.Part1.10">4.1</a>, <a href="#rfc.xref.Part1.11">4.2</a>, <a href="#rfc.xref.Part1.12">5.3.6</a>, <a href="#rfc.xref.Part1.13">5.3.7</a>, <a href="#rfc.xref.Part1.14">5.3.8</a>, <a href="#rfc.xref.Part1.15">5.3.8</a>, <a href="#rfc.xref.Part1.16">6.1</a>, <a href="#rfc.xref.Part1.17">6.1.2</a>, <a href="#rfc.xref.Part1.18">6.5</a>, <a href="#rfc.xref.Part1.19">6.5.3</a>, <a href="#rfc.xref.Part1.20">7.2.1</a>, <a href="#rfc.xref.Part1.21">7.2.2</a>, <a href="#rfc.xref.Part1.22">7.3.4</a>, <a href="#rfc.xref.Part1.23">7.3.6</a>, <a href="#rfc.xref.Part1.24">7.5.15</a>, <a href="#rfc.xref.Part1.25">7.6.6</a>, <a href="#rfc.xref.Part1.26">8</a>, <a href="#rfc.xref.Part1.27">8.4.2</a>, <a href="#rfc.xref.Part1.28">8.4.2</a>, <a href="#rfc.xref.Part1.29">9.4</a>, <a href="#rfc.xref.Part1.30">9.4</a>, <a href="#rfc.xref.Part1.31">9.4</a>, <a href="#rfc.xref.Part1.32">10.1.2</a>, <a href="#rfc.xref.Part1.33">10.3.1</a>, <a href="#rfc.xref.Part1.34">10.3.1</a>, <a href="#rfc.xref.Part1.35">10.3.1</a>, <a href="#rfc.xref.Part1.36">10.3.1</a>, <a href="#rfc.xref.Part1.37">10.3.1</a>, <a href="#rfc.xref.Part1.38">10.3.1</a>, <a href="#rfc.xref.Part1.39">10.4</a>, <a href="#rfc.xref.Part1.40">10.4.1</a>, <a href="#rfc.xref.Part1.41">10.4.1</a>, <a href="#rfc.xref.Part1.42">10.4.2</a>, <a href="#rfc.xref.Part1.43">10.4.2</a>, <a href="#rfc.xref.Part1.44">10.4.2</a>, <a href="#rfc.xref.Part1.45">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a><ul>
     5194                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2.4</a>, <a href="#rfc.xref.Part1.10">4.1</a>, <a href="#rfc.xref.Part1.11">4.2</a>, <a href="#rfc.xref.Part1.12">5.3.6</a>, <a href="#rfc.xref.Part1.13">5.3.7</a>, <a href="#rfc.xref.Part1.14">5.3.8</a>, <a href="#rfc.xref.Part1.15">5.3.8</a>, <a href="#rfc.xref.Part1.16">6.1</a>, <a href="#rfc.xref.Part1.17">6.5</a>, <a href="#rfc.xref.Part1.18">6.5.3</a>, <a href="#rfc.xref.Part1.19">7.2.2</a>, <a href="#rfc.xref.Part1.20">7.3.4</a>, <a href="#rfc.xref.Part1.21">7.3.6</a>, <a href="#rfc.xref.Part1.22">7.5.15</a>, <a href="#rfc.xref.Part1.23">7.6.6</a>, <a href="#rfc.xref.Part1.24">8</a>, <a href="#rfc.xref.Part1.25">8.4.2</a>, <a href="#rfc.xref.Part1.26">8.4.2</a>, <a href="#rfc.xref.Part1.27">9.4</a>, <a href="#rfc.xref.Part1.28">9.4</a>, <a href="#rfc.xref.Part1.29">9.4</a>, <a href="#rfc.xref.Part1.30">10.1.2</a>, <a href="#rfc.xref.Part1.31">10.3.1</a>, <a href="#rfc.xref.Part1.32">10.3.1</a>, <a href="#rfc.xref.Part1.33">10.3.1</a>, <a href="#rfc.xref.Part1.34">10.3.1</a>, <a href="#rfc.xref.Part1.35">10.3.1</a>, <a href="#rfc.xref.Part1.36">10.3.1</a>, <a href="#rfc.xref.Part1.37">10.4</a>, <a href="#rfc.xref.Part1.38">10.4.1</a>, <a href="#rfc.xref.Part1.39">10.4.1</a>, <a href="#rfc.xref.Part1.40">10.4.2</a>, <a href="#rfc.xref.Part1.41">10.4.2</a>, <a href="#rfc.xref.Part1.42">10.4.2</a>, <a href="#rfc.xref.Part1.43">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.44">C</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul>
    51445195                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    5145                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">7.3.4</a></li>
     5196                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">7.3.4</a></li>
    51465197                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    5147                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">7.6.6</a></li>
    5148                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a></li>
    5149                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.5.3</a>, <a href="#rfc.xref.Part1.27">8.4.2</a>, <a href="#rfc.xref.Part1.33">10.3.1</a>, <a href="#rfc.xref.Part1.36">10.3.1</a></li>
    5150                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a></li>
    5151                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">10.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.55">D</a></li>
    5152                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3</a>, <a href="#rfc.xref.Part1.11">4.2</a>, <a href="#rfc.xref.Part1.23">7.3.6</a>, <a href="#rfc.xref.Part1.32">10.1.2</a></li>
     5198                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">7.6.6</a></li>
     5199                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a></li>
     5200                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">6.5.3</a>, <a href="#rfc.xref.Part1.25">8.4.2</a>, <a href="#rfc.xref.Part1.31">10.3.1</a>, <a href="#rfc.xref.Part1.34">10.3.1</a></li>
     5201                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>
     5202                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">10.3.1</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.53">D</a></li>
     5203                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3</a>, <a href="#rfc.xref.Part1.11">4.2</a>, <a href="#rfc.xref.Part1.21">7.3.6</a>, <a href="#rfc.xref.Part1.30">10.1.2</a></li>
    51535204                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">4.1</a></li>
    5154                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.40">10.4.1</a></li>
    5155                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.38">10.3.1</a></li>
    5156                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">9.4</a>, <a href="#rfc.xref.Part1.42">10.4.2</a></li>
    5157                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.39">10.4</a>, <a href="#rfc.xref.Part1.41">10.4.1</a></li>
    5158                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">9.4</a>, <a href="#rfc.xref.Part1.43">10.4.2</a></li>
    5159                         <li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">9.4</a>, <a href="#rfc.xref.Part1.44">10.4.2</a></li>
    5160                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">6.5</a></li>
     5205                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.38">10.4.1</a></li>
     5206                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">10.3.1</a></li>
     5207                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">9.4</a>, <a href="#rfc.xref.Part1.40">10.4.2</a></li>
     5208                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">10.4</a>, <a href="#rfc.xref.Part1.39">10.4.1</a></li>
     5209                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">9.4</a>, <a href="#rfc.xref.Part1.41">10.4.2</a></li>
     5210                        <li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">9.4</a>, <a href="#rfc.xref.Part1.42">10.4.2</a></li>
     5211                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">6.5</a></li>
    51615212                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.12">5.3.6</a>, <a href="#rfc.xref.Part1.13">5.3.7</a></li>
    51625213                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">6.1</a></li>
    5163                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2.4</a>, <a href="#rfc.xref.Part1.26">8</a></li>
    5164                         <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">5.3.8</a>, <a href="#rfc.xref.Part1.28">8.4.2</a>, <a href="#rfc.xref.Part1.46">C</a></li>
    5165                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">10.3.1</a></li>
    5166                         <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">6.1.2</a>, <a href="#rfc.xref.Part1.20">7.2.1</a></li>
    5167                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">7.2.2</a>, <a href="#rfc.xref.Part1.24">7.5.15</a></li>
     5214                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2.4</a>, <a href="#rfc.xref.Part1.24">8</a></li>
     5215                        <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">5.3.8</a>, <a href="#rfc.xref.Part1.26">8.4.2</a>, <a href="#rfc.xref.Part1.44">C</a></li>
     5216                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">10.3.1</a></li>
     5217                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">7.2.2</a>, <a href="#rfc.xref.Part1.22">7.5.15</a></li>
    51685218                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">5.3.8</a></li>
    5169                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.45">12</a></li>
    5170                         <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">10.3.1</a></li>
     5219                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">12</a></li>
     5220                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">10.3.1</a></li>
    51715221                     </ul>
    51725222                  </li>
     
    52465296                     </ul>
    52475297                  </li>
    5248                   <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.4</a>, <a href="#rfc.xref.RFC2068.2">7.4</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.3">B</a><ul>
    5249                         <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.4</a></li>
    5250                         <li><em>Section 10.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">7.4</a></li>
     5298                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">6.1.2.1</a>, <a href="#rfc.xref.RFC2068.2">7.4</a>, <a href="#rfc.xref.RFC2068.3">7.4</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.4">B</a><ul>
     5299                        <li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">7.4</a></li>
     5300                        <li><em>Section 10.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.4</a></li>
    52515301                     </ul>
    52525302                  </li>
     
    53175367                  <li>Status Codes&nbsp;&nbsp;
    53185368                     <ul>
    5319                         <li>100 Continue&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">7.1</a>, <a href="#rfc.iref.s.4"><b>7.2.1</b></a>, <a href="#rfc.xref.status.100.2">10.2.3</a></li>
     5369                        <li>100 Continue&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">6.1.2.1</a>, <a href="#rfc.xref.status.100.2">6.1.2.1</a>, <a href="#rfc.xref.status.100.3">7.1</a>, <a href="#rfc.iref.s.4"><b>7.2.1</b></a>, <a href="#rfc.xref.status.100.4">10.2.3</a></li>
    53205370                        <li>101 Switching Protocols&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">7.1</a>, <a href="#rfc.iref.s.5"><b>7.2.2</b></a>, <a href="#rfc.xref.status.101.2">10.2.3</a></li>
    53215371                        <li>200 OK&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">7.1</a>, <a href="#rfc.iref.s.7"><b>7.3.1</b></a>, <a href="#rfc.xref.status.200.2">10.2.3</a></li>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1858 r1859  
    3737  <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3838  <!ENTITY http-version               "<xref target='Part1' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    39   <!ENTITY use100                     "<xref target='Part1' x:rel='#use.of.the.100.status' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4039  <!ENTITY request-target             "<xref target='Part1' x:rel='#request-target' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4140  <!ENTITY header-accept              "<xref target='header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    16541653   <list>
    16551654      <t>
    1656         The "100-continue" expectation is defined &use100;. It does not support
     1655        The "100-continue" expectation is defined below. It does not support
    16571656        any expect-params.
    16581657      </t>
     
    16721671   header field.
    16731672</t>
     1673
     1674<section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
     1675<t>
     1676   The purpose of the <x:ref>100 (Continue)</x:ref> status code
     1677   (<xref target='status.100'/>)
     1678   is to allow a client that is sending a request message with a request body
     1679   to determine if the origin server is willing to accept the request
     1680   (based on the request header fields) before the client sends the request
     1681   body. In some cases, it might either be inappropriate or highly
     1682   inefficient for the client to send the body if the server will reject
     1683   the message without looking at the body.
     1684</t>
     1685<t>
     1686   Requirements for HTTP/1.1 clients:
     1687  <list style="symbols">
     1688    <t>
     1689        If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
     1690        sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
     1691        field with the "100-continue" expectation.
     1692    </t>
     1693    <t>
     1694        A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
     1695        the "100-continue" expectation if it does not intend to send a request
     1696        body.
     1697    </t>
     1698  </list>
     1699</t>
     1700<t>
     1701   Because of the presence of older implementations, the protocol allows
     1702   ambiguous situations in which a client might send "Expect: 100-continue"
     1703   without receiving either a <x:ref>417 (Expectation Failed)</x:ref>
     1704   or a <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends this
     1705   header field to an origin server (possibly via a proxy) from which it
     1706   has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 
     1707   wait for an indefinite period before sending the request body.
     1708</t>
     1709<t>
     1710   Requirements for HTTP/1.1 origin servers:
     1711  <list style="symbols">
     1712    <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
     1713        field with the "100-continue" expectation, an origin server &MUST;
     1714        either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
     1715        from the input stream, or respond with a final status code. The
     1716        origin server &MUST-NOT; wait for the request body before sending
     1717        the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
     1718        code, it &MAY; close the transport connection or it &MAY; continue
     1719        to read and discard the rest of the request.  It &MUST-NOT;
     1720        perform the request method if it returns a final status code.
     1721    </t>
     1722    <t> An origin server &SHOULD-NOT;  send a <x:ref>100 (Continue)</x:ref> response if
     1723        the request message does not include an <x:ref>Expect</x:ref> header
     1724        field with the "100-continue" expectation, and &MUST-NOT; send a
     1725        <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0
     1726        (or earlier) client. There is an exception to this rule: for
     1727        compatibility with <xref target="RFC2068"/>, a server &MAY; send a <x:ref>100 (Continue)</x:ref>
     1728        status code in response to an HTTP/1.1 PUT or POST request that does
     1729        not include an Expect header field with the "100-continue"
     1730        expectation. This exception, the purpose of which is
     1731        to minimize any client processing delays associated with an
     1732        undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to
     1733        HTTP/1.1 requests, and not to requests with any other HTTP-version
     1734        value.
     1735    </t>
     1736    <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
     1737        already received some or all of the request body for the
     1738        corresponding request.
     1739    </t>
     1740    <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
     1741        ultimately send a final status code, once the request body is
     1742        received and processed, unless it terminates the transport
     1743        connection prematurely.
     1744    </t>
     1745    <t> If an origin server receives a request that does not include an
     1746        <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
     1747        the request includes a request body, and the server responds
     1748        with a final status code before reading the entire request body
     1749        from the transport connection, then the server &SHOULD-NOT;  close
     1750        the transport connection until it has read the entire request,
     1751        or until the client closes the connection. Otherwise, the client
     1752        might not reliably receive the response message. However, this
     1753        requirement ought not be construed as preventing a server from
     1754        defending itself against denial-of-service attacks, or from
     1755        badly broken client implementations.
     1756      </t>
     1757    </list>
     1758</t>
     1759<t>
     1760   Requirements for HTTP/1.1 proxies:
     1761  <list style="symbols">
     1762    <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>
     1763        header field with the "100-continue" expectation, and the proxy
     1764        either knows that the next-hop server complies with HTTP/1.1 or
     1765        higher, or does not know the HTTP version of the next-hop
     1766        server, it &MUST; forward the request, including the Expect header
     1767        field.
     1768    </t>
     1769    <t> If the proxy knows that the version of the next-hop server is
     1770        HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
     1771        respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.
     1772    </t>
     1773    <t> Proxies &SHOULD; maintain a record of the HTTP version
     1774        numbers received from recently-referenced next-hop servers.
     1775    </t>
     1776    <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the
     1777        request message was received from an HTTP/1.0 (or earlier)
     1778        client and did not include an <x:ref>Expect</x:ref> header field with
     1779        the "100-continue" expectation. This requirement overrides the
     1780        general rule for forwarding of <x:ref>1xx</x:ref> responses
     1781        (see <xref target='status.100'/>).
     1782    </t>
     1783  </list>
     1784</t>
     1785</section>
    16741786</section>
    16751787</section>
     
    23592471   &SHOULD; continue by sending the remainder of the request or, if the
    23602472   request has already been completed, ignore this response. The server
    2361    &MUST; send a final response after the request has been completed. See
    2362    &use100; for detailed discussion of the use and handling of this
    2363    status code.
     2473   &MUST; send a final response after the request has been completed.
     2474   See <xref target="use.of.the.100.status"/> for detailed discussion of the
     2475   use and handling of this status code.
    23642476</t>
    23652477</section>
Note: See TracChangeset for help on using the changeset viewer.