![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1859 for draft-ietf-httpbis
- Timestamp:
- 03/09/12 22:12:40 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
-
p1-messaging.html (modified) (35 diffs)
-
p1-messaging.xml (modified) (4 diffs)
-
p2-semantics.html (modified) (37 diffs)
-
p2-semantics.xml (modified) (4 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1845 r1859 449 449 } 450 450 @bottom-center { 451 content: "Expires March 5, 2013";451 content: "Expires March 7, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-09-0 1">494 <meta name="dct.issued" scheme="ISO8601" content="2012-09-03"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: March 5, 2013</td>526 <td class="left">Expires: March 7, 2013</td> 527 527 <td class="right">greenbytes</td> 528 528 </tr> 529 529 <tr> 530 530 <td class="left"></td> 531 <td class="right">September 1, 2012</td>531 <td class="right">September 3, 2012</td> 532 532 </tr> 533 533 </tbody> … … 556 556 in progress”. 557 557 </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> 559 559 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 560 560 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 658 658 </ul> 659 659 </li> 660 <li><a href="#rfc.section.6.3">6.3</a> <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> <a href="#header.upgrade">Upgrade</a></li> 660 <li><a href="#rfc.section.6.3">6.3</a> <a href="#header.upgrade">Upgrade</a></li> 662 661 </ul> 663 662 </li> … … 908 907 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 909 908 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. 911 910 </p> 912 911 <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 … … 1078 1077 </p> 1079 1078 <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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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. 1081 1080 </p> 1082 1081 <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 … … 1176 1175 </div> 1177 1176 <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. 1179 1178 </p> 1180 1179 <div id="rfc.iref.r.6"></div> … … 1189 1188 </p> 1190 1189 <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>). 1192 1191 </p> 1193 1192 <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. … … 1202 1201 <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 1203 1202 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), 1205 1204 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1206 1205 </p> … … 1223 1222 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1224 1223 </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. 1226 1225 </p> 1227 1226 <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 … … 1231 1230 them. 1232 1231 </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 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 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. 1234 1233 </p> 1235 1234 <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" … … 1383 1382 <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 3.2</a>, before determining the message body length. 1384 1383 </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. 1386 1385 </p> 1387 1386 <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 … … 1663 1662 that a client can be assured of buffering the entire response. 1664 1663 </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; 1666 1665 a value of 0 means "not acceptable". 1667 1666 </p> … … 1743 1742 </p> 1744 1743 <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, 1746 1745 </p> 1747 1746 </div> 1748 1747 <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1749 1748 </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, 1751 1750 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1752 1751 </p> … … 1894 1893 </p> 1895 1894 <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>) 1899 1898 </li> 1900 1899 <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>) … … 1904 1903 <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>) 1905 1904 </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>) 1907 1906 </li> 1908 1907 </ul> … … 1912 1911 </p> 1913 1912 <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>) 1915 1914 </li> 1916 1915 <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>) 1917 1916 </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>) 1919 1918 </li> 1920 1919 </ul> … … 1929 1928 <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 1930 1929 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. 1932 1931 </p> 1933 1932 <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. … … 2038 2037 <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. 2039 2038 </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 to2039 <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 2041 2040 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. 2042 2041 </p> 2043 2042 <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4> 2044 2043 <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 understanding2044 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 2046 2045 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. 2047 2046 </p> … … 2093 2092 by the HTTP application. 2094 2093 </p> 2095 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <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 willing2097 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might2098 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without2099 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 has2110 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 compatibility2117 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 undeclared2119 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 connection2124 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 final2127 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 preventing2129 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.12135 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>2144 2094 <div id="rfc.iref.u.5"></div> 2145 2095 <div id="rfc.iref.h.14"></div> 2146 <h2 id="rfc.section.6. 4"><a href="#rfc.section.6.4">6.4</a> <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 the2096 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <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 2148 2098 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2149 2099 </p> … … 2153 2103 <a href="#header.upgrade" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2154 2104 <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> 2156 2106 <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, incompatible2107 </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 2158 2108 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2159 2109 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2162 2112 the server, possibly according to the nature of the request method or target resource). 2163 2113 </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. 2165 2115 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2166 2116 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 2167 2117 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. 2168 2118 </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 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, it2172 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 (Switching2119 <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 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 2175 2125 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. 2176 2126 </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 defined2127 <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 2178 2128 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2179 2129 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. … … 2244 2194 <td class="left">http</td> 2245 2195 <td class="left">standard</td> 2246 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6. 4</a>2196 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.3</a> 2247 2197 </td> 2248 2198 </tr> … … 2434 2384 <li>Pointer to specification text</li> 2435 2385 </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 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 4.2</a>. 2437 2387 </p> 2438 2388 <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 … … 2590 2540 that most implementations will choose substantially higher limits. 2591 2541 </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>). 2593 2543 </p> 2594 2544 <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. 2595 2545 </p> 2596 2546 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <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, Ari2547 <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 2598 2548 Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Mark Nottingham. 2599 2549 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. … … 2854 2804 <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 2855 2805 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>. 2857 2807 </p> 2858 2808 <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 … … 2908 2858 <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 6.1</a>) 2909 2859 </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 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 6.3</a>) 2911 2861 </p> 2912 2862 <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 7.6</a>) … … 3497 3447 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3498 3448 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3499 <li>Connection header field <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 <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> 3500 3450 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3501 3451 </ul> … … 3598 3548 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3599 3549 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3600 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6. 4</b></a></li>3550 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.3</b></a></li> 3601 3551 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3602 3552 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> … … 3614 3564 <li>Header Fields 3615 3565 <ul> 3616 <li>Connection <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 <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> 3617 3567 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3618 3568 <li>Host <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> … … 3620 3570 <li>Trailer <a href="#rfc.iref.h.8"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li> 3621 3571 <li>Transfer-Encoding <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 <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 <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> 3623 3573 <li>Via <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> 3624 3574 </ul> … … 3665 3615 </li> 3666 3616 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3667 <li><em>Part2</em> <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> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3669 <li><em>Section 3.2.2</em> <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> <a href="#rfc.xref.Part2.14">5.3</a></li> 3671 <li><em>Section 3.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3672 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3673 <li><em>Section 5</em> <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> <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> <a href="#rfc.xref.Part2.24">6.3</a></li> 3676 <li><em>Section 5.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3677 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.27">6.4</a></li> 3678 <li><em>Section 5.5</em> <a href="#rfc.xref.Part2.30">8.6</a></li> 3679 <li><em>Section 5.5.12</em> <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> <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> <a href="#rfc.xref.Part2.11">4.3</a></li> 3682 <li><em>Section 10.5</em> <a href="#rfc.xref.Part2.16">5.8</a></li> 3683 <li><em>Section 10.6</em> <a href="#rfc.xref.Part2.19">5.8</a></li> 3684 <li><em>Section 10.8</em> <a href="#rfc.xref.Part2.17">5.8</a></li> 3685 <li><em>Section 10.9</em> <a href="#rfc.xref.Part2.20">5.8</a></li> 3686 <li><em>Section 10.10</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3687 <li><em>Section 10.11</em> <a href="#rfc.xref.Part2.25">6.3</a></li> 3688 <li><em>Section 10.17</em> <a href="#rfc.xref.Part2.18">5.8</a></li> 3617 <li><em>Part2</em> <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> <a href="#rfc.xref.Part2.20">5.8</a></li> 3619 <li><em>Section 3.2.2</em> <a href="#rfc.xref.Part2.19">5.8</a></li> 3620 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part2.17">5.8</a></li> 3621 <li><em>Section 5</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3622 <li><em>Section 5.2.2</em> <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> <a href="#rfc.xref.Part2.13">5.3</a></li> 3624 <li><em>Section 5.3.7</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3625 <li><em>Section 6.3.1</em> <a href="#rfc.xref.Part2.11">4.3</a></li> 3626 <li><em>Section 7</em> <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> <a href="#rfc.xref.Part2.21">5.9</a></li> 3628 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3629 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.24">6.3</a></li> 3630 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2.27">8.6</a></li> 3631 <li><em>Section 7.5.12</em> <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> <a href="#rfc.xref.Part2.8">3.2</a></li> 3633 <li><em>Section 8.4.1</em> <a href="#rfc.xref.Part2.16">5.8</a></li> 3634 <li><em>Section 8.4.2</em> <a href="#rfc.xref.Part2.18">5.8</a></li> 3635 <li><em>Section 9.4</em> <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> <a href="#rfc.xref.Part2.9">3.2</a></li> 3689 3637 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3690 3638 </ul> … … 3729 3677 </li> 3730 3678 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3731 <li><em>RFC2068</em> <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> <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> <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> <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li> 3733 3681 </ul> 3734 3682 </li> … … 3800 3748 </li> 3801 3749 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3802 <li>Upgrade header field <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 <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> 3803 3751 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3804 3752 <li>URI scheme -
draft-ietf-httpbis/latest/p1-messaging.xml
r1845 r1859 34 34 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 35 <!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'/>">37 36 <!ENTITY header-expires "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 37 <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 48 47 <!ENTITY qvalue "<xref target='Part2' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 49 48 <!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'/>">51 49 <!ENTITY status-1xx "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 52 50 <!ENTITY status-203 "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 55 53 <!ENTITY status-4xx "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 56 54 <!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'/>"> 58 56 ]> 59 57 <?rfc toc="yes" ?> … … 3010 3008 </t> 3011 3009 </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 body3018 to determine if the origin server is willing to accept the request3019 (based on the request header fields) before the client sends the request3020 body. In some cases, it might either be inappropriate or highly3021 inefficient for the client to send the body if the server will reject3022 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 before3029 sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header3030 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 with3034 the "100-continue" expectation if it does not intend to send a request3035 body.3036 </t>3037 </list>3038 </t>3039 <t>3040 Because of the presence of older implementations, the protocol allows3041 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 this3044 header field to an origin server (possibly via a proxy) from which it3045 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> header3052 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 read3054 from the input stream, or respond with a final status code. The3055 origin server &MUST-NOT; wait for the request body before sending3056 the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status3057 code, it &MAY; close the transport connection or it &MAY; continue3058 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 if3062 the request message does not include an <x:ref>Expect</x:ref> header3063 field with the "100-continue" expectation, and &MUST-NOT; send a3064 <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.03065 (or earlier) client. There is an exception to this rule: for3066 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 does3068 not include an Expect header field with the "100-continue"3069 expectation. This exception, the purpose of which is3070 to minimize any client processing delays associated with an3071 undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to3072 HTTP/1.1 requests, and not to requests with any other HTTP-version3073 value.3074 </t>3075 <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has3076 already received some or all of the request body for the3077 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 is3081 received and processed, unless it terminates the transport3082 connection prematurely.3083 </t>3084 <t> If an origin server receives a request that does not include an3085 <x:ref>Expect</x:ref> header field with the "100-continue" expectation,3086 the request includes a request body, and the server responds3087 with a final status code before reading the entire request body3088 from the transport connection, then the server &SHOULD-NOT; close3089 the transport connection until it has read the entire request,3090 or until the client closes the connection. Otherwise, the client3091 might not reliably receive the response message. However, this3092 requirement ought not be construed as preventing a server from3093 defending itself against denial-of-service attacks, or from3094 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 proxy3103 either knows that the next-hop server complies with HTTP/1.1 or3104 higher, or does not know the HTTP version of the next-hop3105 server, it &MUST; forward the request, including the Expect header3106 field.3107 </t>3108 <t> If the proxy knows that the version of the next-hop server is3109 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 version3113 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 the3116 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 with3118 the "100-continue" expectation. This requirement overrides the3119 general rule for forwarding of <x:ref>1xx</x:ref> responses (see &status-1xx;).3120 </t>3121 </list>3122 </t>3123 3010 </section> 3124 3011 -
draft-ietf-httpbis/latest/p2-semantics.html
r1858 r1859 632 632 <li><a href="#rfc.section.6.1">6.1</a> <a href="#request.controls">Controls</a><ul> 633 633 <li><a href="#rfc.section.6.1.1">6.1.1</a> <a href="#header.max-forwards">Max-Forwards</a></li> 634 <li><a href="#rfc.section.6.1.2">6.1.2</a> <a href="#header.expect">Expect</a></li> 634 <li><a href="#rfc.section.6.1.2">6.1.2</a> <a href="#header.expect">Expect</a><ul> 635 <li><a href="#rfc.section.6.1.2.1">6.1.2.1</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li> 636 </ul> 637 </li> 635 638 </ul> 636 639 </li> … … 1639 1642 </p> 1640 1643 <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"">[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> 1643 1645 </ul> 1644 1646 <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> … … 1647 1649 </p> 1648 1650 <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> <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 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 7.2.1</a>). 1698 </li> 1699 </ul> 1649 1700 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="request.conditionals" href="#request.conditionals">Conditionals</a></h2> 1650 1701 <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 … … 1961 2012 <tr> 1962 2013 <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.1 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a></td> 1964 2015 </tr> 1965 2016 <tr> … … 2018 2069 user agent limitations. 2019 2070 </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 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.1 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2071 <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 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"">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2021 2072 for identifying the application. 2022 2073 </p> … … 2074 2125 <td class="left">100</td> 2075 2126 <td class="left">Continue</td> 2076 <td class="left"><a href="#status.100" id="rfc.xref.status.100. 1" title="100 Continue">Section 7.2.1</a></td>2127 <td class="left"><a href="#status.100" id="rfc.xref.status.100.3" title="100 Continue">Section 7.2.1</a></td> 2077 2128 </tr> 2078 2129 <tr> … … 2299 2350 <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 2300 2351 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"">[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 6.1.2.1</a> for detailed discussion of the use and handling of this status code. 2302 2353 </p> 2303 2354 <div id="rfc.iref.77"></div> 2304 2355 <div id="rfc.iref.s.5"></div> 2305 2356 <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <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"">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined2357 <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"">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 2307 2358 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 2308 2359 </p> … … 2359 2410 <div id="rfc.iref.s.10"></div> 2360 2411 <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a> <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.2 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[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>). 2362 2413 </p> 2363 2414 <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 … … 2394 2445 another input action. 2395 2446 </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.2 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. 2397 2448 </p> 2398 2449 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2428 2479 <div class="note" id="rfc.section.7.4.p.3"> 2429 2480 <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 added2481 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 2431 2482 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. 2432 2483 </p> … … 2440 2491 </p> 2441 2492 <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. 2443 2494 </p> 2444 2495 </div> … … 2653 2704 <div id="rfc.iref.s.36"></div> 2654 2705 <h3 id="rfc.section.7.5.15"><a href="#rfc.section.7.5.15">7.5.15</a> <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"">[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"">[Part1]</cite></a>) specifying the required protocols. 2656 2707 </p> 2657 2708 <div id="rfc.figure.u.33"></div> … … 2718 2769 <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 2719 2770 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.2 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[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. 2721 2772 </p> 2722 2773 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 2723 2774 <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.2 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 2725 2776 </p> 2726 2777 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="response.control.data" href="#response.control.data">Control Data</a></h2> … … 2916 2967 <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a> <a id="header.server" href="#header.server">Server</a></h3> 2917 2968 <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 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.2 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2969 <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 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"">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2919 2970 identifying the application. 2920 2971 </p> … … 2922 2973 </pre><p id="rfc.section.8.4.2.p.4">Example:</p> 2923 2974 <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.2 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 2925 2976 </p> 2926 2977 <div class="note" id="rfc.section.8.4.2.p.7"> … … 3057 3108 </p> 3058 3109 <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.2 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. 3060 3111 </li> 3061 3112 </ul> … … 3063 3114 </p> 3064 3115 <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"">[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"">[Part1]</cite></a>. 3066 3117 </li> 3067 3118 </ul> … … 3069 3120 </p> 3070 3121 <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"">[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"">[Part1]</cite></a>. 3072 3123 </li> 3073 3124 </ul> … … 3163 3214 specific to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3164 3215 </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.3 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing3216 <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"">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing 3166 3217 algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods 3167 3218 can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain … … 3286 3337 <td class="left">100</td> 3287 3338 <td class="left">Continue</td> 3288 <td class="left"> <a href="#status.100" id="rfc.xref.status.100. 2" title="100 Continue">Section 7.2.1</a>3339 <td class="left"> <a href="#status.100" id="rfc.xref.status.100.4" title="100 Continue">Section 7.2.1</a> 3289 3340 </td> 3290 3341 </tr> … … 3507 3558 <h3 id="rfc.section.10.3.1"><a href="#rfc.section.10.3.1">10.3.1</a> <a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3> 3508 3559 <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.3 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages. 3510 3561 </p> 3511 3562 <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 3512 3563 with "X-" if they are to be registered (either immediately or in the future). 3513 3564 </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.3 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters3565 <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"">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 3515 3566 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>. 3516 3567 </p> 3517 3568 <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 3518 3569 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.3 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 3520 3571 </p> 3521 3572 <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 … … 3535 3586 <ul> 3536 3587 <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.3 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 3538 3589 </p> 3539 3590 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 3551 3602 </li> 3552 3603 <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.3 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 3554 3605 </p> 3555 3606 </li> … … 3562 3613 </li> 3563 3614 <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.3 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 3565 3616 </p> 3566 3617 </li> … … 3721 3772 <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> 3722 3773 <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <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.3 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.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"">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 3724 3775 </p> 3725 3776 <h3 id="rfc.section.10.4.1"><a href="#rfc.section.10.4.1">10.4.1</a> <a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3> … … 3731 3782 <li>Pointer to specification text</li> 3732 3783 </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"">[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"">[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"">[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"">[Part1]</cite></a>). 3734 3785 </p> 3735 3786 <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. … … 3751 3802 <td class="left">compress</td> 3752 3803 <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.4 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a> 3754 3805 </td> 3755 3806 </tr> … … 3758 3809 <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>) 3759 3810 </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.4 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a> 3761 3812 </td> 3762 3813 </tr> … … 3764 3815 <td class="left">gzip</td> 3765 3816 <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.4 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a> 3767 3818 </td> 3768 3819 </tr> … … 3856 3907 </p> 3857 3908 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <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.4 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. 3859 3910 </p> 3860 3911 <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References … … 4122 4173 </p> 4123 4174 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <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.14175 <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 4125 4176 applications. Implementers are advised to be aware of these features, but cannot rely upon their presence in, or interoperability 4126 4177 with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that … … 4168 4219 <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 6.5.2</a>) 4169 4220 </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.4 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 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"">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>) 4171 4222 </p> 4172 4223 <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 9.3</a>) … … 4195 4246 (any visible US-ASCII character). 4196 4247 </p> 4197 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>:4198 </p> 4199 <div id="rfc.figure.u.63"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>4200 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>4201 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1. 50"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>>4202 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1. 51"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>4203 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>4204 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.5 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>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"">[Part1]</cite></a>: 4249 </p> 4250 <div id="rfc.figure.u.63"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 4251 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 4252 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 4253 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 4254 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 4255 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 4205 4256 4206 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4207 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>>4208 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4209 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.5 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4257 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4258 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 4259 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4260 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4210 4261 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 4211 4262 <div id="rfc.figure.u.64"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 4913 4964 <ul class="ind"> 4914 4965 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4915 <li>100 Continue (status code) <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) <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> 4916 4967 <li>100-continue (expect value) <a href="#rfc.iref.46"><b>6.1.2</b></a></li> 4917 4968 <li>101 Switching Protocols (status code) <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> … … 5141 5192 </li> 5142 5193 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5143 <li><em>Part1</em> <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> <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> 5144 5195 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 5145 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.2 2">7.3.4</a></li>5196 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.20">7.3.4</a></li> 5146 5197 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 5147 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.2 5">7.6.6</a></li>5148 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5 4">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> <a href="#rfc.xref.Part1.1 9">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> <a href="#rfc.xref.Part1.4 8">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> <a href="#rfc.xref.Part1.3 5">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> <a href="#rfc.xref.Part1.7">3</a>, <a href="#rfc.xref.Part1.11">4.2</a>, <a href="#rfc.xref.Part1.2 3">7.3.6</a>, <a href="#rfc.xref.Part1.32">10.1.2</a></li>5198 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.23">7.6.6</a></li> 5199 <li><em>Section 2.7</em> <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> <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> <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> <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> <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> 5153 5204 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.10">4.1</a></li> 5154 <li><em>Section 4</em> <a href="#rfc.xref.Part1. 40">10.4.1</a></li>5155 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.3 8">10.3.1</a></li>5156 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.2 9">9.4</a>, <a href="#rfc.xref.Part1.42">10.4.2</a></li>5157 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.3 9">10.4</a>, <a href="#rfc.xref.Part1.41">10.4.1</a></li>5158 <li><em>Section 4.2.2</em> <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> <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> <a href="#rfc.xref.Part1.1 8">6.5</a></li>5205 <li><em>Section 4</em> <a href="#rfc.xref.Part1.38">10.4.1</a></li> 5206 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.36">10.3.1</a></li> 5207 <li><em>Section 4.2.1</em> <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> <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> <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> <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> <a href="#rfc.xref.Part1.17">6.5</a></li> 5161 5212 <li><em>Section 5.3</em> <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> 5162 5213 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.16">6.1</a></li> 5163 <li><em>Section 5.5</em> <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> <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> <a href="#rfc.xref.Part1.37">10.3.1</a></li> 5166 <li><em>Section 6.3</em> <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> <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> <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> <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> <a href="#rfc.xref.Part1.35">10.3.1</a></li> 5217 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.19">7.2.2</a>, <a href="#rfc.xref.Part1.22">7.5.15</a></li> 5168 5218 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.15">5.3.8</a></li> 5169 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 5">12</a></li>5170 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.3 4">10.3.1</a></li>5219 <li><em>Section 9</em> <a href="#rfc.xref.Part1.43">12</a></li> 5220 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.32">10.3.1</a></li> 5171 5221 </ul> 5172 5222 </li> … … 5246 5296 </ul> 5247 5297 </li> 5248 <li><em>RFC2068</em> <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> <a href="#rfc.xref.RFC2068. 2">7.4</a></li>5250 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068. 1">7.4</a></li>5298 <li><em>RFC2068</em> <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> <a href="#rfc.xref.RFC2068.3">7.4</a></li> 5300 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.2">7.4</a></li> 5251 5301 </ul> 5252 5302 </li> … … 5317 5367 <li>Status Codes 5318 5368 <ul> 5319 <li>100 Continue <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 <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> 5320 5370 <li>101 Switching Protocols <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> 5321 5371 <li>200 OK <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 37 37 <!ENTITY http-url "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 38 <!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'/>">40 39 <!ENTITY request-target "<xref target='Part1' x:rel='#request-target' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 41 40 <!ENTITY header-accept "<xref target='header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 1654 1653 <list> 1655 1654 <t> 1656 The "100-continue" expectation is defined &use100;. It does not support1655 The "100-continue" expectation is defined below. It does not support 1657 1656 any expect-params. 1658 1657 </t> … … 1672 1671 header field. 1673 1672 </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> 1674 1786 </section> 1675 1787 </section> … … 2359 2471 &SHOULD; continue by sending the remainder of the request or, if the 2360 2472 request has already been completed, ignore this response. The server 2361 &MUST; send a final response after the request has been completed. See2362 &use100; for detailed discussion of the use and handling of this2363 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. 2364 2476 </t> 2365 2477 </section>
Note: See TracChangeset
for help on using the changeset viewer.
