You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/10/12 02:33:48 UTC
svn commit: r583996 [2/5] - in /labs/webarch/trunk/http/draft-fielding-http:
outline2616.html outlineALL.html p1-messaging.html p1-messaging.xml
p2-semantics.html p2-semantics.xml
Modified: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html?rev=583996&r1=583995&r2=583996&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html Thu Oct 11 17:33:46 2007
@@ -335,11 +335,13 @@
<link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2">
<link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3">
<link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4">
- <link rel="Chapter" title="5 Connections" href="#rfc.section.5">
- <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6">
- <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
- <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
- <link rel="Chapter" href="#rfc.section.9" title="9 References">
+ <link rel="Chapter" title="5 Request" href="#rfc.section.5">
+ <link rel="Chapter" title="6 Response" href="#rfc.section.6">
+ <link rel="Chapter" title="7 Connections" href="#rfc.section.7">
+ <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8">
+ <link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9">
+ <link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10">
+ <link rel="Chapter" href="#rfc.section.11" title="11 References">
<link rel="Appendix" title="A Internet Media Type message/http and application/http" href="#rfc.section.A">
<link rel="Appendix" title="B Tolerant Applications" href="#rfc.section.B">
<link rel="Appendix" title="C Conversion of Date Formats" href="#rfc.section.C">
@@ -498,59 +500,80 @@
<li class="tocline1">4.5 <a href="#general.header.fields">General Header Fields</a></li>
</ul>
</li>
- <li class="tocline0">5. <a href="#connections">Connections</a><ul class="toc">
- <li class="tocline1">5.1 <a href="#persistent.connections">Persistent Connections</a><ul class="toc">
- <li class="tocline1">5.1.1 <a href="#persistent.purpose">Purpose</a></li>
- <li class="tocline1">5.1.2 <a href="#persistent.overall">Overall Operation</a><ul class="toc">
- <li class="tocline1">5.1.2.1 <a href="#persistent.negotiation">Negotiation</a></li>
- <li class="tocline1">5.1.2.2 <a href="#pipelining">Pipelining</a></li>
+ <li class="tocline0">5. <a href="#request">Request</a><ul class="toc">
+ <li class="tocline1">5.1 <a href="#request-line">Request-Line</a><ul class="toc">
+ <li class="tocline1">5.1.1 <a href="#method">Method</a></li>
+ <li class="tocline1">5.1.2 <a href="#request-uri">Request-URI</a></li>
+ </ul>
+ </li>
+ <li class="tocline1">5.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
+ </ul>
+ </li>
+ <li class="tocline0">6. <a href="#response">Response</a><ul class="toc">
+ <li class="tocline1">6.1 <a href="#status-line">Status-Line</a><ul class="toc">
+ <li class="tocline1">6.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li class="tocline0">7. <a href="#connections">Connections</a><ul class="toc">
+ <li class="tocline1">7.1 <a href="#persistent.connections">Persistent Connections</a><ul class="toc">
+ <li class="tocline1">7.1.1 <a href="#persistent.purpose">Purpose</a></li>
+ <li class="tocline1">7.1.2 <a href="#persistent.overall">Overall Operation</a><ul class="toc">
+ <li class="tocline1">7.1.2.1 <a href="#persistent.negotiation">Negotiation</a></li>
+ <li class="tocline1">7.1.2.2 <a href="#pipelining">Pipelining</a></li>
</ul>
</li>
- <li class="tocline1">5.1.3 <a href="#persistent.proxy">Proxy Servers</a></li>
- <li class="tocline1">5.1.4 <a href="#persistent.practical">Practical Considerations</a></li>
+ <li class="tocline1">7.1.3 <a href="#persistent.proxy">Proxy Servers</a></li>
+ <li class="tocline1">7.1.4 <a href="#persistent.practical">Practical Considerations</a></li>
</ul>
</li>
- <li class="tocline1">5.2 <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul class="toc">
- <li class="tocline1">5.2.1 <a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
- <li class="tocline1">5.2.2 <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
- <li class="tocline1">5.2.3 <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
- <li class="tocline1">5.2.4 <a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li>
+ <li class="tocline1">7.2 <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul class="toc">
+ <li class="tocline1">7.2.1 <a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
+ <li class="tocline1">7.2.2 <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
+ <li class="tocline1">7.2.3 <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
+ <li class="tocline1">7.2.4 <a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li>
</ul>
</li>
</ul>
</li>
- <li class="tocline0">6. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
- <li class="tocline1">6.1 <a href="#header.connection">Connection</a></li>
- <li class="tocline1">6.2 <a href="#header.content-length">Content-Length</a></li>
- <li class="tocline1">6.3 <a href="#header.date">Date</a><ul class="toc">
- <li class="tocline1">6.3.1 <a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li>
+ <li class="tocline0">8. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
+ <li class="tocline1">8.1 <a href="#header.connection">Connection</a></li>
+ <li class="tocline1">8.2 <a href="#header.content-length">Content-Length</a></li>
+ <li class="tocline1">8.3 <a href="#header.date">Date</a><ul class="toc">
+ <li class="tocline1">8.3.1 <a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li>
</ul>
</li>
- <li class="tocline1">6.4 <a href="#header.te">TE</a></li>
- <li class="tocline1">6.5 <a href="#header.trailer">Trailer</a></li>
- <li class="tocline1">6.6 <a href="#header.transfer-encoding">Transfer-Encoding</a></li>
- <li class="tocline1">6.7 <a href="#header.upgrade">Upgrade</a></li>
- <li class="tocline1">6.8 <a href="#header.via">Via</a></li>
+ <li class="tocline1">8.4 <a href="#header.host">Host</a></li>
+ <li class="tocline1">8.5 <a href="#header.te">TE</a></li>
+ <li class="tocline1">8.6 <a href="#header.trailer">Trailer</a></li>
+ <li class="tocline1">8.7 <a href="#header.transfer-encoding">Transfer-Encoding</a></li>
+ <li class="tocline1">8.8 <a href="#header.upgrade">Upgrade</a></li>
+ <li class="tocline1">8.9 <a href="#header.via">Via</a></li>
</ul>
</li>
- <li class="tocline0">7. <a href="#security.considerations">Security Considerations</a><ul class="toc">
- <li class="tocline1">7.1 <a href="#personal.information">Personal Information</a></li>
- <li class="tocline1">7.2 <a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
- <li class="tocline1">7.3 <a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
- <li class="tocline1">7.4 <a href="#dns.spoofing">DNS Spoofing</a></li>
- <li class="tocline1">7.5 <a href="#attack.proxies">Proxies and Caching</a></li>
- <li class="tocline1">7.6 <a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
+ <li class="tocline0">9. <a href="#security.considerations">Security Considerations</a><ul class="toc">
+ <li class="tocline1">9.1 <a href="#personal.information">Personal Information</a></li>
+ <li class="tocline1">9.2 <a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
+ <li class="tocline1">9.3 <a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
+ <li class="tocline1">9.4 <a href="#dns.spoofing">DNS Spoofing</a></li>
+ <li class="tocline1">9.5 <a href="#attack.proxies">Proxies and Caching</a></li>
+ <li class="tocline1">9.6 <a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
</ul>
</li>
- <li class="tocline0">8. <a href="#ack">Acknowledgments</a></li>
- <li class="tocline0">9. <a href="#rfc.references">References</a></li>
+ <li class="tocline0">10. <a href="#ack">Acknowledgments</a></li>
+ <li class="tocline0">11. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
<li class="tocline0">A. <a href="#internet.media.type.http">Internet Media Type message/http and application/http</a></li>
<li class="tocline0">B. <a href="#tolerant.applications">Tolerant Applications</a></li>
<li class="tocline0">C. <a href="#conversion.of.date.formats">Conversion of Date Formats</a></li>
<li class="tocline0">D. <a href="#compatibility">Compatibility with Previous Versions</a><ul class="toc">
- <li class="tocline1">D.1 <a href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></li>
- <li class="tocline1">D.2 <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li>
+ <li class="tocline1">D.1 <a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul class="toc">
+ <li class="tocline1">D.1.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></li>
+ </ul>
+ </li>
+ <li class="tocline1">D.2 <a href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></li>
+ <li class="tocline1">D.3 <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li>
</ul>
</li>
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
@@ -601,12 +624,14 @@
<p id="rfc.section.1.3.p.4"> <span id="rfc.iref.r.1"></span> <dfn>request</dfn>
</p>
<dl class="empty">
- <dd>An HTTP request message, as defined in [Part 2].</dd>
+ <dd>An HTTP request message, as defined in <a href="#request" title="Request">Section 5</a>.
+ </dd>
</dl>
<p id="rfc.section.1.3.p.5"> <span id="rfc.iref.r.2"></span> <dfn>response</dfn>
</p>
<dl class="empty">
- <dd>An HTTP response message, as defined in [Part 2].</dd>
+ <dd>An HTTP response message, as defined in <a href="#response" title="Response">Section 6</a>.
+ </dd>
</dl>
<p id="rfc.section.1.3.p.6"> <span id="rfc.iref.r.3"></span> <dfn>resource</dfn>
</p>
@@ -780,7 +805,7 @@
the scope of this specification.
</p>
<p id="rfc.section.1.4.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may
- be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section 5.1</a>).
+ be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>).
</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1>
<h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2>
@@ -965,9 +990,7 @@
</p>
<div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
</pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server
- listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path ([Part 2]). The
- use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see RFC 1900 <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[20]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource ([Part 2]). If a proxy receives a host name which is not a fully
- qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
+ listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see RFC 1900 <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[20]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
</p>
<h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
<p id="rfc.section.3.2.3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
@@ -1036,7 +1059,7 @@
<div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span> parameter = attribute "=" value
attribute = token
value = token | quoted-string
-</pre><p id="rfc.section.3.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 6.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 6.6</a>).
+</pre><p id="rfc.section.3.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 8.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8.7</a>).
</p>
<p id="rfc.section.3.4.p.6">Whenever a transfer-coding is applied to a message-body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer-coding is used,
it <em class="bcp14">MUST</em> be the last transfer-coding applied to the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message
@@ -1077,13 +1100,13 @@
whose size is zero, followed by the trailer, which is terminated by an empty line.
</p>
<p id="rfc.section.3.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
- can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 6.5</a>).
+ can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 8.6</a>).
</p>
<p id="rfc.section.3.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
</p>
<ol>
<li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as
- described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 6.4</a>; or,
+ described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 8.5</a>; or,
</li>
<li>the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient
could use the message (in a manner acceptable to the origin server) without receiving this metadata. In other words, the origin
@@ -1116,7 +1139,7 @@
<h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="message.types" href="#message.types">Message Types</a></h2>
<p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>
<div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.51"></span> HTTP-message = Request | Response ; HTTP/1.1 messages
-</pre><p id="rfc.section.4.1.p.3">Request ([Part 2]) and Response ([Part 2]) messages use the generic message format of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header
+</pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section 5</a>) and Response (<a href="#response" title="Response">Section 6</a>) messages use the generic message format of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header
fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header
fields, and possibly a message-body.
</p>
@@ -1160,7 +1183,7 @@
<h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="message.body" href="#message.body">Message Body</a></h2>
<p id="rfc.section.4.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The
message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
- header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 6.6</a>).
+ header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.7</a>).
</p>
<div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.58"></span> message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
@@ -1174,7 +1197,7 @@
then the message-body <em class="bcp14">SHOULD</em> be ignored when handling the request.
</p>
<p id="rfc.section.4.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
- the response status code ([Part 2]). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational),
+ the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 6.1.1</a>). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational),
204 (no content), and 304 (not modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length.
</p>
<h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="message.length" href="#message.length">Message Length</a></h2>
@@ -1190,12 +1213,12 @@
</p>
</li>
<li>
- <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 6.6</a>) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding
+ <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.7</a>) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding
(<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), unless the message is terminated by closing the connection.
</p>
</li>
<li>
- <p>If a Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 6.2</a>) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header
+ <p>If a Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 8.2</a>) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header
field <em class="bcp14">MUST NOT</em> be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received
with both a Transfer-Encoding header field and a Content-Length header field, the latter <em class="bcp14">MUST</em> be ignored.
</p>
@@ -1233,27 +1256,135 @@
to the entity being transferred. These header fields apply only to the message being transmitted.
</p>
<div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.59"></span> general-header = Cache-Control ; [Part 6]
- | Connection ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>
- | Date ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 6.3</a>
+ | Connection ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>
+ | Date ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a>
| Pragma ; [Part 6]
- | Trailer ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 6.5</a>
- | Transfer-Encoding ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 6.6</a>
- | Upgrade ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.7</a>
- | Via ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 6.8</a>
+ | Trailer ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.6</a>
+ | Transfer-Encoding ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8.7</a>
+ | Upgrade ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.8</a>
+ | Via ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.9</a>
| Warning ; [Part 6]
</pre><p id="rfc.section.4.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize
them to be general-header fields. Unrecognized header fields are treated as entity-header fields.
</p>
- <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="connections" href="#connections">Connections</a></h1>
- <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
- <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
- <p id="rfc.section.5.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP
+ <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="request" href="#request">Request</a></h1>
+ <p id="rfc.section.5.p.1">A request message from a client to a server includes, within the first line of that message, the method to be applied to the
+ resource, the identifier of the resource, and the protocol version in use.
+ </p>
+ <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.60"></span> Request = Request-Line ; <a href="#request-line" title="Request-Line">Section 5.1</a>
+ *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a>
+ | request-header ; [Part 2]
+ | entity-header ) CRLF) ; [Part 3]
+ CRLF
+ [ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a>
+</pre><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2>
+ <p id="rfc.section.5.1.p.1">The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The
+ elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
+ </p>
+ <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.61"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF
+</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="method" href="#method">Method</a></h3>
+ <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>
+ <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span> Method = token
+</pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="request-uri" href="#request-uri">Request-URI</a></h3>
+ <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>) and identifies the resource upon which to apply the request.
+ </p>
+ <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.64"></span> Request-URI = "*" | absoluteURI | abs_path | authority
+</pre><p id="rfc.section.5.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does
+ not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
+ apply to a resource. One example would be
+ </p>
+ <div id="rfc.figure.u.31"></div><pre class="text"> OPTIONS * HTTP/1.1
+</pre><p id="rfc.section.5.1.2.p.5">The absoluteURI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
+ and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request
+ loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example
+ Request-Line would be:
+ </p>
+ <div id="rfc.figure.u.32"></div><pre class="text"> GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+</pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
+ </p>
+ <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method ([Part 2]).</p>
+ <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute
+ path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#general.syntax" title="General Syntax">Section 3.2.1</a>, abs_path) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
+ server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:
+ </p>
+ <div id="rfc.figure.u.33"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1
+ Host: www.w3.org
+</pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
+ URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
+ </p>
+ <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#general.syntax" title="General Syntax">Section 3.2.1</a>. If the Request-URI is encoded using the "% HEX HEX" encoding <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[29]</cite></a>, the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
+ </p>
+ <p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above
+ to replace a null abs_path with "/".
+ </p>
+ <p id="rfc.section.5.1.2.p.14"> </p>
+ <dl class="empty">
+ <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
+ a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
+ known to rewrite the Request-URI.
+ </dd>
+ </dl>
+ <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
+ <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p>
+ <p id="rfc.section.5.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix D.1.1</a> for other requirements on Host support in HTTP/1.1.)
+ </p>
+ <p id="rfc.section.5.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or
+ vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
+ </p>
+ <ol>
+ <li>If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
+ </li>
+ <li>If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host
+ header field value.
+ </li>
+ <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.
+ </li>
+ </ol>
+ <p id="rfc.section.5.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine
+ what exact resource is being requested.
+ </p>
+ <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1>
+ <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
+ <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.65"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 6.1</a>
+ *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a>
+ | response-header ; [Part 2]
+ | entity-header ) CRLF) ; [Part 3]
+ CRLF
+ [ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a>
+</pre><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2>
+ <p id="rfc.section.6.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code
+ and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final
+ CRLF sequence.
+ </p>
+ <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.66"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+</pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
+ <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
+ are fully defined in [Part 2]. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code
+ is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine
+ or display the Reason-Phrase.
+ </p>
+ <p id="rfc.section.6.1.1.p.2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
+ There are 5 values for the first digit:
+ </p>
+ <ul>
+ <li>1xx: Informational - Request received, continuing process</li>
+ <li>2xx: Success - The action was successfully received, understood, and accepted</li>
+ <li>3xx: Redirection - Further action must be taken in order to complete the request</li>
+ <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li>
+ <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
+ </ul>
+ <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> Status-Code = 3DIGIT
+ Reason-Phrase = *<TEXT, excluding CR, LF>
+</pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1>
+ <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
+ <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
+ <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP
servers and causing congestion on the Internet. The use of inline images and other associated data often require a client
to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results
from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[21]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[24]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[28]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[22]</cite></a>.
</p>
- <p id="rfc.section.5.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
+ <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
<ul>
<li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways,
tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
@@ -1270,84 +1401,84 @@
semantics after an error is reported.
</li>
</ul>
- <p id="rfc.section.5.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
+ <p id="rfc.section.7.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
</p>
- <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
- <p id="rfc.section.5.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
+ <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
+ <p id="rfc.section.7.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior
of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server.
</p>
- <p id="rfc.section.5.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
- takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
+ <p id="rfc.section.7.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling
+ takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
</p>
- <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
- <p id="rfc.section.5.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token
+ <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
+ <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token
"close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close.
</p>
- <p id="rfc.section.5.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
+ <p id="rfc.section.7.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than
that request, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close.
</p>
- <p id="rfc.section.5.1.2.1.p.3">If either the client or the server sends the close token in the Connection header, that request becomes the last one for the
+ <p id="rfc.section.7.1.2.1.p.3">If either the client or the server sends the close token in the Connection header, that request becomes the last one for the
connection.
</p>
- <p id="rfc.section.5.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix D.1</a> for more information on backward compatibility with HTTP/1.0 clients.
+ <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix D.2</a> for more information on backward compatibility with HTTP/1.0 clients.
</p>
- <p id="rfc.section.5.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.length" title="Message Length">Section 4.4</a>.
+ <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.length" title="Message Length">Section 4.4</a>.
</p>
- <h4 id="rfc.section.5.1.2.2"><a href="#rfc.section.5.1.2.2">5.1.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4>
- <p id="rfc.section.5.1.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
+ <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4>
+ <p id="rfc.section.7.1.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
</p>
- <p id="rfc.section.5.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
+ <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
</p>
- <p id="rfc.section.5.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see [Part 2]). Otherwise, a premature
+ <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see [Part 2]). Otherwise, a premature
termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
</p>
- <h3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
- <p id="rfc.section.5.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>.
+ <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
+ <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.1</a>.
</p>
- <p id="rfc.section.5.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
+ <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects
to. Each persistent connection applies to only one transport link.
</p>
- <p id="rfc.section.5.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[25]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
+ <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[25]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
</p>
- <h3 id="rfc.section.5.1.4"><a href="#rfc.section.5.1.4">5.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
- <p id="rfc.section.5.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
+ <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
+ <p id="rfc.section.7.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
might make this a higher value since it is likely that the client will be making more connections through the same server.
The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client
or the server.
</p>
- <p id="rfc.section.5.1.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
+ <p id="rfc.section.7.1.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does
not detect the other side's close promptly it could cause unnecessary resource drain on the network.
</p>
- <p id="rfc.section.5.1.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
+ <p id="rfc.section.7.1.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time
that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed
while it was idle, but from the client's point of view, a request is in progress.
</p>
- <p id="rfc.section.5.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
+ <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
sequence is idempotent (see [Part 2]). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
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.
</p>
- <p id="rfc.section.5.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
+ <p id="rfc.section.7.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
</p>
- <p id="rfc.section.5.1.4.p.6">Clients that use persistent connections <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server. A single-user client <em class="bcp14">SHOULD NOT</em> maintain more than 2 connections with any server or proxy. A proxy <em class="bcp14">SHOULD</em> use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines
+ <p id="rfc.section.7.1.4.p.6">Clients that use persistent connections <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server. A single-user client <em class="bcp14">SHOULD NOT</em> maintain more than 2 connections with any server or proxy. A proxy <em class="bcp14">SHOULD</em> use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines
are intended to improve HTTP response times and avoid congestion.
</p>
- <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
- <h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
- <p id="rfc.section.5.2.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
+ <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
+ <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
+ <p id="rfc.section.7.2.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating
connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.
</p>
- <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
- <p id="rfc.section.5.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status while it is transmitting the request. If the client sees an error status,
+ <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
+ <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status while it is transmitting the request. If the client sees an error status,
it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
</p>
- <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
- <p id="rfc.section.5.2.3.p.1">The purpose of the 100 (Continue) status (see [Part 2]) is to allow a client that is sending a request message with a request
+ <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
+ <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see [Part 2]) is to allow a client that is sending a request message with a request
body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends
the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if
the server will reject the message without looking at the body.
</p>
- <p id="rfc.section.5.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
+ <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
<ul>
<li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field ([Part 2]) with the "100-continue" expectation.
</li>
@@ -1355,12 +1486,12 @@
body.
</li>
</ul>
- <p id="rfc.section.5.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect:
+ <p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect:
100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client
sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the
client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
</p>
- <p id="rfc.section.5.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
+ <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
<ul>
<li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status 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 100 (Continue) 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 requested method if it returns a final status code.
@@ -1384,7 +1515,7 @@
server from defending itself against denial-of-service attacks, or from badly broken client implementations.
</li>
</ul>
- <p id="rfc.section.5.2.3.p.5">Requirements for HTTP/1.1 proxies: </p>
+ <p id="rfc.section.7.2.3.p.5">Requirements for HTTP/1.1 proxies: </p>
<ul>
<li>If a proxy receives a request that includes an Expect request-header field with the "100-continue" expectation, and the proxy
either knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop
@@ -1399,8 +1530,8 @@
of 1xx responses (see [Part 2]).
</li>
</ul>
- <h3 id="rfc.section.5.2.4"><a href="#rfc.section.5.2.4">5.2.4</a> <a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
- <p id="rfc.section.5.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field
+ <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
+ <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field
with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the
client sees the connection close before receiving any status from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
</p>
@@ -1417,71 +1548,71 @@
is received, or the user becomes impatient and terminates the retry process.
</li>
</ol>
- <p id="rfc.section.5.2.4.p.2">If at any point an error status is received, the client </p>
+ <p id="rfc.section.7.2.4.p.2">If at any point an error status is received, the client </p>
<ul>
<li><em class="bcp14">SHOULD NOT</em> continue and
</li>
<li><em class="bcp14">SHOULD</em> close the connection if it has not completed sending the request message.
</li>
</ul>
- <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
- <p id="rfc.section.6.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
+ <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
+ <p id="rfc.section.8.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
and recipient refer to either the client or the server, depending on who sends and who receives the entity.
</p>
<div id="rfc.iref.c.6"></div>
<div id="rfc.iref.h.1"></div>
- <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2>
- <p id="rfc.section.6.1.p.1">The Connection general-header field allows the sender to specify options that are desired for that particular connection and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
+ <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2>
+ <p id="rfc.section.8.1.p.1">The Connection general-header field allows the sender to specify options that are desired for that particular connection and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
</p>
- <p id="rfc.section.6.1.p.2">The Connection header has the following grammar:</p>
- <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span> Connection = "Connection" ":" 1#(connection-token)
+ <p id="rfc.section.8.1.p.2">The Connection header has the following grammar:</p>
+ <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> Connection = "Connection" ":" 1#(connection-token)
connection-token = token
-</pre><p id="rfc.section.6.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header
+</pre><p id="rfc.section.8.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header
field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a
connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional
header field may not be sent if there are no parameters associated with that connection option.
</p>
- <p id="rfc.section.6.1.p.5">Message headers listed in the Connection header <em class="bcp14">MUST NOT</em> include end-to-end headers, such as Cache-Control.
+ <p id="rfc.section.8.1.p.5">Message headers listed in the Connection header <em class="bcp14">MUST NOT</em> include end-to-end headers, such as Cache-Control.
</p>
- <p id="rfc.section.6.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
+ <p id="rfc.section.8.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
of the response. For example,
</p>
- <div id="rfc.figure.u.28"></div><pre class="text"> Connection: close
-</pre><p id="rfc.section.6.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 5.1</a>) after the current request/response is complete.
+ <div id="rfc.figure.u.38"></div><pre class="text"> Connection: close
+</pre><p id="rfc.section.8.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete.
</p>
- <p id="rfc.section.6.1.p.9">HTTP/1.1 applications that do not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every message.
+ <p id="rfc.section.8.1.p.9">HTTP/1.1 applications that do not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every message.
</p>
- <p id="rfc.section.6.1.p.10">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token
+ <p id="rfc.section.8.1.p.10">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token
in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects
- against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix D.1</a>.
+ against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix D.2</a>.
</p>
<div id="rfc.iref.c.7"></div>
<div id="rfc.iref.h.2"></div>
- <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
- <p id="rfc.section.6.2.p.1">The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient
+ <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
+ <p id="rfc.section.8.2.p.1">The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient
or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
</p>
- <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.62"></span> Content-Length = "Content-Length" ":" 1*DIGIT
-</pre><p id="rfc.section.6.2.p.3">An example is</p>
- <div id="rfc.figure.u.30"></div><pre class="text"> Content-Length: 3495
-</pre><p id="rfc.section.6.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 4.4</a>.
+ <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.72"></span> Content-Length = "Content-Length" ":" 1*DIGIT
+</pre><p id="rfc.section.8.2.p.3">An example is</p>
+ <div id="rfc.figure.u.40"></div><pre class="text"> Content-Length: 3495
+</pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 4.4</a>.
</p>
- <p id="rfc.section.6.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.length" title="Message Length">Section 4.4</a> describes how to determine the length of a message-body if a Content-Length is not given.
+ <p id="rfc.section.8.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.length" title="Message Length">Section 4.4</a> describes how to determine the length of a message-body if a Content-Length is not given.
</p>
- <p id="rfc.section.6.2.p.7">Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional
+ <p id="rfc.section.8.2.p.7">Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional
field used within the "message/external-body" content-type. In HTTP, it <em class="bcp14">SHOULD</em> be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules
in <a href="#message.length" title="Message Length">Section 4.4</a>.
</p>
<div id="rfc.iref.d.2"></div>
<div id="rfc.iref.h.3"></div>
- <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.date" href="#header.date">Date</a></h2>
- <p id="rfc.section.6.3.p.1">The Date general-header field represents the date and time at which the message was originated, having the same semantics
+ <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.date" href="#header.date">Date</a></h2>
+ <p id="rfc.section.8.3.p.1">The Date general-header field represents the date and time at which the message was originated, having the same semantics
as orig-date in RFC 822. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 3.3.1</a>; it <em class="bcp14">MUST</em> be sent in RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[6]</cite></a>-date format.
</p>
- <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.63"></span> Date = "Date" ":" HTTP-date
-</pre><p id="rfc.section.6.3.p.3">An example is</p>
- <div id="rfc.figure.u.32"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT
-</pre><p id="rfc.section.6.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
+ <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span> Date = "Date" ":" HTTP-date
+</pre><p id="rfc.section.8.3.p.3">An example is</p>
+ <div id="rfc.figure.u.42"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT
+</pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
</p>
<ol>
<li>If the response status code is 100 (Continue) or 101 (Switching Protocols), the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
@@ -1489,44 +1620,64 @@
<li>If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it
is inconvenient or impossible to generate a valid Date.
</li>
- <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 6.3.1</a> <em class="bcp14">MUST</em> be followed.
+ <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 8.3.1</a> <em class="bcp14">MUST</em> be followed.
</li>
</ol>
- <p id="rfc.section.6.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires
+ <p id="rfc.section.8.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires
a Date. An HTTP implementation without a clock <em class="bcp14">MUST NOT</em> cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[23]</cite></a>, to synchronize its clock with a reliable external standard.
</p>
- <p id="rfc.section.6.3.p.7">Clients <em class="bcp14">SHOULD</em> only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even
+ <p id="rfc.section.8.3.p.7">Clients <em class="bcp14">SHOULD</em> only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even
then it is optional. A client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request.
</p>
- <p id="rfc.section.6.3.p.8">The HTTP-date sent in a Date header <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
+ <p id="rfc.section.8.3.p.8">The HTTP-date sent in a Date header <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the entity
is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
value.
</p>
- <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a> <a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>
- <p id="rfc.section.6.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or
+ <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>
+ <p id="rfc.section.8.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or
user with a reliable clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration"
of responses without storing separate Expires values for each resource).
</p>
- <div id="rfc.iref.t.2"></div>
<div id="rfc.iref.h.4"></div>
- <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.te" href="#header.te">TE</a></h2>
- <p id="rfc.section.6.4.p.1">The TE request-header field indicates what extension transfer-codings it is willing to accept in the response and whether
+ <div id="rfc.iref.h.5"></div>
+ <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.host" href="#header.host">Host</a></h2>
+ <p id="rfc.section.8.4.p.1">The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from
+ the original URI given by the user or referring resource (generally an HTTP URL, as described in <a href="#http.url" title="http URL">Section 3.2.2</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or
+ gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on
+ a single IP address.
+ </p>
+ <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.74"></span> Host = "Host" ":" host [ ":" port ] ; <a href="#http.url" title="http URL">Section 3.2.2</a>
+</pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
+ URL). For example, a request on the origin server for <http://www.w3.org/pub/WWW/> would properly include:
+ </p>
+ <div id="rfc.figure.u.44"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1
+ Host: www.w3.org
+</pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name
+ for the service being requested, then the Host header field <em class="bcp14">MUST</em> be given with an empty value. An HTTP/1.1 proxy <em class="bcp14">MUST</em> ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being
+ requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
+ </p>
+ <p id="rfc.section.8.4.p.6">See sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">D.1.1</a> for other requirements relating to Host.
+ </p>
+ <div id="rfc.iref.t.2"></div>
+ <div id="rfc.iref.h.6"></div>
+ <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="header.te" href="#header.te">TE</a></h2>
+ <p id="rfc.section.8.5.p.1">The TE request-header field indicates what extension transfer-codings it is willing to accept in the response and whether
or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers"
and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>).
</p>
- <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span> TE = "TE" ":" #( t-codings )
+ <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
-</pre><p id="rfc.section.6.4.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
+</pre><p id="rfc.section.8.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
as defined in <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
</p>
- <p id="rfc.section.6.4.p.4">Examples of its use are:</p>
- <div id="rfc.figure.u.34"></div><pre class="text"> TE: deflate
+ <p id="rfc.section.8.5.p.4">Examples of its use are:</p>
+ <div id="rfc.figure.u.46"></div><pre class="text"> TE: deflate
TE:
TE: trailers, deflate;q=0.5
-</pre><p id="rfc.section.6.4.p.6">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 6.1</a>) whenever TE is present in an HTTP/1.1 message.
+</pre><p id="rfc.section.8.5.p.6">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 8.1</a>) whenever TE is present in an HTTP/1.1 message.
</p>
- <p id="rfc.section.6.4.p.7">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
+ <p id="rfc.section.8.5.p.7">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
<ol>
<li>
<p>The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing
@@ -1549,22 +1700,22 @@
</p>
</li>
</ol>
- <p id="rfc.section.6.4.p.8">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
+ <p id="rfc.section.8.5.p.8">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
is always acceptable.
</p>
<div id="rfc.iref.t.3"></div>
- <div id="rfc.iref.h.5"></div>
- <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2>
- <p id="rfc.section.6.5.p.1">The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded
+ <div id="rfc.iref.h.7"></div>
+ <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2>
+ <p id="rfc.section.8.6.p.1">The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded
with chunked transfer-coding.
</p>
- <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.66"></span> Trailer = "Trailer" ":" 1#field-name
[... 595 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org