Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/latest/p1-messaging.html?annotate=blame&rev=148
Timestamp: 2019-12-12 00:16:09
Document Index: 753585305

Matched Legal Cases: ['art 1', 'art3', 'art3', 'art 3', 'art3', 'art3', 'art3', 'art 3', 'art3', 'art3', 'art3', 'art 3', 'art3', 'art6', 'art6', 'art 6', 'art6', 'art3', 'art3', 'art 3', 'art3', 'art6', 'art6', 'art 6', 'art6', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2']

p1-messaging.html in draft-ietf-httpbis/latest – Hypertext Transfer Protocol Wiki
source: draft-ietf-httpbis/latest/p1-messaging.html @ 148
Last change on this file since 148 was 148, checked in by fielding@…, 12 years ago
content: "HTTP/1.1, Part 1";
<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="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">
1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier
(URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general
security concerns for implementations.
<li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#http.version">HTTP Version</a></li>
<li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul class="toc">
<li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#general.syntax">General Syntax</a></li>
<li class="tocline1">3.2.2&nbsp;&nbsp;&nbsp;<a href="#http.url">http URL</a></li>
<li class="tocline1">3.2.3&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">URI Comparison</a></li>
<li class="tocline1">3.3&nbsp;&nbsp;&nbsp;<a href="#date.time.formats">Date/Time Formats</a><ul class="toc">
<li class="tocline1">3.3.1&nbsp;&nbsp;&nbsp;<a href="#full.date">Full Date</a></li>
<li class="tocline1">3.4&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul class="toc">
<li class="tocline1">3.4.1&nbsp;&nbsp;&nbsp;<a href="#chunked.transfer.encoding">Chunked Transfer Coding</a></li>
<li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#http.message">HTTP Message</a><ul class="toc">
<li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#message.types">Message Types</a></li>
<li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#message.headers">Message Headers</a></li>
<li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a></li>
<li class="tocline1">4.4&nbsp;&nbsp;&nbsp;<a href="#message.length">Message Length</a></li>
<li class="tocline1">4.5&nbsp;&nbsp;&nbsp;<a href="#general.header.fields">General Header Fields</a></li>
<li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#request">Request</a><ul class="toc">
<li class="tocline1">5.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
<li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#response">Response</a><ul class="toc">
<li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#status-line">Status-Line</a><ul class="toc">
<li class="tocline1">6.1.1&nbsp;&nbsp;&nbsp;<a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li>
<li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#connections">Connections</a><ul class="toc">
<li class="tocline1">7.1&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistent Connections</a><ul class="toc">
<li class="tocline1">7.1.1&nbsp;&nbsp;&nbsp;<a href="#persistent.purpose">Purpose</a></li>
<li class="tocline1">7.1.2&nbsp;&nbsp;&nbsp;<a href="#persistent.overall">Overall Operation</a><ul class="toc">
<li class="tocline1">7.1.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.negotiation">Negotiation</a></li>
<li class="tocline1">7.1.2.2&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
<li class="tocline1">7.2&nbsp;&nbsp;&nbsp;<a href="#message.transmission.requirements">Message Transmission Requirements</a><ul class="toc">
<li class="tocline1">7.2.1&nbsp;&nbsp;&nbsp;<a href="#persistent.flow">Persistent Connections and Flow Control</a></li>
<li class="tocline1">7.2.2&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
<li class="tocline1">7.2.3&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
<li class="tocline1">7.2.4&nbsp;&nbsp;&nbsp;<a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li>
<li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
<li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li>
<li class="tocline1">8.2&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li>
<li class="tocline1">8.3&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a><ul class="toc">
<li class="tocline1">8.3.1&nbsp;&nbsp;&nbsp;<a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li>
<li class="tocline1">8.4&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
<li class="tocline1">8.5&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li>
<li class="tocline1">8.6&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
<li class="tocline1">8.7&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li>
<li class="tocline1">8.8&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
<li class="tocline1">8.9&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li>
<li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a></li>
<li class="tocline0">10.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc">
<li class="tocline1">10.1&nbsp;&nbsp;&nbsp;<a href="#personal.information">Personal Information</a></li>
<li class="tocline1">10.2&nbsp;&nbsp;&nbsp;<a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
<li class="tocline1">10.3&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
<li class="tocline1">10.4&nbsp;&nbsp;&nbsp;<a href="#dns.spoofing">DNS Spoofing</a></li>
<li class="tocline1">10.5&nbsp;&nbsp;&nbsp;<a href="#attack.proxies">Proxies and Caching</a></li>
<li class="tocline1">10.6&nbsp;&nbsp;&nbsp;<a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>
<li class="tocline0">11.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
<li class="tocline0">12.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc">
<li class="tocline1">12.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
<li class="tocline1">12.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
<li class="tocline1">12.3&nbsp;&nbsp;&nbsp;<a href="#rfc.references.3">References (to be categorized)</a></li>
<li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type message/http and application/http</a></li>
<li class="tocline0">B.&nbsp;&nbsp;&nbsp;<a href="#tolerant.applications">Tolerant Applications</a></li>
<li class="tocline0">C.&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li>
<li class="tocline0">D.&nbsp;&nbsp;&nbsp;<a href="#compatibility">Compatibility with Previous Versions</a><ul class="toc">
<li class="tocline1">D.1&nbsp;&nbsp;&nbsp;<a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul class="toc">
<li class="tocline1">D.1.1&nbsp;&nbsp;&nbsp;<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>
entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 3</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
<dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
<dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
The rules for determining the cacheability of HTTP responses are defined in <a href="p6-cache.html#caching" title="Caching in HTTP">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular
<p id="rfc.section.1.4.p.1">The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method,
entity-body content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
<div id="rfc.figure.u.1"></div><pre class="drawing"> request chain ------------------------&gt;
<div id="rfc.figure.u.2"></div><pre class="drawing"> request chain --------------------------------------&gt;
<div id="rfc.figure.u.3"></div><pre class="drawing"> request chain ----------&gt;
behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" title="Caching in HTTP">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
<p id="rfc.section.2.1.p.11">implied *LWS </p>
<p id="rfc.section.3.1.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended
<p id="rfc.section.3.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this
<p id="rfc.section.3.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p>
<p id="rfc.section.3.1.p.7">Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the
<h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
<p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[RFC1737]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location,
or any other characteristic--a resource.
<h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="general.syntax" href="#general.syntax">General Syntax</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:
</pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2>
<p id="rfc.section.3.3.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated
<h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
<p id="rfc.section.3.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to
<p id="rfc.section.3.4.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has
a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty
in determining the exact body length (<a href="#message.length" title="Message Length">Section&nbsp;4.4</a>), or the desire to encrypt data over a shared transport.
<h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3>
<p id="rfc.section.3.4.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
<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&nbsp;8.6</a>).
<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:
described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;8.5</a>; or,
<p id="rfc.section.3.4.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
<p id="rfc.section.4.1.p.6">Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden
fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and
in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) does not allow sending an entity-body in requests. A server <em class="bcp14">SHOULD</em> read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body,
then the message-body <em class="bcp14">SHOULD</em> be ignored when handling the request.
<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 (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section&nbsp;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),
<h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="message.length" href="#message.length">Message Length</a></h2>
<p id="rfc.section.4.4.p.1">The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings
<p id="rfc.section.4.4.p.2"> </p>
<p>If a Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;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
<dd>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.
<p id="rfc.section.4.4.p.3">For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body
<p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
<p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.
<p id="rfc.section.4.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected.
<h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="request" href="#request">Request</a></h1>
<p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
<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&nbsp;D.1.1</a> for other requirements on Host support in HTTP/1.1.)
<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>If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host
are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use
<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.
from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (<cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.2">RFC 2068</cite>) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
<p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
<p id="rfc.section.7.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.
<h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>
<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
takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.
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 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
<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&nbsp;D.2</a> for more information on backward compatibility with HTTP/1.0 clients.
<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 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&nbsp;8.1</a>.
<p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
<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
<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
<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 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.
<h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
<h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
<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
<h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
<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&nbsp;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.
at the body.
<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.
<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.
rule: for compatibility 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 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with
any other HTTP-version value.
<li>An origin server that sends a 100 (Continue) 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
<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 417 (Expectation Failed) status.
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:
<li>Transmit the request-headers</li>
<li>Compute T = R * (2**N), where N is the number of previous retries of this request.</li>
<li>Wait either for an error response from the server, or for T seconds (whichever comes first)</li>
<li>If no error response is received, after T seconds transmit the body of the request.</li>
<li>If client sees that the connection is closed prematurely, repeat from step 1 until the request is accepted, an error response
is received, or the user becomes impatient and terminates the retry process.
<p id="rfc.section.7.2.4.p.2">If at any point an error status is received, the client </p>
<li><em class="bcp14">SHOULD NOT</em> continue and
<li><em class="bcp14">SHOULD</em> close the connection if it has not completed sending the request message.
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<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 HTTP/1.1 header fields related to message framing and transport protocols.</p>
<p id="rfc.section.8.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
header field may not be sent if there are no parameters associated with that connection option.
<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 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
<li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section&nbsp;8.3.1</a> <em class="bcp14">MUST</em> be followed.
<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
<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
<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
<h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>
<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"
<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 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>
<p>The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing
to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that,
if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response,
or that it will attempt to buffer the response on behalf of downstream recipients.
<p> <b>Note:</b> HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering
<p>If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred.
The "chunked" transfer-coding always has a qvalue of 1.
<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
<p id="rfc.section.8.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
<p id="rfc.section.8.6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
<div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.78"></span> Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
<p id="rfc.section.8.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.
<p id="rfc.section.8.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section&nbsp;8.1</a>) whenever Upgrade is present in an HTTP/1.1 message.
<p id="rfc.section.8.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
by the HTTP version rules of <a href="#http.version" title="HTTP Version">Section&nbsp;3.1</a> and future updates to this specification. Any token can be used as a protocol name; however, it will only be useful if both
on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of <a href="#RFC2822" id="rfc.xref.RFC2822.5"><cite title="Internet Message Format">[RFC2822]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
<p id="rfc.section.8.9.p.4">The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port
<p id="rfc.section.8.9.p.5">Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
<p id="rfc.section.8.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
<p id="rfc.section.8.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
<p id="rfc.section.9.p.1">TBD.</p>
<p id="rfc.section.10.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
<h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
<p id="rfc.section.10.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords,
encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly
recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers
and implementors be particularly careful in this area. History shows that errors in this area often create serious security
and/or privacy problems and generate highly adverse publicity for the implementor's company.
<h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
<p id="rfc.section.10.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without
the permission of any individuals that are identifiable by the published results.
<h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
<p id="rfc.section.10.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.
<h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a>&nbsp;<a id="dns.spoofing" href="#dns.spoofing">DNS Spoofing</a></h2>
<p id="rfc.section.10.4.p.1">Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the
<p id="rfc.section.10.4.p.2">In particular, HTTP clients <em class="bcp14">SHOULD</em> rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous
<p id="rfc.section.10.4.p.3">If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they <em class="bcp14">MUST</em> observe the TTL information reported by DNS.
<h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2>
<p id="rfc.section.10.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise
<p id="rfc.section.10.5.p.2">Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports
and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;10.2</a>).
<p id="rfc.section.10.5.p.3">Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the
<p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve
<p id="rfc.section.10.5.p.5">The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy
<h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a>&nbsp;<a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>
<p id="rfc.section.11.p.2">The HTTP protocol has evolved considerably over the years. It has benefited from a large and active developer community--the
many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for
the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny,
John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett,
Tony Sanders, and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
<p id="rfc.section.11.p.3">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already
mentioned, the following individuals have contributed to this specification:
<p id="rfc.section.11.p.4">Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman
Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann,
Bob Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben
Laurie, Paul J. Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David Morris, Gavin Nicol, Ross
Patterson, Bill Perry, Jeffrey Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich Salz, Allan
M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart)
Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen.
<p id="rfc.section.11.p.7">The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank
<address class="vcard"><span class="vcardline"><span