source: draft-ietf-httpbis/19/draft-ietf-httpbis-p1-messaging-19.xml @ 2673

Last change on this file since 2673 was 1592, checked in by julian.reschke@…, 8 years ago

-19

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 225.7 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
7<?rfc toc="yes" ?>
8<?rfc symrefs="yes" ?>
9<?rfc sortrefs="yes" ?>
10<?rfc compact="yes"?>
11<?rfc subcompact="no" ?>
12<?rfc linkmailto="no" ?>
13<?rfc editing="no" ?>
14<?rfc comments="yes"?>
15<?rfc inline="yes"?>
16<?rfc rfcedstyle="yes"?>
17<!DOCTYPE rfc
18  PUBLIC "" "rfc2629.dtd">
19<rfc obsoletes="2145,2616" updates="2817" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p1-messaging-19">
20
21
22<front>
23
24  <title abbrev="HTTP/1.1, Part 1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
25
26  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
27    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
28    <address>
29      <postal>
30        <street>345 Park Ave</street>
31        <city>San Jose</city>
32        <region>CA</region>
33        <code>95110</code>
34        <country>USA</country>
35      </postal>
36      <email>fielding@gbiv.com</email>
37      <uri>http://roy.gbiv.com/</uri>
38    </address>
39  </author>
40
41  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
42    <organization abbrev="W3C">World Wide Web Consortium</organization>
43    <address>
44      <postal>
45        <street>W3C / ERCIM</street>
46        <street>2004, rte des Lucioles</street>
47        <city>Sophia-Antipolis</city>
48        <region>AM</region>
49        <code>06902</code>
50        <country>France</country>
51      </postal>
52      <email>ylafon@w3.org</email>
53      <uri>http://www.raubacapeu.net/people/yves/</uri>
54    </address>
55  </author>
56
57  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
58    <organization abbrev="greenbytes">greenbytes GmbH</organization>
59    <address>
60      <postal>
61        <street>Hafenweg 16</street>
62        <city>Muenster</city><region>NW</region><code>48155</code>
63        <country>Germany</country>
64      </postal>
65      <phone>+49 251 2807760</phone>
66      <facsimile>+49 251 2807761</facsimile>
67      <email>julian.reschke@greenbytes.de</email>
68      <uri>http://greenbytes.de/tech/webdav/</uri>
69    </address>
70  </author>
71
72  <date month="March" year="2012" day="12"/>
73  <workgroup>HTTPbis Working Group</workgroup>
74
75<abstract>
76<t>
77   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
78   distributed, collaborative, hypertext information systems. HTTP has been in
79   use by the World Wide Web global information initiative since 1990. This
80   document is Part 1 of the seven-part specification that defines the protocol
81   referred to as "HTTP/1.1" and, taken together, obsoletes
82   RFC 2616 and moves it to historic
83   status, along with its predecessor RFC
84   2068.
85</t>
86<t>
87   Part 1 provides an overview of HTTP and its associated terminology, defines
88   the "http" and "https" Uniform Resource Identifier (URI) schemes, defines
89   the generic message syntax and parsing requirements for HTTP message frames,
90   and describes general security concerns for implementations.
91</t>
92<t>
93   This part also obsoletes RFCs 2145
94   (on HTTP version numbers) and 2817
95   (on using CONNECT for TLS upgrades) and moves them to historic status.
96</t>
97</abstract>
98
99<note title="Editorial Note (To be removed by RFC Editor)">
100  <t>
101    Discussion of this draft should take place on the HTTPBIS working group
102    mailing list (ietf-http-wg@w3.org), which is archived at
103    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
104  </t>
105  <t>
106    The current issues list is at
107    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
108    documents (including fancy diffs) can be found at
109    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
110  </t>
111  <t>
112    The changes in this draft are summarized in <xref target="changes.since.18"/>.
113  </t>
114</note>
115</front>
116<middle>
117<section title="Introduction" anchor="introduction">
118<t>
119   The Hypertext Transfer Protocol (HTTP) is an application-level
120   request/response protocol that uses extensible semantics and MIME-like
121   message payloads for flexible interaction with network-based hypertext
122   information systems. HTTP relies upon the Uniform Resource Identifier (URI)
123   standard <xref target="RFC3986"/> to indicate the target resource
124   (<xref target="target-resource"/>) and relationships between resources.
125   Messages are passed in a format similar to that used by Internet mail
126   <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
127   (MIME) <xref target="RFC2045"/> (see Appendix A of <xref target="Part3"/> for the differences
128   between HTTP and MIME messages).
129</t>
130<t>
131   HTTP is a generic interface protocol for information systems. It is
132   designed to hide the details of how a service is implemented by presenting
133   a uniform interface to clients that is independent of the types of
134   resources provided. Likewise, servers do not need to be aware of each
135   client's purpose: an HTTP request can be considered in isolation rather
136   than being associated with a specific type of client or a predetermined
137   sequence of application steps. The result is a protocol that can be used
138   effectively in many different contexts and for which implementations can
139   evolve independently over time.
140</t>
141<t>
142   HTTP is also designed for use as an intermediation protocol for translating
143   communication to and from non-HTTP information systems.
144   HTTP proxies and gateways can provide access to alternative information
145   services by translating their diverse protocols into a hypertext
146   format that can be viewed and manipulated by clients in the same way
147   as HTTP services.
148</t>
149<t>
150   One consequence of HTTP flexibility is that the protocol cannot be
151   defined in terms of what occurs behind the interface. Instead, we
152   are limited to defining the syntax of communication, the intent
153   of received communication, and the expected behavior of recipients.
154   If the communication is considered in isolation, then successful
155   actions ought to be reflected in corresponding changes to the
156   observable interface provided by servers. However, since multiple
157   clients might act in parallel and perhaps at cross-purposes, we
158   cannot require that such changes be observable beyond the scope
159   of a single response.
160</t>
161<t>
162   This document is Part 1 of the seven-part specification of HTTP,
163   defining the protocol referred to as "HTTP/1.1", obsoleting
164   <xref target="RFC2616"/> and <xref target="RFC2145"/>.
165   Part 1 describes the architectural elements that are used or
166   referred to in HTTP, defines the "http" and "https" URI schemes,
167   describes overall network operation and connection management,
168   and defines HTTP message framing and forwarding requirements.
169   Our goal is to define all of the mechanisms necessary for HTTP message
170   handling that are independent of message semantics, thereby defining the
171   complete set of requirements for message parsers and
172   message-forwarding intermediaries.
173</t>
174
175<section title="Requirement Notation" anchor="intro.requirements">
176<t>
177   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179   document are to be interpreted as described in <xref target="RFC2119"/>.
180</t>
181</section>
182
183<section title="Syntax Notation" anchor="notation">
184<iref primary="true" item="Grammar" subitem="ALPHA"/>
185<iref primary="true" item="Grammar" subitem="CR"/>
186<iref primary="true" item="Grammar" subitem="CRLF"/>
187<iref primary="true" item="Grammar" subitem="CTL"/>
188<iref primary="true" item="Grammar" subitem="DIGIT"/>
189<iref primary="true" item="Grammar" subitem="DQUOTE"/>
190<iref primary="true" item="Grammar" subitem="HEXDIG"/>
191<iref primary="true" item="Grammar" subitem="HTAB"/>
192<iref primary="true" item="Grammar" subitem="LF"/>
193<iref primary="true" item="Grammar" subitem="OCTET"/>
194<iref primary="true" item="Grammar" subitem="SP"/>
195<iref primary="true" item="Grammar" subitem="VCHAR"/>
196<t>
197   This specification uses the Augmented Backus-Naur Form (ABNF) notation
198   of <xref target="RFC5234"/> with the list rule extension defined in
199   <xref target="abnf.extension"/>.  <xref target="collected.abnf"/> shows
200   the collected ABNF with the list rule expanded.
201</t>
202<t anchor="core.rules">
203 
204 
205 
206 
207 
208 
209 
210 
211 
212 
213 
214 
215   The following core rules are included by
216   reference, as defined in <xref target="RFC5234"/>, Appendix B.1:
217   ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
218   DIGIT (decimal 0-9), DQUOTE (double quote),
219   HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed),
220   OCTET (any 8-bit sequence of data), SP (space), and
221   VCHAR (any visible <xref target="USASCII"/> character).
222</t>
223<t>
224   As a convention, ABNF rule names prefixed with "obs-" denote
225   "obsolete" grammar rules that appear for historical reasons.
226</t>
227</section>
228</section>
229
230<section title="Architecture" anchor="architecture">
231<t>
232   HTTP was created for the World Wide Web architecture
233   and has evolved over time to support the scalability needs of a worldwide
234   hypertext system. Much of that architecture is reflected in the terminology
235   and syntax productions used to define HTTP.
236</t>
237
238<section title="Client/Server Messaging" anchor="operation">
239<iref primary="true" item="client"/>
240<iref primary="true" item="server"/>
241<iref primary="true" item="connection"/>
242<t>
243   HTTP is a stateless request/response protocol that operates by exchanging
244   messages (<xref target="http.message"/>) across a reliable
245   transport or session-layer
246   "connection". An HTTP "client" is a
247   program that establishes a connection to a server for the purpose of
248   sending one or more HTTP requests.  An HTTP "server" is a
249   program that accepts connections in order to service HTTP requests by
250   sending HTTP responses.
251</t>
252<iref primary="true" item="user agent"/>
253<iref primary="true" item="origin server"/>
254<iref primary="true" item="browser"/>
255<iref primary="true" item="spider"/>
256<iref primary="true" item="sender"/>
257<iref primary="true" item="recipient"/>
258<t>
259   Note that the terms client and server refer only to the roles that
260   these programs perform for a particular connection.  The same program
261   might act as a client on some connections and a server on others.  We use
262   the term "user agent" to refer to the program that initiates a request,
263   such as a WWW browser, editor, or spider (web-traversing robot), and
264   the term "origin server" to refer to the program that can originate
265   authoritative responses to a request.  For general requirements, we use
266   the term "sender" to refer to whichever component sent a given message
267   and the term "recipient" to refer to any component that receives the
268   message.
269</t>
270<t><list>
271  <t>
272    Note: The term 'user agent' covers both those situations where
273    there is a user (human) interacting with the software agent (and for which
274    user interface or interactive suggestions might be made, e.g., warning the
275    user or given the user an option in the case of security or privacy
276    options) and also those where the software agent may act autonomously.
277  </t>
278</list></t>
279<t>
280   Most HTTP communication consists of a retrieval request (GET) for
281   a representation of some resource identified by a URI.  In the
282   simplest case, this might be accomplished via a single bidirectional
283   connection (===) between the user agent (UA) and the origin server (O).
284</t>
285<figure><artwork type="drawing"><![CDATA[
286         request   >
287    UA ======================================= O
288                                <   response
289]]></artwork></figure>
290<iref primary="true" item="message"/>
291<iref primary="true" item="request"/>
292<iref primary="true" item="response"/>
293<t>
294   A client sends an HTTP request to the server in the form of a request
295   message, beginning with a request-line that includes a method, URI, and
296   protocol version (<xref target="request.line"/>),
297   followed by MIME-like header fields containing
298   request modifiers, client information, and representation metadata
299   (<xref target="header.fields"/>),
300   an empty line to indicate the end of the header section, and finally
301   a message body containing the payload body (if any,
302   <xref target="message.body"/>).
303</t>
304<t>
305   A server responds to the client's request by sending one or more HTTP
306   response
307   messages, each beginning with a status line that
308   includes the protocol version, a success or error code, and textual
309   reason phrase (<xref target="status.line"/>),
310   possibly followed by MIME-like header fields containing server
311   information, resource metadata, and representation metadata
312   (<xref target="header.fields"/>),
313   an empty line to indicate the end of the header section, and finally
314   a message body containing the payload body (if any,
315   <xref target="message.body"/>).
316</t>
317<t>
318   The following example illustrates a typical message exchange for a
319   GET request on the URI "http://www.example.com/hello.txt":
320</t>
321<figure><preamble>
322client request:
323</preamble><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
324  GET /hello.txt HTTP/1.1
325  User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
326  Host: www.example.com
327  Accept: */*
328 
329  ]]></artwork></figure>
330<figure><preamble>
331server response:
332</preamble><artwork type="message/http; msgtype=&#34;response&#34;"><![CDATA[
333  HTTP/1.1 200 OK
334  Date: Mon, 27 Jul 2009 12:28:53 GMT
335  Server: Apache
336  Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
337  ETag: "34aa387-d-1568eb00"
338  Accept-Ranges: bytes
339  Content-Length: 14
340  Vary: Accept-Encoding
341  Content-Type: text/plain
342 
343  Hello World!
344  ]]></artwork></figure>
345</section>
346
347<section title="Connections and Transport Independence" anchor="transport-independence">
348<t>
349   HTTP messaging is independent of the underlying transport or
350   session-layer connection protocol(s).  HTTP only presumes a reliable
351   transport with in-order delivery of requests and the corresponding
352   in-order delivery of responses.  The mapping of HTTP request and
353   response structures onto the data units of the underlying transport
354   protocol is outside the scope of this specification.
355</t>
356<t>
357   The specific connection protocols to be used for an interaction
358   are determined by client configuration and the target URI
359   (<xref target="target-resource"/>).
360   For example, the "http" URI scheme
361   (<xref target="http.uri"/>) indicates a default connection of TCP
362   over IP, with a default TCP port of 80, but the client might be
363   configured to use a proxy via some other connection port or protocol
364   instead of using the defaults.
365</t>
366<t>
367   A connection might be used for multiple HTTP request/response exchanges,
368   as defined in <xref target="persistent.connections"/>.
369</t>
370</section>
371
372<section title="Intermediaries" anchor="intermediaries">
373<iref primary="true" item="intermediary"/>
374<t>
375   HTTP enables the use of intermediaries to satisfy requests through
376   a chain of connections.  There are three common forms of HTTP
377   intermediary: proxy, gateway, and tunnel.  In some cases,
378   a single intermediary might act as an origin server, proxy, gateway,
379   or tunnel, switching behavior based on the nature of each request.
380</t>
381<figure><artwork type="drawing"><![CDATA[
382         >             >             >             >
383    UA =========== A =========== B =========== C =========== O
384               <             <             <             <
385]]></artwork></figure>
386<t>
387   The figure above shows three intermediaries (A, B, and C) between the
388   user agent and origin server. A request or response message that
389   travels the whole chain will pass through four separate connections.
390   Some HTTP communication options
391   might apply only to the connection with the nearest, non-tunnel
392   neighbor, only to the end-points of the chain, or to all connections
393   along the chain. Although the diagram is linear, each participant might
394   be engaged in multiple, simultaneous communications. For example, B
395   might be receiving requests from many clients other than A, and/or
396   forwarding requests to servers other than C, at the same time that it
397   is handling A's request.
398</t>
399<t>
400<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
401<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
402   We use the terms "upstream" and "downstream"
403   to describe various requirements in relation to the directional flow of a
404   message: all messages flow from upstream to downstream.
405   Likewise, we use the terms inbound and outbound to refer to
406   directions in relation to the request path:
407   "inbound" means toward the origin server and
408   "outbound" means toward the user agent.
409</t>
410<t><iref primary="true" item="proxy"/>
411   A "proxy" is a message forwarding agent that is selected by the
412   client, usually via local configuration rules, to receive requests
413   for some type(s) of absolute URI and attempt to satisfy those
414   requests via translation through the HTTP interface.  Some translations
415   are minimal, such as for proxy requests for "http" URIs, whereas
416   other requests might require translation to and from entirely different
417   application-layer protocols. Proxies are often used to group an
418   organization's HTTP requests through a common intermediary for the
419   sake of security, annotation services, or shared caching.
420</t>
421<t>
422<iref primary="true" item="transforming proxy"/>
423<iref primary="true" item="non-transforming proxy"/>
424   An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed
425   or configured to modify request or response messages in a semantically
426   meaningful way (i.e., modifications, beyond those required by normal
427   HTTP processing, that change the message in a way that would be
428   significant to the original sender or potentially significant to
429   downstream recipients).  For example, a transforming proxy might be
430   acting as a shared annotation server (modifying responses to include
431   references to a local annotation database), a malware filter, a
432   format transcoder, or an intranet-to-Internet privacy filter.  Such
433   transformations are presumed to be desired by the client (or client
434   organization) that selected the proxy and are beyond the scope of
435   this specification.  However, when a proxy is not intended to transform
436   a given message, we use the term "non-transforming proxy" to target
437   requirements that preserve HTTP message semantics. See Section 7.2.4 of <xref target="Part2"/> and
438   Section 3.6 of <xref target="Part6"/> for status and warning codes related to transformations.
439</t>
440<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
441<iref primary="true" item="accelerator"/>
442   A "gateway" (a.k.a., "reverse proxy")
443   is a receiving agent that acts
444   as a layer above some other server(s) and translates the received
445   requests to the underlying server's protocol.  Gateways are often
446   used to encapsulate legacy or untrusted information services, to
447   improve server performance through "accelerator" caching, and to
448   enable partitioning or load-balancing of HTTP services across
449   multiple machines.
450</t>
451<t>
452   A gateway behaves as an origin server on its outbound connection and
453   as a user agent on its inbound connection.
454   All HTTP requirements applicable to an origin server
455   also apply to the outbound communication of a gateway.
456   A gateway communicates with inbound servers using any protocol that
457   it desires, including private extensions to HTTP that are outside
458   the scope of this specification.  However, an HTTP-to-HTTP gateway
459   that wishes to interoperate with third-party HTTP servers MUST
460   conform to HTTP user agent requirements on the gateway's inbound
461   connection and MUST implement the Connection
462   (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)
463   header fields for both connections.
464</t>
465<t><iref primary="true" item="tunnel"/>
466   A "tunnel" acts as a blind relay between two connections
467   without changing the messages. Once active, a tunnel is not
468   considered a party to the HTTP communication, though the tunnel might
469   have been initiated by an HTTP request. A tunnel ceases to exist when
470   both ends of the relayed connection are closed. Tunnels are used to
471   extend a virtual connection through an intermediary, such as when
472   transport-layer security is used to establish private communication
473   through a shared firewall proxy.
474</t>
475<t><iref primary="true" item="interception proxy"/><iref primary="true" item="transparent proxy"/>
476<iref primary="true" item="captive portal"/>
477   In addition, there may exist network intermediaries that are not
478   considered part of the HTTP communication but nevertheless act as
479   filters or redirecting agents (usually violating HTTP semantics,
480   causing security problems, and otherwise making a mess of things).
481   Such a network intermediary, often referred to as an "interception proxy"
482   <xref target="RFC3040"/>, "transparent proxy" <xref target="RFC1919"/>,
483   or "captive portal",
484   differs from an HTTP proxy because it has not been selected by the client.
485   Instead, the network intermediary redirects outgoing TCP port 80 packets
486   (and occasionally other common port traffic) to an internal HTTP server.
487   Interception proxies are commonly found on public network access points,
488   as a means of enforcing account subscription prior to allowing use of
489   non-local Internet services, and within corporate firewalls to enforce
490   network usage policies.
491   They are indistinguishable from a man-in-the-middle attack.
492</t>
493<t>
494   HTTP is defined as a stateless protocol, meaning that each request message
495   can be understood in isolation.  Many implementations depend on HTTP's
496   stateless design in order to reuse proxied connections or dynamically
497   load balance requests across multiple servers.  Hence, servers MUST NOT
498   assume that two requests on the same connection are from the same user
499   agent unless the connection is secured and specific to that agent.
500   Some non-standard HTTP extensions (e.g., <xref target="RFC4559"/>) have
501   been known to violate this requirement, resulting in security and
502   interoperability problems.
503</t>
504</section>
505
506<section title="Caches" anchor="caches">
507<iref primary="true" item="cache"/>
508<t>
509   A "cache" is a local store of previous response messages and the
510   subsystem that controls its message storage, retrieval, and deletion.
511   A cache stores cacheable responses in order to reduce the response
512   time and network bandwidth consumption on future, equivalent
513   requests. Any client or server MAY employ a cache, though a cache
514   cannot be used by a server while it is acting as a tunnel.
515</t>
516<t>
517   The effect of a cache is that the request/response chain is shortened
518   if one of the participants along the chain has a cached response
519   applicable to that request. The following illustrates the resulting
520   chain if B has a cached copy of an earlier response from O (via C)
521   for a request which has not been cached by UA or A.
522</t>
523<figure><artwork type="drawing"><![CDATA[
524            >             >
525       UA =========== A =========== B - - - - - - C - - - - - - O
526                  <             <
527]]></artwork></figure>
528<t><iref primary="true" item="cacheable"/>
529   A response is "cacheable" if a cache is allowed to store a copy of
530   the response message for use in answering subsequent requests.
531   Even when a response is cacheable, there might be additional
532   constraints placed by the client or by the origin server on when
533   that cached response can be used for a particular request. HTTP
534   requirements for cache behavior and cacheable responses are
535   defined in Section 2 of <xref target="Part6"/>. 
536</t>
537<t>
538   There are a wide variety of architectures and configurations
539   of caches and proxies deployed across the World Wide Web and
540   inside large organizations. These systems include national hierarchies
541   of proxy caches to save transoceanic bandwidth, systems that
542   broadcast or multicast cache entries, organizations that distribute
543   subsets of cached data via optical media, and so on.
544</t>
545</section>
546
547<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
548<t>
549   This specification targets conformance criteria according to the role of
550   a participant in HTTP communication.  Hence, HTTP requirements are placed
551   on senders, recipients, clients, servers, user agents, intermediaries,
552   origin servers, proxies, gateways, or caches, depending on what behavior
553   is being constrained by the requirement.
554</t>
555<t>
556   An implementation is considered conformant if it complies with all of the
557   requirements associated with the roles it partakes in HTTP.
558</t>
559<t>
560   Senders MUST NOT generate protocol elements that do not match the grammar
561   defined by the ABNF rules for those protocol elements.
562</t>
563<t>
564   Unless otherwise noted, recipients MAY attempt to recover a usable
565   protocol element from an invalid construct.  HTTP does not define
566   specific error handling mechanisms except when they have a direct impact
567   on security, since different applications of the protocol require
568   different error handling strategies.  For example, a Web browser might
569   wish to transparently recover from a response where the Location header
570   field doesn't parse according to the ABNF, whereas a systems control
571   client might consider any form of error recovery to be dangerous.
572</t>
573</section>
574
575<section title="Protocol Versioning" anchor="http.version">
576 
577 
578<t>
579   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate
580   versions of the protocol. This specification defines version "1.1".
581   The protocol version as a whole indicates the sender's conformance
582   with the set of requirements laid out in that version's corresponding
583   specification of HTTP.
584</t>
585<t>
586   The version of an HTTP message is indicated by an HTTP-version field
587   in the first line of the message. HTTP-version is case-sensitive.
588</t>
589<figure><iref primary="true" item="Grammar" subitem="HTTP-version"/><iref primary="true" item="Grammar" subitem="HTTP-name"/><artwork type="abnf2616"><![CDATA[
590  HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
591  HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
592]]></artwork></figure>
593<t>
594   The HTTP version number consists of two decimal digits separated by a "."
595   (period or decimal point).  The first digit ("major version") indicates the
596   HTTP messaging syntax, whereas the second digit ("minor version") indicates
597   the highest minor version to which the sender is
598   conformant and able to understand for future communication.  The minor
599   version advertises the sender's communication capabilities even when the
600   sender is only using a backwards-compatible subset of the protocol,
601   thereby letting the recipient know that more advanced features can
602   be used in response (by servers) or in future requests (by clients).
603</t>
604<t>
605   When an HTTP/1.1 message is sent to an HTTP/1.0 recipient
606   <xref target="RFC1945"/> or a recipient whose version is unknown,
607   the HTTP/1.1 message is constructed such that it can be interpreted
608   as a valid HTTP/1.0 message if all of the newer features are ignored.
609   This specification places recipient-version requirements on some
610   new features so that a conformant sender will only use compatible
611   features until it has determined, through configuration or the
612   receipt of a message, that the recipient supports HTTP/1.1.
613</t>
614<t>
615   The interpretation of a header field does not change between minor
616   versions of the same major HTTP version, though the default
617   behavior of a recipient in the absence of such a field can change.
618   Unless specified otherwise, header fields defined in HTTP/1.1 are
619   defined for all versions of HTTP/1.x.  In particular, the Host and
620   Connection header fields ought to be implemented by all HTTP/1.x
621   implementations whether or not they advertise conformance with HTTP/1.1.
622</t>
623<t>
624   New header fields can be defined such that, when they are
625   understood by a recipient, they might override or enhance the
626   interpretation of previously defined header fields.  When an
627   implementation receives an unrecognized header field, the recipient
628   MUST ignore that header field for local processing regardless of
629   the message's HTTP version.  An unrecognized header field received
630   by a proxy MUST be forwarded downstream unless the header field's
631   field-name is listed in the message's Connection header-field
632   (see <xref target="header.connection"/>).
633   These requirements allow HTTP's functionality to be enhanced without
634   requiring prior update of deployed intermediaries.
635</t>
636<t>
637   Intermediaries that process HTTP messages (i.e., all intermediaries
638   other than those acting as tunnels) MUST send their own HTTP-version
639   in forwarded messages.  In other words, they MUST NOT blindly
640   forward the first line of an HTTP message without ensuring that the
641   protocol version in that message matches a version to which that
642   intermediary is conformant for both the receiving and
643   sending of messages.  Forwarding an HTTP message without rewriting
644   the HTTP-version might result in communication errors when downstream
645   recipients use the message sender's version to determine what features
646   are safe to use for later communication with that sender.
647</t>
648<t>
649   An HTTP client SHOULD send a request version equal to the highest
650   version to which the client is conformant and
651   whose major version is no higher than the highest version supported
652   by the server, if this is known.  An HTTP client MUST NOT send a
653   version to which it is not conformant.
654</t>
655<t>
656   An HTTP client MAY send a lower request version if it is known that
657   the server incorrectly implements the HTTP specification, but only
658   after the client has attempted at least one normal request and determined
659   from the response status or header fields (e.g., Server) that the
660   server improperly handles higher request versions.
661</t>
662<t>
663   An HTTP server SHOULD send a response version equal to the highest
664   version to which the server is conformant and
665   whose major version is less than or equal to the one received in the
666   request.  An HTTP server MUST NOT send a version to which it is not
667   conformant.  A server MAY send a 505 (HTTP
668   Version Not Supported) response if it cannot send a response using the
669   major version used in the client's request.
670</t>
671<t>
672   An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request
673   if it is known or suspected that the client incorrectly implements the
674   HTTP specification and is incapable of correctly processing later
675   version responses, such as when a client fails to parse the version
676   number correctly or when an intermediary is known to blindly forward
677   the HTTP-version even when it doesn't conform to the given minor
678   version of the protocol. Such protocol downgrades SHOULD NOT be
679   performed unless triggered by specific client attributes, such as when
680   one or more of the request header fields (e.g., User-Agent) uniquely
681   match the values sent by a client known to be in error.
682</t>
683<t>
684   The intention of HTTP's versioning design is that the major number
685   will only be incremented if an incompatible message syntax is
686   introduced, and that the minor number will only be incremented when
687   changes made to the protocol have the effect of adding to the message
688   semantics or implying additional capabilities of the sender.  However,
689   the minor version was not incremented for the changes introduced between
690   <xref target="RFC2068"/> and <xref target="RFC2616"/>, and this revision
691   is specifically avoiding any such changes to the protocol.
692</t>
693</section>
694
695<section title="Uniform Resource Identifiers" anchor="uri">
696<iref primary="true" item="resource"/>
697<t>
698   Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used
699   throughout HTTP as the means for identifying resources. URI references
700   are used to target requests, indicate redirects, and define relationships.
701   HTTP does not limit what a resource might be; it merely defines an interface
702   that can be used to interact with a resource via HTTP. More information on
703   the scope of URIs and resources can be found in <xref target="RFC3986"/>.
704</t>
705 
706 
707 
708 
709 
710 
711 
712 
713 
714 
715<t>
716   This specification adopts the definitions of "URI-reference",
717   "absolute-URI", "relative-part", "port", "host",
718   "path-abempty", "path-absolute", "query", and "authority" from the
719   URI generic syntax <xref target="RFC3986"/>.
720   In addition, we define a partial-URI rule for protocol elements
721   that allow a relative URI but not a fragment.
722</t>
723<figure><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/><artwork type="abnf2616"><![CDATA[
724  URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
725  absolute-URI  = <absolute-URI, defined in [RFC3986], Section 4.3>
726  relative-part = <relative-part, defined in [RFC3986], Section 4.2>
727  authority     = <authority, defined in [RFC3986], Section 3.2>
728  path-abempty  = <path-abempty, defined in [RFC3986], Section 3.3>
729  path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
730  port          = <port, defined in [RFC3986], Section 3.2.3>
731  query         = <query, defined in [RFC3986], Section 3.4>
732  uri-host      = <host, defined in [RFC3986], Section 3.2.2>
733 
734  partial-URI   = relative-part [ "?" query ]
735]]></artwork></figure>
736<t>
737   Each protocol element in HTTP that allows a URI reference will indicate
738   in its ABNF production whether the element allows any form of reference
739   (URI-reference), only a URI in absolute form (absolute-URI), only the
740   path and optional query components, or some combination of the above.
741   Unless otherwise indicated, URI references are parsed
742   relative to the effective request URI
743   (<xref target="effective.request.uri"/>).
744</t>
745
746<section title="http URI scheme" anchor="http.uri">
747 
748  <iref item="http URI scheme" primary="true"/>
749  <iref item="URI scheme" subitem="http" primary="true"/>
750<t>
751   The "http" URI scheme is hereby defined for the purpose of minting
752   identifiers according to their association with the hierarchical
753   namespace governed by a potential HTTP origin server listening for
754   TCP connections on a given port.
755</t>
756<figure><iref primary="true" item="Grammar" subitem="http-URI"/><artwork type="abnf2616"><![CDATA[
757  http-URI = "http:" "//" authority path-abempty [ "?" query ]
758]]></artwork></figure>
759<t>
760   The HTTP origin server is identified by the generic syntax's
761   <xref target="uri" format="none">authority</xref> component, which includes a host identifier
762   and optional TCP port (<xref target="RFC3986"/>, Section 3.2.2).
763   The remainder of the URI, consisting of both the hierarchical path
764   component and optional query component, serves as an identifier for
765   a potential resource within that origin server's name space.
766</t>
767<t>
768   If the host identifier is provided as an IP literal or IPv4 address,
769   then the origin server is any listener on the indicated TCP port at
770   that IP address. If host is a registered name, then that name is
771   considered an indirect identifier and the recipient might use a name
772   resolution service, such as DNS, to find the address of a listener
773   for that host.
774   The host MUST NOT be empty; if an "http" URI is received with an
775   empty host, then it MUST be rejected as invalid.
776   If the port subcomponent is empty or not given, then TCP port 80 is
777   assumed (the default reserved port for WWW services).
778</t>
779<t>
780   Regardless of the form of host identifier, access to that host is not
781   implied by the mere presence of its name or address. The host might or might
782   not exist and, even when it does exist, might or might not be running an
783   HTTP server or listening to the indicated port. The "http" URI scheme
784   makes use of the delegated nature of Internet names and addresses to
785   establish a naming authority (whatever entity has the ability to place
786   an HTTP server at that Internet name or address) and allows that
787   authority to determine which names are valid and how they might be used.
788</t>
789<t>
790   When an "http" URI is used within a context that calls for access to the
791   indicated resource, a client MAY attempt access by resolving
792   the host to an IP address, establishing a TCP connection to that address
793   on the indicated port, and sending an HTTP request message
794   (<xref target="http.message"/>) containing the URI's identifying data
795   (<xref target="message.routing"/>) to the server.
796   If the server responds to that request with a non-interim HTTP response
797   message, as described in Section 4 of <xref target="Part2"/>, then that response
798   is considered an authoritative answer to the client's request.
799</t>
800<t>
801   Although HTTP is independent of the transport protocol, the "http"
802   scheme is specific to TCP-based services because the name delegation
803   process depends on TCP for establishing authority.
804   An HTTP service based on some other underlying connection protocol
805   would presumably be identified using a different URI scheme, just as
806   the "https" scheme (below) is used for servers that require an SSL/TLS
807   transport layer on a connection. Other protocols might also be used to
808   provide access to "http" identified resources — it is only the
809   authoritative interface used for mapping the namespace that is
810   specific to TCP.
811</t>
812<t>
813   The URI generic syntax for authority also includes a deprecated
814   userinfo subcomponent (<xref target="RFC3986"/>, Section 3.2.1)
815   for including user authentication information in the URI.  Some
816   implementations make use of the userinfo component for internal
817   configuration of authentication information, such as within command
818   invocation options, configuration files, or bookmark lists, even
819   though such usage might expose a user identifier or password.
820   Senders MUST NOT include a userinfo subcomponent (and its "@"
821   delimiter) when transmitting an "http" URI in a message.  Recipients
822   of HTTP messages that contain a URI reference SHOULD parse for the
823   existence of userinfo and treat its presence as an error, likely
824   indicating that the deprecated subcomponent is being used to obscure
825   the authority for the sake of phishing attacks.
826</t>
827</section>
828
829<section title="https URI scheme" anchor="https.uri">
830   
831   <iref item="https URI scheme"/>
832   <iref item="URI scheme" subitem="https"/>
833<t>
834   The "https" URI scheme is hereby defined for the purpose of minting
835   identifiers according to their association with the hierarchical
836   namespace governed by a potential HTTP origin server listening for
837   SSL/TLS-secured connections on a given TCP port.
838</t>
839<t>
840   All of the requirements listed above for the "http" scheme are also
841   requirements for the "https" scheme, except that a default TCP port
842   of 443 is assumed if the port subcomponent is empty or not given,
843   and the TCP connection MUST be secured for privacy through the
844   use of strong encryption prior to sending the first HTTP request.
845</t>
846<figure><iref primary="true" item="Grammar" subitem="https-URI"/><artwork type="abnf2616"><![CDATA[
847  https-URI = "https:" "//" authority path-abempty [ "?" query ]
848]]></artwork></figure>
849<t>
850   Unlike the "http" scheme, responses to "https" identified requests
851   are never "public" and thus MUST NOT be reused for shared caching.
852   They can, however, be reused in a private cache if the message is
853   cacheable by default in HTTP or specifically indicated as such by
854   the Cache-Control header field (Section 3.2 of <xref target="Part6"/>).
855</t>
856<t>
857   Resources made available via the "https" scheme have no shared
858   identity with the "http" scheme even if their resource identifiers
859   indicate the same authority (the same host listening to the same
860   TCP port).  They are distinct name spaces and are considered to be
861   distinct origin servers.  However, an extension to HTTP that is
862   defined to apply to entire host domains, such as the Cookie protocol
863   <xref target="RFC6265"/>, can allow information
864   set by one service to impact communication with other services
865   within a matching group of host domains.
866</t>
867<t>
868   The process for authoritative access to an "https" identified
869   resource is defined in <xref target="RFC2818"/>.
870</t>
871</section>
872
873<section title="http and https URI Normalization and Comparison" anchor="uri.comparison">
874<t>
875   Since the "http" and "https" schemes conform to the URI generic syntax,
876   such URIs are normalized and compared according to the algorithm defined
877   in <xref target="RFC3986"/>, Section 6, using the defaults
878   described above for each scheme.
879</t>
880<t>
881   If the port is equal to the default port for a scheme, the normal
882   form is to elide the port subcomponent. Likewise, an empty path
883   component is equivalent to an absolute path of "/", so the normal
884   form is to provide a path of "/" instead. The scheme and host
885   are case-insensitive and normally provided in lowercase; all
886   other components are compared in a case-sensitive manner.
887   Characters other than those in the "reserved" set are equivalent
888   to their percent-encoded octets (see <xref target="RFC3986"/>, Section 2.1): the normal form is to not encode them.
889</t>
890<t>
891   For example, the following three URIs are equivalent:
892</t>
893<figure><artwork type="example"><![CDATA[
894   http://example.com:80/~smith/home.html
895   http://EXAMPLE.com/%7Esmith/home.html
896   http://EXAMPLE.com:/%7esmith/home.html
897]]></artwork></figure>
898</section>
899</section>
900</section>
901
902<section title="Message Format" anchor="http.message">
903
904
905
906
907<iref item="header section"/>
908<iref item="headers"/>
909<iref item="header field"/>
910<t>
911   All HTTP/1.1 messages consist of a start-line followed by a sequence of
912   octets in a format similar to the Internet Message Format
913   <xref target="RFC5322"/>: zero or more header fields (collectively
914   referred to as the "headers" or the "header section"), an empty line
915   indicating the end of the header section, and an optional message body.
916</t>
917<figure><iref primary="true" item="Grammar" subitem="HTTP-message"/><artwork type="abnf2616"><![CDATA[
918  HTTP-message   = start-line
919                   *( header-field CRLF )
920                   CRLF
921                   [ message-body ]
922]]></artwork></figure>
923<t>
924   The normal procedure for parsing an HTTP message is to read the
925   start-line into a structure, read each header field into a hash
926   table by field name until the empty line, and then use the parsed
927   data to determine if a message body is expected.  If a message body
928   has been indicated, then it is read as a stream until an amount
929   of octets equal to the message body length is read or the connection
930   is closed.
931</t>
932<t>
933   Recipients MUST parse an HTTP message as a sequence of octets in an
934   encoding that is a superset of US-ASCII <xref target="USASCII"/>.
935   Parsing an HTTP message as a stream of Unicode characters, without regard
936   for the specific encoding, creates security vulnerabilities due to the
937   varying ways that string processing libraries handle invalid multibyte
938   character sequences that contain the octet LF (%x0A).  String-based
939   parsers can only be safely used within protocol elements after the element
940   has been extracted from the message, such as within a header field-value
941   after message parsing has delineated the individual fields.
942</t>
943<t>
944   An HTTP message can be parsed as a stream for incremental processing or
945   forwarding downstream.  However, recipients cannot rely on incremental
946   delivery of partial messages, since some implementations will buffer or
947   delay message forwarding for the sake of network efficiency, security
948   checks, or payload transformations.
949</t>
950
951<section title="Start Line" anchor="start.line">
952 
953<t>
954   An HTTP message can either be a request from client to server or a
955   response from server to client.  Syntactically, the two types of message
956   differ only in the start-line, which is either a request-line (for requests)
957   or a status-line (for responses), and in the algorithm for determining
958   the length of the message body (<xref target="message.body"/>).
959   In theory, a client could receive requests and a server could receive
960   responses, distinguishing them by their different start-line formats,
961   but in practice servers are implemented to only expect a request
962   (a response is interpreted as an unknown or invalid request method)
963   and clients are implemented to only expect a response.
964</t>
965<figure><iref primary="true" item="Grammar" subitem="start-line"/><artwork type="abnf2616"><![CDATA[
966  start-line     = request-line / status-line
967]]></artwork></figure>
968<t>
969</t>
970<t>
971   Implementations MUST NOT send whitespace between the start-line and
972   the first header field. The presence of such whitespace in a request
973   might be an attempt to trick a server into ignoring that field or
974   processing the line after it as a new request, either of which might
975   result in a security vulnerability if other implementations within
976   the request chain interpret the same message differently.
977   Likewise, the presence of such whitespace in a response might be
978   ignored by some clients or cause others to cease parsing.
979</t>
980
981<section title="Request Line" anchor="request.line">
982 
983 
984<t>
985   A request-line begins with a method token, followed by a single
986   space (SP), the request-target, another single space (SP), the
987   protocol version, and ending with CRLF.
988</t>
989<figure><iref primary="true" item="Grammar" subitem="request-line"/><artwork type="abnf2616"><![CDATA[
990  request-line   = method SP request-target SP HTTP-version CRLF
991]]></artwork></figure>
992<iref primary="true" item="method"/>
993<t anchor="method">
994   The method token indicates the request method to be performed on the
995   target resource. The request method is case-sensitive.
996</t>
997<figure><iref primary="true" item="Grammar" subitem="method"/><artwork type="abnf2616"><![CDATA[
998  method         = token
999]]></artwork></figure>
1000<t>
1001   The methods defined by this specification can be found in
1002   Section 2 of <xref target="Part2"/>, along with information regarding the HTTP method registry
1003   and considerations for defining new methods.
1004</t>
1005<iref item="request-target"/>
1006<t>
1007   The request-target identifies the target resource upon which to apply
1008   the request, as defined in <xref target="request-target"/>.
1009</t>
1010<t>
1011   No whitespace is allowed inside the method, request-target, and
1012   protocol version.  Hence, recipients typically parse the request-line
1013   into its component parts by splitting on the SP characters.
1014</t>
1015<t>
1016   Unfortunately, some user agents fail to properly encode hypertext
1017   references that have embedded whitespace, sending the characters
1018   directly instead of properly percent-encoding the disallowed characters.
1019   Recipients of an invalid request-line SHOULD respond with either a
1020   400 (Bad Request) error or a 301 (Moved Permanently) redirect with the
1021   request-target properly encoded.  Recipients SHOULD NOT attempt to
1022   autocorrect and then process the request without a redirect, since the
1023   invalid request-line might be deliberately crafted to bypass
1024   security filters along the request chain.
1025</t>
1026<t>
1027   HTTP does not place a pre-defined limit on the length of a request-line.
1028   A server that receives a method longer than any that it implements
1029   SHOULD respond with either a 404 (Not Allowed), if it is an origin
1030   server, or a 501 (Not Implemented) status code.
1031   A server MUST be prepared to receive URIs of unbounded length and
1032   respond with the 414 (URI Too Long) status code if the received
1033   request-target would be longer than the server wishes to handle
1034   (see Section 7.4.12 of <xref target="Part2"/>).
1035</t>
1036<t>
1037   Various ad-hoc limitations on request-line length are found in practice.
1038   It is RECOMMENDED that all HTTP senders and recipients support, at a
1039   minimum, request-line lengths of up to 8000 octets.
1040</t>
1041</section>
1042
1043<section title="Status Line" anchor="status.line">
1044 
1045 
1046<t>
1047   The first line of a response message is the status-line, consisting
1048   of the protocol version, a space (SP), the status code, another space,
1049   a possibly-empty textual phrase describing the status code, and
1050   ending with CRLF.
1051</t>
1052<figure><iref primary="true" item="Grammar" subitem="status-line"/><artwork type="abnf2616"><![CDATA[
1053  status-line = HTTP-version SP status-code SP reason-phrase CRLF
1054]]></artwork></figure>
1055
1056<t anchor="status-code">
1057   The status-code element is a 3-digit integer result code of the attempt to
1058   understand and satisfy the request. See Section 4 of <xref target="Part2"/> for
1059   further information, such as the list of status codes defined by this
1060   specification, the IANA registry, and considerations for new status codes.
1061</t>
1062<figure><iref primary="true" item="Grammar" subitem="status-code"/><artwork type="abnf2616"><![CDATA[
1063  status-code    = 3DIGIT
1064]]></artwork></figure>
1065
1066<t anchor="reason-phrase">  
1067   The reason-phrase element exists for the sole purpose of providing a
1068   textual description associated with the numeric status code, mostly
1069   out of deference to earlier Internet application protocols that were more
1070   frequently used with interactive text clients. A client SHOULD ignore
1071   the reason-phrase content.
1072</t>
1073<figure><iref primary="true" item="Grammar" subitem="reason-phrase"/><artwork type="abnf2616"><![CDATA[
1074  reason-phrase  = *( HTAB / SP / VCHAR / obs-text )
1075]]></artwork></figure>
1076</section>
1077</section>
1078
1079<section title="Header Fields" anchor="header.fields">
1080 
1081 
1082 
1083 
1084 
1085<t>
1086   Each HTTP header field consists of a case-insensitive field name
1087   followed by a colon (":"), optional whitespace, and the field value.
1088</t>
1089<figure><iref primary="true" item="Grammar" subitem="header-field"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/><iref primary="true" item="Grammar" subitem="obs-fold"/><artwork type="abnf2616"><![CDATA[
1090  header-field   = field-name ":" OWS field-value BWS
1091  field-name     = token
1092  field-value    = *( field-content / obs-fold )
1093  field-content  = *( HTAB / SP / VCHAR / obs-text )
1094  obs-fold       = CRLF ( SP / HTAB )
1095                 ; obsolete line folding
1096                 ; see Section 3.2.2
1097]]></artwork></figure>
1098<t>
1099   The field-name token labels the corresponding field-value as having the
1100   semantics defined by that header field.  For example, the Date header field
1101   is defined in Section 10.2 of <xref target="Part2"/> as containing the origination
1102   timestamp for the message in which it appears.
1103</t>
1104<t>
1105   HTTP header fields are fully extensible: there is no limit on the
1106   introduction of new field names, each presumably defining new semantics,
1107   or on the number of header fields used in a given message.  Existing
1108   fields are defined in each part of this specification and in many other
1109   specifications outside the standards process.
1110   New header fields can be introduced without changing the protocol version
1111   if their defined semantics allow them to be safely ignored by recipients
1112   that do not recognize them.
1113</t>
1114<t>
1115   New HTTP header fields SHOULD be registered with IANA according
1116   to the procedures in Section 3.1 of <xref target="Part2"/>.
1117   Unrecognized header fields MUST be forwarded by a proxy unless the
1118   field-name is listed in the Connection header field
1119   (<xref target="header.connection"/>) or the proxy is specifically
1120   configured to block or otherwise transform such fields.
1121   Unrecognized header fields SHOULD be ignored by other recipients.
1122</t>
1123<t>
1124   The order in which header fields with differing field names are
1125   received is not significant. However, it is "good practice" to send
1126   header fields that contain control data first, such as Host on
1127   requests and Date on responses, so that implementations can decide
1128   when not to handle a message as early as possible.  A server MUST
1129   wait until the entire header section is received before interpreting
1130   a request message, since later header fields might include conditionals,
1131   authentication credentials, or deliberately misleading duplicate
1132   header fields that would impact request processing.
1133</t>
1134<t>
1135   Multiple header fields with the same field name MUST NOT be
1136   sent in a message unless the entire field value for that
1137   header field is defined as a comma-separated list [i.e., #(values)].
1138   Multiple header fields with the same field name can be combined into
1139   one "field-name: field-value" pair, without changing the semantics of the
1140   message, by appending each subsequent field value to the combined
1141   field value in order, separated by a comma. The order in which
1142   header fields with the same field name are received is therefore
1143   significant to the interpretation of the combined field value;
1144   a proxy MUST NOT change the order of these field values when
1145   forwarding a message.
1146</t>
1147<t><list>
1148  <t>
1149   Note: The "Set-Cookie" header field as implemented in
1150   practice can occur multiple times, but does not use the list syntax, and
1151   thus cannot be combined into a single line (<xref target="RFC6265"/>). (See Appendix A.2.3 of <xref target="Kri2001"/>
1152   for details.) Also note that the Set-Cookie2 header field specified in
1153   <xref target="RFC2965"/> does not share this problem.
1154  </t>
1155</list></t>
1156
1157<section title="Whitespace" anchor="whitespace">
1158<t anchor="rule.LWS">
1159   This specification uses three rules to denote the use of linear
1160   whitespace: OWS (optional whitespace), RWS (required whitespace), and
1161   BWS ("bad" whitespace).
1162</t>
1163<t anchor="rule.OWS">
1164   The OWS rule is used where zero or more linear whitespace octets might
1165   appear. OWS SHOULD either not be produced or be produced as a single
1166   SP. Multiple OWS octets that occur within field-content SHOULD either
1167   be replaced with a single SP or transformed to all SP octets (each
1168   octet other than SP replaced with SP) before interpreting the field value
1169   or forwarding the message downstream.
1170</t>
1171<t anchor="rule.RWS">
1172   RWS is used when at least one linear whitespace octet is required to
1173   separate field tokens. RWS SHOULD be produced as a single SP.
1174   Multiple RWS octets that occur within field-content SHOULD either
1175   be replaced with a single SP or transformed to all SP octets before
1176   interpreting the field value or forwarding the message downstream.
1177</t>
1178<t anchor="rule.BWS">
1179   BWS is used where the grammar allows optional whitespace for historical
1180   reasons but senders SHOULD NOT produce it in messages. HTTP/1.1
1181   recipients MUST accept such bad optional whitespace and remove it before
1182   interpreting the field value or forwarding the message downstream.
1183</t>
1184<t anchor="rule.whitespace">
1185 
1186 
1187 
1188</t>
1189<figure><iref primary="true" item="Grammar" subitem="OWS"/><iref primary="true" item="Grammar" subitem="RWS"/><iref primary="true" item="Grammar" subitem="BWS"/><artwork type="abnf2616"><![CDATA[
1190  OWS            = *( SP / HTAB )
1191                 ; "optional" whitespace
1192  RWS            = 1*( SP / HTAB )
1193                 ; "required" whitespace
1194  BWS            = OWS
1195                 ; "bad" whitespace
1196]]></artwork></figure>
1197</section>
1198
1199<section title="Field Parsing" anchor="field.parsing">
1200<t>
1201   No whitespace is allowed between the header field-name and colon.
1202   In the past, differences in the handling of such whitespace have led to
1203   security vulnerabilities in request routing and response handling.
1204   Any received request message that contains whitespace between a header
1205   field-name and colon MUST be rejected with a response code of 400
1206   (Bad Request).  A proxy MUST remove any such whitespace from a response
1207   message before forwarding the message downstream.
1208</t>
1209<t>
1210   A field value MAY be preceded by optional whitespace (OWS); a single SP is
1211   preferred. The field value does not include any leading or trailing white
1212   space: OWS occurring before the first non-whitespace octet of the
1213   field value or after the last non-whitespace octet of the field value
1214   is ignored and SHOULD be removed before further processing (as this does
1215   not change the meaning of the header field).
1216</t>
1217<t>
1218   Historically, HTTP header field values could be extended over multiple
1219   lines by preceding each extra line with at least one space or horizontal
1220   tab (obs-fold). This specification deprecates such line
1221   folding except within the message/http media type
1222   (<xref target="internet.media.type.message.http"/>).
1223   HTTP senders MUST NOT produce messages that include line folding
1224   (i.e., that contain any field-value that matches the obs-fold rule) unless
1225   the message is intended for packaging within the message/http media type.
1226   HTTP recipients SHOULD accept line folding and replace any embedded
1227   obs-fold whitespace with either a single SP or a matching number of SP
1228   octets (to avoid buffer copying) prior to interpreting the field value or
1229   forwarding the message downstream.
1230</t>
1231<t>
1232   Historically, HTTP has allowed field content with text in the ISO-8859-1
1233   <xref target="ISO-8859-1"/> character encoding and supported other
1234   character sets only through use of <xref target="RFC2047"/> encoding.
1235   In practice, most HTTP header field values use only a subset of the
1236   US-ASCII character encoding <xref target="USASCII"/>. Newly defined
1237   header fields SHOULD limit their field values to US-ASCII octets.
1238   Recipients SHOULD treat other (obs-text) octets in field content as
1239   opaque data.
1240</t>
1241</section>
1242
1243<section title="Field Length" anchor="field.length">
1244<t>
1245   HTTP does not place a pre-defined limit on the length of header fields,
1246   either in isolation or as a set. A server MUST be prepared to receive
1247   request header fields of unbounded length and respond with a 4xx status
1248   code if the received header field(s) would be longer than the server wishes
1249   to handle.
1250</t>
1251<t>
1252   A client that receives response headers that are longer than it wishes to
1253   handle can only treat it as a server error.
1254</t>
1255<t>
1256   Various ad-hoc limitations on header length are found in practice. It is
1257   RECOMMENDED that all HTTP senders and recipients support messages whose
1258   combined header fields have 4000 or more octets.
1259</t>
1260</section>
1261
1262<section title="Field value components" anchor="field.components">
1263<t anchor="rule.token.separators">
1264 
1265 
1266 
1267 
1268   Many HTTP/1.1 header field values consist of words (token or quoted-string)
1269   separated by whitespace or special characters. These special characters
1270   MUST be in a quoted string to be used within a parameter value (as defined
1271   in <xref target="transfer.codings"/>).
1272</t>
1273<figure><iref primary="true" item="Grammar" subitem="word"/><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><iref primary="true" item="Grammar" subitem="special"/><artwork type="abnf2616"><![CDATA[
1274  word           = token / quoted-string
1275
1276  token          = 1*tchar
1277
1278  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
1279                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
1280                 / DIGIT / ALPHA
1281                 ; any VCHAR, except special
1282
1283  special        = "(" / ")" / "<" / ">" / "@" / ","
1284                 / ";" / ":" / "\" / DQUOTE / "/" / "["
1285                 / "]" / "?" / "=" / "{" / "}"
1286]]></artwork></figure>
1287<t anchor="rule.quoted-string">
1288 
1289 
1290 
1291   A string of text is parsed as a single word if it is quoted using
1292   double-quote marks.
1293</t>
1294<figure><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/><artwork type="abnf2616"><![CDATA[
1295  quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1296  qdtext         = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
1297  obs-text       = %x80-FF
1298]]></artwork></figure>
1299<t anchor="rule.quoted-pair">
1300 
1301   The backslash octet ("\") can be used as a single-octet
1302   quoting mechanism within quoted-string constructs:
1303</t>
1304<figure><iref primary="true" item="Grammar" subitem="quoted-pair"/><artwork type="abnf2616"><![CDATA[
1305  quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
1306]]></artwork></figure>
1307<t>
1308   Recipients that process the value of the quoted-string MUST handle a
1309   quoted-pair as if it were replaced by the octet following the backslash.
1310</t>
1311<t>
1312   Senders SHOULD NOT escape octets in quoted-strings that do not require
1313   escaping (i.e., other than DQUOTE and the backslash octet).
1314</t>
1315<t anchor="rule.comment">
1316 
1317 
1318   Comments can be included in some HTTP header fields by surrounding
1319   the comment text with parentheses. Comments are only allowed in
1320   fields containing "comment" as part of their field value definition.
1321</t>
1322<figure><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/><artwork type="abnf2616"><![CDATA[
1323  comment        = "(" *( ctext / quoted-cpair / comment ) ")"
1324  ctext          = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1325]]></artwork></figure>
1326<t anchor="rule.quoted-cpair">
1327 
1328   The backslash octet ("\") can be used as a single-octet
1329   quoting mechanism within comment constructs:
1330</t>
1331<figure><iref primary="true" item="Grammar" subitem="quoted-cpair"/><artwork type="abnf2616"><![CDATA[
1332  quoted-cpair   = "\" ( HTAB / SP / VCHAR / obs-text )
1333]]></artwork></figure>
1334<t>
1335   Senders SHOULD NOT escape octets in comments that do not require escaping
1336   (i.e., other than the backslash octet "\" and the parentheses "(" and ")").
1337</t>
1338</section>
1339
1340<section title="ABNF list extension: #rule" anchor="abnf.extension">
1341<t>
1342  A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to
1343  improve readability in the definitions of some header field values.
1344</t>
1345<t>
1346  A construct "#" is defined, similar to "*", for defining comma-delimited
1347  lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating
1348  at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
1349  comma (",") and optional whitespace (OWS).   
1350</t>
1351<figure><preamble>
1352  Thus,
1353</preamble><artwork type="example"><![CDATA[
1354  1#element => element *( OWS "," OWS element )
1355]]></artwork></figure>
1356<figure><preamble>
1357  and:
1358</preamble><artwork type="example"><![CDATA[
1359  #element => [ 1#element ]
1360]]></artwork></figure>
1361<figure><preamble>
1362  and for n &gt;= 1 and m &gt; 1:
1363</preamble><artwork type="example"><![CDATA[
1364  <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
1365]]></artwork></figure>
1366<t>
1367  For compatibility with legacy list rules, recipients SHOULD accept empty
1368  list elements. In other words, consumers would follow the list productions:
1369</t>
1370<figure><artwork type="example"><![CDATA[
1371  #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1372 
1373  1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
1374]]></artwork></figure>
1375<t>
1376  Note that empty elements do not contribute to the count of elements present,
1377  though.
1378</t>
1379<t>
1380  For example, given these ABNF productions:
1381</t>
1382<figure><artwork type="example"><![CDATA[
1383  example-list      = 1#example-list-elmt
1384  example-list-elmt = token ; see Section 3.2.4
1385]]></artwork></figure>
1386<t>
1387  Then these are valid values for example-list (not including the double
1388  quotes, which are present for delimitation only):
1389</t>
1390<figure><artwork type="example"><![CDATA[
1391  "foo,bar"
1392  "foo ,bar,"
1393  "foo , ,bar,charlie   "
1394]]></artwork></figure>
1395<t>
1396  But these values would be invalid, as at least one non-empty element is
1397  required:
1398</t>
1399<figure><artwork type="example"><![CDATA[
1400  ""
1401  ","
1402  ",   ,"
1403]]></artwork></figure>
1404<t>
1405  <xref target="collected.abnf"/> shows the collected ABNF, with the list rules
1406  expanded as explained above.
1407</t>
1408</section>
1409</section>
1410
1411<section title="Message Body" anchor="message.body">
1412 
1413<t>
1414   The message body (if any) of an HTTP message is used to carry the
1415   payload body of that request or response.  The message body is
1416   identical to the payload body unless a transfer coding has been
1417   applied, as described in <xref target="header.transfer-encoding"/>.
1418</t>
1419<figure><iref primary="true" item="Grammar" subitem="message-body"/><artwork type="abnf2616"><![CDATA[
1420  message-body = *OCTET
1421]]></artwork></figure>
1422<t>
1423   The rules for when a message body is allowed in a message differ for
1424   requests and responses.
1425</t>
1426<t>
1427   The presence of a message body in a request is signaled by a
1428   a Content-Length or Transfer-Encoding header field.
1429   Request message framing is independent of method semantics,
1430   even if the method does not define any use for a message body.
1431</t>
1432<t>
1433   The presence of a message body in a response depends on both
1434   the request method to which it is responding and the response
1435   status code (<xref target="status-code"/>).
1436   Responses to the HEAD request method never include a message body
1437   because the associated response header fields (e.g., Transfer-Encoding,
1438   Content-Length, etc.) only indicate what their values would have been
1439   if the request method had been GET.
1440   Successful (2xx) responses to CONNECT switch to tunnel mode instead of
1441   having a message body.
1442   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
1443   responses MUST NOT include a message body.
1444   All other responses do include a message body, although the body
1445   MAY be of zero length.
1446</t>
1447
1448<section title="Transfer-Encoding" anchor="header.transfer-encoding">
1449  <iref primary="true" item="Transfer-Encoding header field"/>
1450  <iref primary="true" item="Header Fields" subitem="Transfer-Encoding"/>
1451 
1452<t>
1453   When one or more transfer codings are applied to a payload body in order
1454   to form the message body, a Transfer-Encoding header field MUST be sent
1455   in the message and MUST contain the list of corresponding
1456   transfer-coding names in the same order that they were applied.
1457   Transfer codings are defined in <xref target="transfer.codings"/>.
1458</t>
1459<figure><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><artwork type="abnf2616"><![CDATA[
1460  Transfer-Encoding = 1#transfer-coding
1461]]></artwork></figure>
1462<t>
1463   Transfer-Encoding is analogous to the Content-Transfer-Encoding field of
1464   MIME, which was designed to enable safe transport of binary data over a
1465   7-bit transport service (<xref target="RFC2045"/>, Section 6).
1466   However, safe transport has a different focus for an 8bit-clean transfer
1467   protocol. In HTTP's case, Transfer-Encoding is primarily intended to
1468   accurately delimit a dynamically generated payload and to distinguish
1469   payload encodings that are only applied for transport efficiency or
1470   security from those that are characteristics of the target resource.
1471</t>
1472<t>
1473   The "chunked" transfer-coding (<xref target="chunked.encoding"/>)
1474   MUST be implemented by all HTTP/1.1 recipients because it plays a
1475   crucial role in delimiting messages when the payload body size is not
1476   known in advance.
1477   When the "chunked" transfer-coding is used, it MUST be the last
1478   transfer-coding applied to form the message body and MUST NOT
1479   be applied more than once in a message body.
1480   If any transfer-coding is applied to a request payload body,
1481   the final transfer-coding applied MUST be "chunked".
1482   If any transfer-coding is applied to a response payload body, then either
1483   the final transfer-coding applied MUST be "chunked" or
1484   the message MUST be terminated by closing the connection.
1485</t>
1486<figure><preamble>
1487   For example,
1488</preamble><artwork type="example"><![CDATA[
1489  Transfer-Encoding: gzip, chunked
1490]]></artwork><postamble>
1491   indicates that the payload body has been compressed using the gzip
1492   coding and then chunked using the chunked coding while forming the
1493   message body.
1494</postamble></figure>
1495<t>
1496   If more than one Transfer-Encoding header field is present in a message,
1497   the multiple field-values MUST be combined into one field-value,
1498   according to the algorithm defined in <xref target="header.fields"/>,
1499   before determining the message body length.
1500</t>
1501<t>
1502   Unlike Content-Encoding (Section 2.2 of <xref target="Part3"/>), Transfer-Encoding is a
1503   property of the message, not of the payload, and thus MAY be added or
1504   removed by any implementation along the request/response chain.
1505   Additional information about the encoding parameters MAY be provided
1506   by other header fields not defined by this specification.
1507</t>
1508<t>
1509   Transfer-Encoding MAY be sent in a response to a HEAD request or in a
1510   304 response to a GET request, neither of which includes a message body,
1511   to indicate that the origin server would have applied a transfer coding
1512   to the message body if the request had been an unconditional GET.
1513   This indication is not required, however, because any recipient on
1514   the response chain (including the origin server) can remove transfer
1515   codings when they are not needed.
1516</t>
1517<t>
1518   Transfer-Encoding was added in HTTP/1.1.  It is generally assumed that
1519   implementations advertising only HTTP/1.0 support will not understand
1520   how to process a transfer-encoded payload.
1521   A client MUST NOT send a request containing Transfer-Encoding unless it
1522   knows the server will handle HTTP/1.1 (or later) requests; such knowledge
1523   might be in the form of specific user configuration or by remembering the
1524   version of a prior received response.
1525   A server MUST NOT send a response containing Transfer-Encoding unless
1526   the corresponding request indicates HTTP/1.1 (or later).
1527</t>
1528<t>
1529   A server that receives a request message with a transfer-coding it does
1530   not understand SHOULD respond with 501 (Not Implemented) and then
1531   close the connection.
1532</t>
1533</section>
1534
1535<section title="Content-Length" anchor="header.content-length">
1536  <iref primary="true" item="Content-Length header field"/>
1537  <iref primary="true" item="Header Fields" subitem="Content-Length"/>
1538 
1539<t>
1540   When a message does not have a Transfer-Encoding header field and the
1541   payload body length can be determined prior to being transferred, a
1542   Content-Length header field SHOULD be sent to indicate the length of the
1543   payload body that is either present as the message body, for requests
1544   and non-HEAD responses other than 304, or would have been present had
1545   the request been an unconditional GET.  The length is expressed as a
1546   decimal number of octets.
1547</t>
1548<figure><iref primary="true" item="Grammar" subitem="Content-Length"/><artwork type="abnf2616"><![CDATA[
1549  Content-Length = 1*DIGIT
1550]]></artwork></figure>
1551<t>
1552   An example is
1553</t>
1554<figure><artwork type="example"><![CDATA[
1555  Content-Length: 3495
1556]]></artwork></figure>
1557<t>
1558   In the case of a response to a HEAD request, Content-Length indicates
1559   the size of the payload body (without any potential transfer-coding)
1560   that would have been sent had the request been a GET.
1561   In the case of a 304 (Not Modified) response to a GET request,
1562   Content-Length indicates the size of the payload body (without
1563   any potential transfer-coding) that would have been sent in a 200 (OK)
1564   response.
1565</t>
1566<t>
1567   HTTP's use of Content-Length is significantly different from how it is
1568   used in MIME, where it is an optional field used only within the
1569   "message/external-body" media-type.
1570</t>
1571<t>
1572   Any Content-Length field value greater than or equal to zero is valid.
1573   Since there is no predefined limit to the length of an HTTP payload,
1574   recipients SHOULD anticipate potentially large decimal numerals and
1575   prevent parsing errors due to integer conversion overflows
1576   (<xref target="attack.protocol.element.size.overflows"/>).
1577</t>
1578<t>
1579   If a message is received that has multiple Content-Length header fields
1580   (<xref target="header.content-length"/>) with field-values consisting
1581   of the same decimal value, or a single Content-Length header field with
1582   a field value containing a list of identical decimal values (e.g.,
1583   "Content-Length: 42, 42"), indicating that duplicate Content-Length
1584   header fields have been generated or combined by an upstream message
1585   processor, then the recipient MUST either reject the message as invalid
1586   or replace the duplicated field-values with a single valid Content-Length
1587   field containing that decimal value prior to determining the message body
1588   length.
1589</t>
1590</section>
1591
1592<section title="Message Body Length" anchor="message.body.length">
1593<t>
1594   The length of a message body is determined by one of the following
1595   (in order of precedence):
1596</t>
1597<t>
1598  <list style="numbers">
1599    <t>
1600     Any response to a HEAD request and any response with a status
1601     code of 100-199, 204, or 304 is always terminated by the first
1602     empty line after the header fields, regardless of the header
1603     fields present in the message, and thus cannot contain a message body.
1604    </t>
1605    <t>
1606     Any successful (2xx) response to a CONNECT request implies that the
1607     connection will become a tunnel immediately after the empty line that
1608     concludes the header fields.  A client MUST ignore any Content-Length
1609     or Transfer-Encoding header fields received in such a message.
1610    </t>
1611    <t>
1612     If a Transfer-Encoding header field is present
1613     and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
1614     is the final encoding, the message body length is determined by reading
1615     and decoding the chunked data until the transfer-coding indicates the
1616     data is complete.
1617    <vspace blankLines="1"/>
1618     If a Transfer-Encoding header field is present in a response and the
1619     "chunked" transfer-coding is not the final encoding, the message body
1620     length is determined by reading the connection until it is closed by
1621     the server.
1622     If a Transfer-Encoding header field is present in a request and the
1623     "chunked" transfer-coding is not the final encoding, the message body
1624     length cannot be determined reliably; the server MUST respond with
1625     the 400 (Bad Request) status code and then close the connection.
1626    <vspace blankLines="1"/>
1627     If a message is received with both a Transfer-Encoding header field
1628     and a Content-Length header field, the Transfer-Encoding overrides
1629     the Content-Length.
1630     Such a message might indicate an attempt to perform request or response
1631     smuggling (bypass of security-related checks on message routing or content)
1632     and thus ought to be handled as an error.  The provided Content-Length MUST
1633     be removed, prior to forwarding the message downstream, or replaced with
1634     the real message body length after the transfer-coding is decoded.
1635    </t>
1636    <t>
1637     If a message is received without Transfer-Encoding and with either
1638     multiple Content-Length header fields having differing field-values or
1639     a single Content-Length header field having an invalid value, then the
1640     message framing is invalid and MUST be treated as an error to
1641     prevent request or response smuggling.
1642     If this is a request message, the server MUST respond with
1643     a 400 (Bad Request) status code and then close the connection.
1644     If this is a response message received by a proxy, the proxy
1645     MUST discard the received response, send a 502 (Bad Gateway)
1646     status code as its downstream response, and then close the connection.
1647     If this is a response message received by a user-agent, it MUST be
1648     treated as an error by discarding the message and closing the connection.
1649    </t>
1650    <t>
1651     If a valid Content-Length header field
1652     is present without Transfer-Encoding, its decimal value defines the
1653     message body length in octets.  If the actual number of octets sent in
1654     the message is less than the indicated Content-Length, the recipient
1655     MUST consider the message to be incomplete and treat the connection
1656     as no longer usable.
1657     If the actual number of octets sent in the message is more than the indicated
1658     Content-Length, the recipient MUST only process the message body up to the
1659     field value's number of octets; the remainder of the message MUST either
1660     be discarded or treated as the next message in a pipeline.  For the sake of
1661     robustness, a user-agent MAY attempt to detect and correct such an error
1662     in message framing if it is parsing the response to the last request on
1663     a connection and the connection has been closed by the server.
1664    </t>
1665    <t>
1666     If this is a request message and none of the above are true, then the
1667     message body length is zero (no message body is present).
1668    </t>
1669    <t>
1670     Otherwise, this is a response message without a declared message body
1671     length, so the message body length is determined by the number of octets
1672     received prior to the server closing the connection.
1673    </t>
1674  </list>
1675</t>
1676<t>
1677   Since there is no way to distinguish a successfully completed,
1678   close-delimited message from a partially-received message interrupted
1679   by network failure, implementations SHOULD use encoding or
1680   length-delimited messages whenever possible.  The close-delimiting
1681   feature exists primarily for backwards compatibility with HTTP/1.0.
1682</t>
1683<t>
1684   A server MAY reject a request that contains a message body but
1685   not a Content-Length by responding with 411 (Length Required).
1686</t>
1687<t>
1688   Unless a transfer-coding other than "chunked" has been applied,
1689   a client that sends a request containing a message body SHOULD
1690   use a valid Content-Length header field if the message body length
1691   is known in advance, rather than the "chunked" encoding, since some
1692   existing services respond to "chunked" with a 411 (Length Required)
1693   status code even though they understand the chunked encoding.  This
1694   is typically because such services are implemented via a gateway that
1695   requires a content-length in advance of being called and the server
1696   is unable or unwilling to buffer the entire request before processing.
1697</t>
1698<t>
1699   A client that sends a request containing a message body MUST include a
1700   valid Content-Length header field if it does not know the server will
1701   handle HTTP/1.1 (or later) requests; such knowledge can be in the form
1702   of specific user configuration or by remembering the version of a prior
1703   received response.
1704</t>
1705</section>
1706</section>
1707
1708<section anchor="incomplete.messages" title="Handling Incomplete Messages">
1709<t>
1710   Request messages that are prematurely terminated, possibly due to a
1711   cancelled connection or a server-imposed time-out exception, MUST
1712   result in closure of the connection; sending an HTTP/1.1 error response
1713   prior to closing the connection is OPTIONAL.
1714</t>
1715<t>
1716   Response messages that are prematurely terminated, usually by closure
1717   of the connection prior to receiving the expected number of octets or by
1718   failure to decode a transfer-encoded message body, MUST be recorded
1719   as incomplete.  A response that terminates in the middle of the header
1720   block (before the empty line is received) cannot be assumed to convey the
1721   full semantics of the response and MUST be treated as an error.
1722</t>
1723<t>
1724   A message body that uses the chunked transfer encoding is
1725   incomplete if the zero-sized chunk that terminates the encoding has not
1726   been received.  A message that uses a valid Content-Length is incomplete
1727   if the size of the message body received (in octets) is less than the
1728   value given by Content-Length.  A response that has neither chunked
1729   transfer encoding nor Content-Length is terminated by closure of the
1730   connection, and thus is considered complete regardless of the number of
1731   message body octets received, provided that the header block was received
1732   intact.
1733</t>
1734<t>
1735   A user agent MUST NOT render an incomplete response message body as if
1736   it were complete (i.e., some indication must be given to the user that an
1737   error occurred).  Cache requirements for incomplete responses are defined
1738   in Section 2.1 of <xref target="Part6"/>.
1739</t>
1740<t>
1741   A server MUST read the entire request message body or close
1742   the connection after sending its response, since otherwise the
1743   remaining data on a persistent connection would be misinterpreted
1744   as the next request.  Likewise,
1745   a client MUST read the entire response message body if it intends
1746   to reuse the same connection for a subsequent request.  Pipelining
1747   multiple requests on a connection is described in <xref target="pipelining"/>.
1748</t>
1749</section>
1750
1751<section title="Message Parsing Robustness" anchor="message.robustness">
1752<t>
1753   Older HTTP/1.0 client implementations might send an extra CRLF
1754   after a POST request as a lame workaround for some early server
1755   applications that failed to read message body content that was
1756   not terminated by a line-ending. An HTTP/1.1 client MUST NOT
1757   preface or follow a request with an extra CRLF.  If terminating
1758   the request message body with a line-ending is desired, then the
1759   client MUST include the terminating CRLF octets as part of the
1760   message body length.
1761</t>
1762<t>
1763   In the interest of robustness, servers SHOULD ignore at least one
1764   empty line received where a request-line is expected. In other words, if
1765   the server is reading the protocol stream at the beginning of a
1766   message and receives a CRLF first, it SHOULD ignore the CRLF.
1767   Likewise, although the line terminator for the start-line and header
1768   fields is the sequence CRLF, we recommend that recipients recognize a
1769   single LF as a line terminator and ignore any CR.
1770</t>
1771<t>
1772   When a server listening only for HTTP request messages, or processing
1773   what appears from the start-line to be an HTTP request message,
1774   receives a sequence of octets that does not match the HTTP-message
1775   grammar aside from the robustness exceptions listed above, the
1776   server MUST respond with an HTTP/1.1 400 (Bad Request) response. 
1777</t>
1778</section>
1779</section>
1780
1781<section title="Transfer Codings" anchor="transfer.codings">
1782 
1783 
1784<t>
1785   Transfer-coding values are used to indicate an encoding
1786   transformation that has been, can be, or might need to be applied to a
1787   payload body in order to ensure "safe transport" through the network.
1788   This differs from a content coding in that the transfer-coding is a
1789   property of the message rather than a property of the representation
1790   that is being transferred.
1791</t>
1792<figure><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/><artwork type="abnf2616"><![CDATA[
1793  transfer-coding    = "chunked" ; Section 4.1
1794                     / "compress" ; Section 4.2.1
1795                     / "deflate" ; Section 4.2.2
1796                     / "gzip" ; Section 4.2.3
1797                     / transfer-extension
1798  transfer-extension = token *( OWS ";" OWS transfer-parameter )
1799]]></artwork></figure>
1800<t anchor="rule.parameter">
1801 
1802 
1803 
1804   Parameters are in the form of attribute/value pairs.
1805</t>
1806<figure><iref primary="true" item="Grammar" subitem="transfer-parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/><artwork type="abnf2616"><![CDATA[
1807  transfer-parameter = attribute BWS "=" BWS value
1808  attribute          = token
1809  value              = word
1810]]></artwork></figure>
1811<t>
1812   All transfer-coding values are case-insensitive.
1813   The HTTP Transfer Coding registry is defined in
1814   <xref target="transfer.coding.registry"/>.
1815   HTTP/1.1 uses transfer-coding values in the TE header field
1816   (<xref target="header.te"/>) and in the Transfer-Encoding header field
1817   (<xref target="header.transfer-encoding"/>).
1818</t>
1819
1820<section title="Chunked Transfer Coding" anchor="chunked.encoding">
1821  <iref item="chunked (Coding Format)"/>
1822  <iref item="Coding Format" subitem="chunked"/>
1823 
1824 
1825 
1826 
1827 
1828 
1829 
1830 
1831 
1832 
1833 
1834<t>
1835   The chunked encoding modifies the body of a message in order to
1836   transfer it as a series of chunks, each with its own size indicator,
1837   followed by an OPTIONAL trailer containing header fields. This
1838   allows dynamically produced content to be transferred along with the
1839   information necessary for the recipient to verify that it has
1840   received the full message.
1841</t>
1842<figure><iref primary="true" item="Grammar" subitem="chunked-body"/><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="true" item="Grammar" subitem="trailer-part"/><iref primary="true" item="Grammar" subitem="quoted-str-nf"/><iref primary="true" item="Grammar" subitem="qdtext-nf"/><artwork type="abnf2616"><![CDATA[
1843  chunked-body   = *chunk
1844                   last-chunk
1845                   trailer-part
1846                   CRLF
1847 
1848  chunk          = chunk-size [ chunk-ext ] CRLF
1849                   chunk-data CRLF
1850  chunk-size     = 1*HEXDIG
1851  last-chunk     = 1*("0") [ chunk-ext ] CRLF
1852 
1853  chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1854  chunk-ext-name = token
1855  chunk-ext-val  = token / quoted-str-nf
1856  chunk-data     = 1*OCTET ; a sequence of chunk-size octets
1857  trailer-part   = *( header-field CRLF )
1858 
1859  quoted-str-nf  = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
1860                 ; like quoted-string, but disallowing line folding
1861  qdtext-nf      = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
1862]]></artwork></figure>
1863<t>
1864   The chunk-size field is a string of hex digits indicating the size of
1865   the chunk-data in octets. The chunked encoding is ended by any chunk whose size is
1866   zero, followed by the trailer, which is terminated by an empty line.
1867</t>
1868<t>
1869   The trailer allows the sender to include additional HTTP header
1870   fields at the end of the message. The Trailer header field can be
1871   used to indicate which header fields are included in a trailer (see
1872   <xref target="header.trailer"/>).
1873</t>
1874<t>
1875   A server using chunked transfer-coding in a response MUST NOT use the
1876   trailer for any header fields unless at least one of the following is
1877   true:
1878  <list style="numbers">
1879    <t>the request included a TE header field that indicates "trailers" is
1880     acceptable in the transfer-coding of the  response, as described in
1881     <xref target="header.te"/>; or,</t>
1882     
1883    <t>the trailer fields consist entirely of optional metadata, and the
1884    recipient could use the message (in a manner acceptable to the server where
1885    the field originated) without receiving it. In other words, the server that
1886    generated the header (often but not always the origin server) is willing to
1887    accept the possibility that the trailer fields might be silently discarded
1888    along the path to the client.</t>
1889  </list>
1890</t>
1891<t>
1892   This requirement prevents an interoperability failure when the
1893   message is being received by an HTTP/1.1 (or later) proxy and
1894   forwarded to an HTTP/1.0 recipient. It avoids a situation where
1895   conformance with the protocol would have necessitated a possibly
1896   infinite buffer on the proxy.
1897</t>
1898<t>
1899   A process for decoding the "chunked" transfer-coding
1900   can be represented in pseudo-code as:
1901</t>
1902<figure><artwork type="code"><![CDATA[
1903  length := 0
1904  read chunk-size, chunk-ext (if any) and CRLF
1905  while (chunk-size > 0) {
1906     read chunk-data and CRLF
1907     append chunk-data to decoded-body
1908     length := length + chunk-size
1909     read chunk-size and CRLF
1910  }
1911  read header-field
1912  while (header-field not empty) {
1913     append header-field to existing header fields
1914     read header-field
1915  }
1916  Content-Length := length
1917  Remove "chunked" from Transfer-Encoding
1918]]></artwork></figure>
1919<t>
1920   All HTTP/1.1 applications MUST be able to receive and decode the
1921   "chunked" transfer-coding and MUST ignore chunk-ext extensions
1922   they do not understand.
1923</t>
1924<t>
1925   Use of chunk-ext extensions by senders is deprecated; they SHOULD NOT be
1926   sent and definition of new chunk-extensions is discouraged.
1927</t>
1928</section>
1929
1930<section title="Compression Codings" anchor="compression.codings">
1931<t>
1932   The codings defined below can be used to compress the payload of a
1933   message.
1934</t>
1935<t><list><t>
1936   Note: Use of program names for the identification of encoding formats
1937   is not desirable and is discouraged for future encodings. Their
1938   use here is representative of historical practice, not good
1939   design.
1940</t></list></t>
1941<t><list><t>
1942   Note: For compatibility with previous implementations of HTTP,
1943   applications SHOULD consider "x-gzip" and "x-compress" to be
1944   equivalent to "gzip" and "compress" respectively.
1945</t></list></t>
1946
1947<section title="Compress Coding" anchor="compress.coding">
1948<iref item="compress (Coding Format)"/>
1949<iref item="Coding Format" subitem="compress"/>
1950<t>
1951   The "compress" format is produced by the common UNIX file compression
1952   program "compress". This format is an adaptive Lempel-Ziv-Welch
1953   coding (LZW).
1954</t>
1955</section>
1956
1957<section title="Deflate Coding" anchor="deflate.coding">
1958<iref item="deflate (Coding Format)"/>
1959<iref item="Coding Format" subitem="deflate"/>
1960<t>
1961   The "deflate" format is defined as the "deflate" compression mechanism
1962   (described in <xref target="RFC1951"/>) used inside the "zlib"
1963   data format (<xref target="RFC1950"/>).
1964</t>
1965<t><list>
1966  <t>
1967    Note: Some incorrect implementations send the "deflate"
1968    compressed data without the zlib wrapper.
1969   </t>
1970</list></t>
1971</section>
1972
1973<section title="Gzip Coding" anchor="gzip.coding">
1974<iref item="gzip (Coding Format)"/>
1975<iref item="Coding Format" subitem="gzip"/>
1976<t>
1977   The "gzip" format is produced by the file compression program
1978   "gzip" (GNU zip), as described in <xref target="RFC1952"/>. This format is a
1979   Lempel-Ziv coding (LZ77) with a 32 bit CRC.
1980</t>
1981</section>
1982
1983</section>
1984
1985<section title="TE" anchor="header.te">
1986  <iref primary="true" item="TE header field"/>
1987  <iref primary="true" item="Header Fields" subitem="TE"/>
1988 
1989 
1990 
1991 
1992<t>
1993   The "TE" header field indicates what extension transfer-codings
1994   the client is willing to accept in the response, and whether or not it is
1995   willing to accept trailer fields in a chunked transfer-coding.
1996</t>
1997<t>
1998   Its value consists of the keyword "trailers" and/or a comma-separated
1999   list of extension transfer-coding names with optional accept
2000   parameters (as described in <xref target="transfer.codings"/>).
2001</t>
2002<figure><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/><artwork type="abnf2616"><![CDATA[
2003  TE        = #t-codings
2004  t-codings = "trailers" / ( transfer-extension [ te-params ] )
2005  te-params = OWS ";" OWS "q=" qvalue *( te-ext )
2006  te-ext    = OWS ";" OWS token [ "=" word ]
2007]]></artwork></figure>
2008<t>
2009   The presence of the keyword "trailers" indicates that the client is
2010   willing to accept trailer fields in a chunked transfer-coding, as
2011   defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with
2012   transfer-coding values even though it does not itself represent a
2013   transfer-coding.
2014</t>
2015<t>
2016   Examples of its use are:
2017</t>
2018<figure><artwork type="example"><![CDATA[
2019  TE: deflate
2020  TE:
2021  TE: trailers, deflate;q=0.5
2022]]></artwork></figure>
2023<t>
2024   The TE header field only applies to the immediate connection.
2025   Therefore, the keyword MUST be supplied within a Connection header
2026   field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.
2027</t>
2028<t>
2029   A server tests whether a transfer-coding is acceptable, according to
2030   a TE field, using these rules:
2031  <list style="numbers">
2032    <t>The "chunked" transfer-coding is always acceptable. If the
2033         keyword "trailers" is listed, the client indicates that it is
2034         willing to accept trailer fields in the chunked response on
2035         behalf of itself and any downstream clients. The implication is
2036         that, if given, the client is stating that either all
2037         downstream clients are willing to accept trailer fields in the
2038         forwarded response, or that it will attempt to buffer the
2039         response on behalf of downstream recipients.
2040      <vspace blankLines="1"/>
2041         Note: HTTP/1.1 does not define any means to limit the size of a
2042         chunked response such that a client can be assured of buffering
2043         the entire response.</t>
2044    <t>If the transfer-coding being tested is one of the transfer-codings
2045         listed in the TE field, then it is acceptable unless it
2046         is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a
2047         qvalue of 0 means "not acceptable".)</t>
2048    <t>If multiple transfer-codings are acceptable, then the
2049         acceptable transfer-coding with the highest non-zero qvalue is
2050         preferred.  The "chunked" transfer-coding always has a qvalue
2051         of 1.</t>
2052  </list>
2053</t>
2054<t>
2055   If the TE field-value is empty or if no TE field is present, the only
2056   acceptable transfer-coding is "chunked". A message with no transfer-coding is
2057   always acceptable.
2058</t>
2059
2060<section title="Quality Values" anchor="quality.values">
2061 
2062<t>
2063   Both transfer codings (TE request header field, <xref target="header.te"/>)
2064   and content negotiation (Section 5 of <xref target="Part3"/>) use short "floating point"
2065   numbers to indicate the relative importance ("weight") of various
2066   negotiable parameters.  A weight is normalized to a real number in
2067   the range 0 through 1, where 0 is the minimum and 1 the maximum
2068   value. If a parameter has a quality value of 0, then content with
2069   this parameter is "not acceptable" for the client. HTTP/1.1
2070   applications MUST NOT generate more than three digits after the
2071   decimal point. User configuration of these values SHOULD also be
2072   limited in this fashion.
2073</t>
2074<figure><iref primary="true" item="Grammar" subitem="qvalue"/><artwork type="abnf2616"><![CDATA[
2075  qvalue         = ( "0" [ "." 0*3DIGIT ] )
2076                 / ( "1" [ "." 0*3("0") ] )
2077]]></artwork></figure>
2078<t><list>
2079  <t>
2080     Note: "Quality values" is a misnomer, since these values merely represent
2081     relative degradation in desired quality.
2082  </t>
2083</list></t>
2084</section>
2085</section>
2086
2087<section title="Trailer" anchor="header.trailer">
2088  <iref primary="true" item="Trailer header field"/>
2089  <iref primary="true" item="Header Fields" subitem="Trailer"/>
2090 
2091<t>
2092   The "Trailer" header field indicates that the given set of
2093   header fields is present in the trailer of a message encoded with
2094   chunked transfer-coding.
2095</t>
2096<figure><iref primary="true" item="Grammar" subitem="Trailer"/><artwork type="abnf2616"><![CDATA[
2097  Trailer = 1#field-name
2098]]></artwork></figure>
2099<t>
2100   An HTTP/1.1 message SHOULD include a Trailer header field in a
2101   message using chunked transfer-coding with a non-empty trailer. Doing
2102   so allows the recipient to know which header fields to expect in the
2103   trailer.
2104</t>
2105<t>
2106   If no Trailer header field is present, the trailer SHOULD NOT  include
2107   any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of
2108   trailer fields in a "chunked" transfer-coding.
2109</t>
2110<t>
2111   Message header fields listed in the Trailer header field MUST NOT
2112   include the following header fields:
2113  <list style="symbols">
2114    <t>Transfer-Encoding</t>
2115    <t>Content-Length</t>
2116    <t>Trailer</t>
2117  </list>
2118</t>
2119</section>
2120</section>
2121
2122<section title="Message Routing" anchor="message.routing">
2123<t>
2124   HTTP request message routing is determined by each client based on the
2125   target resource, the client's proxy configuration, and
2126   establishment or reuse of an inbound connection.  The corresponding
2127   response routing follows the same connection chain back to the client.
2128</t>
2129
2130<section title="Identifying a Target Resource" anchor="target-resource">
2131  <iref primary="true" item="target resource"/>
2132  <iref primary="true" item="target URI"/>
2133<t>
2134   HTTP is used in a wide variety of applications, ranging from
2135   general-purpose computers to home appliances.  In some cases,
2136   communication options are hard-coded in a client's configuration.
2137   However, most HTTP clients rely on the same resource identification
2138   mechanism and configuration techniques as general-purpose Web browsers.
2139</t>
2140<t>
2141   HTTP communication is initiated by a user agent for some purpose.
2142   The purpose is a combination of request semantics, which are defined in
2143   <xref target="Part2"/>, and a target resource upon which to apply those
2144   semantics.  A URI reference (<xref target="uri"/>) is typically used as
2145   an identifier for the "target resource", which a user agent would resolve
2146   to its absolute form in order to obtain the "target URI".  The target URI
2147   excludes the reference's fragment identifier component, if any,
2148   since fragment identifiers are reserved for client-side processing
2149   (<xref target="RFC3986"/>, Section 3.5).
2150</t>
2151<t>
2152   HTTP intermediaries obtain the request semantics and target URI
2153   from the request-line of an incoming request message.
2154</t>
2155</section>
2156
2157<section title="Connecting Inbound" anchor="connecting.inbound">
2158<t>
2159   Once the target URI is determined, a client needs to decide whether
2160   a network request is necessary to accomplish the desired semantics and,
2161   if so, where that request is to be directed.
2162</t>
2163<t>
2164   If the client has a response cache and the request semantics can be
2165   satisfied by a cache (<xref target="Part6"/>), then the request is
2166   usually directed to the cache first.
2167</t>
2168<t>
2169   If the request is not satisfied by a cache, then a typical client will
2170   check its configuration to determine whether a proxy is to be used to
2171   satisfy the request.  Proxy configuration is implementation-dependent,
2172   but is often based on URI prefix matching, selective authority matching,
2173   or both, and the proxy itself is usually identified by an "http" or
2174   "https" URI.  If a proxy is applicable, the client connects inbound by
2175   establishing (or reusing) a connection to that proxy.
2176</t>
2177<t>
2178   If no proxy is applicable, a typical client will invoke a handler routine,
2179   usually specific to the target URI's scheme, to connect directly
2180   to an authority for the target resource.  How that is accomplished is
2181   dependent on the target URI scheme and defined by its associated
2182   specification, similar to how this specification defines origin server
2183   access for resolution of the "http" (<xref target="http.uri"/>) and
2184   "https" (<xref target="https.uri"/>) schemes.
2185</t>
2186</section>
2187
2188<section title="Request Target" anchor="request-target">
2189<t>
2190   Once an inbound connection is obtained
2191   (<xref target="connection.management"/>),
2192   the client sends an HTTP request message (<xref target="http.message"/>)
2193   with a request-target derived from the target URI.
2194   There are four distinct formats for the request-target, depending on both
2195   the method being requested and whether the request is to a proxy.
2196</t>   
2197<figure><iref primary="true" item="Grammar" subitem="request-target"/><iref primary="true" item="Grammar" subitem="origin-form"/><iref primary="true" item="Grammar" subitem="absolute-form"/><iref primary="true" item="Grammar" subitem="authority-form"/><iref primary="true" item="Grammar" subitem="asterisk-form"/><artwork type="abnf2616"><![CDATA[
2198  request-target = origin-form
2199                 / absolute-form
2200                 / authority-form
2201                 / asterisk-form
2202
2203  origin-form    = path-absolute [ "?" query ]
2204  absolute-form  = absolute-URI
2205  authority-form = authority
2206  asterisk-form  = "*"
2207]]></artwork></figure>
2208<t anchor="origin-form"><iref item="origin-form (of request-target)"/>
2209   The most common form of request-target is the origin-form.
2210   When making a request directly to an origin server, other than a CONNECT
2211   or server-wide OPTIONS request (as detailed below),
2212   a client MUST send only the absolute path and query components of
2213   the target URI as the request-target.
2214   If the target URI's path component is empty, then the client MUST send
2215   "/" as the path within the origin-form of request-target.
2216   A Host header field is also sent, as defined in
2217   <xref target="header.host"/>, containing the target URI's
2218   authority component (excluding any userinfo).
2219</t>
2220<t>
2221   For example, a client wishing to retrieve a representation of the resource
2222   identified as
2223</t>
2224<figure><artwork><![CDATA[
2225  http://www.example.org/where?q=now
2226  ]]></artwork></figure>
2227<t>
2228   directly from the origin server would open (or reuse) a TCP connection
2229   to port 80 of the host "www.example.org" and send the lines:
2230</t>
2231<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
2232  GET /where?q=now HTTP/1.1
2233  Host: www.example.org
2234  ]]></artwork></figure>
2235<t>
2236   followed by the remainder of the request message.
2237</t>
2238<t anchor="absolute-form"><iref item="absolute-form (of request-target)"/>
2239   When making a request to a proxy, other than a CONNECT or server-wide
2240   OPTIONS request (as detailed below), a client MUST send the target URI
2241   in absolute-form as the request-target.
2242   The proxy is requested to either service that request from a valid cache,
2243   if possible, or make the same request on the client's behalf to either
2244   the next inbound proxy server or directly to the origin server indicated
2245   by the request-target.  Requirements on such "forwarding" of messages are
2246   defined in <xref target="intermediary.forwarding"/>.
2247</t>
2248<t>
2249   An example absolute-form of request-line would be:
2250</t>
2251<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
2252  GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
2253  ]]></artwork></figure>
2254<t>
2255   To allow for transition to the absolute-form for all requests in some
2256   future version of HTTP, HTTP/1.1 servers MUST accept the absolute-form
2257   in requests, even though HTTP/1.1 clients will only send them in requests
2258   to proxies.
2259</t>
2260<t anchor="authority-form"><iref item="authority-form (of request-target)"/>
2261   The authority-form of request-target is only used for CONNECT requests
2262   (Section 6.9 of <xref target="Part2"/>).  When making a CONNECT request to establish a tunnel through
2263   one or more proxies, a client MUST send only the target URI's
2264   authority component (excluding any userinfo) as the request-target.
2265   For example,
2266</t>
2267<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
2268  CONNECT www.example.com:80 HTTP/1.1
2269  ]]></artwork></figure>
2270<t anchor="asterisk-form"><iref item="asterisk-form (of request-target)"/>
2271   The asterisk-form of request-target is only used for a server-wide
2272   OPTIONS request (Section 6.2 of <xref target="Part2"/>).  When a client wishes to request OPTIONS
2273   for the server as a whole, as opposed to a specific named resource of
2274   that server, the client MUST send only "*" (%x2A) as the request-target.
2275   For example,
2276</t>
2277<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
2278  OPTIONS * HTTP/1.1
2279  ]]></artwork></figure>
2280<t>
2281   If a proxy receives an OPTIONS request with an absolute-form of
2282   request-target in which the URI has an empty path and no query component,
2283   then the last proxy on the request chain MUST send a request-target
2284   of "*" when it forwards the request to the indicated origin server.
2285</t>
2286<figure><preamble>  
2287   For example, the request
2288</preamble><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
2289  OPTIONS http://www.example.org:8001 HTTP/1.1
2290  ]]></artwork></figure>
2291<figure><preamble>  
2292  would be forwarded by the final proxy as
2293</preamble><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
2294  OPTIONS * HTTP/1.1
2295  Host: www.example.org:8001
2296  ]]></artwork>
2297<postamble>
2298   after connecting to port 8001 of host "www.example.org".
2299</postamble>
2300</figure>
2301</section>
2302
2303<section title="Host" anchor="header.host">
2304  <iref primary="true" item="Host header field"/>
2305  <iref primary="true" item="Header Fields" subitem="Host"/>
2306 
2307<t>
2308   The "Host" header field in a request provides the host and port
2309   information from the target URI, enabling the origin
2310   server to distinguish among resources while servicing requests
2311   for multiple host names on a single IP address.  Since the Host
2312   field-value is critical information for handling a request, it
2313   SHOULD be sent as the first header field following the request-line.
2314</t>
2315<figure><iref primary="true" item="Grammar" subitem="Host"/><artwork type="abnf2616"><![CDATA[
2316  Host = uri-host [ ":" port ] ; Section 2.7.1
2317]]></artwork></figure>
2318<t>
2319   A client MUST send a Host header field in all HTTP/1.1 request
2320   messages.  If the target URI includes an authority component, then
2321   the Host field-value MUST be identical to that authority component
2322   after excluding any userinfo (<xref target="http.uri"/>).
2323   If the authority component is missing or undefined for the target URI,
2324   then the Host header field MUST be sent with an empty field-value.
2325</t>
2326<t>
2327   For example, a GET request to the origin server for
2328   &lt;http://www.example.org/pub/WWW/&gt; would begin with:
2329</t>
2330<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
2331  GET /pub/WWW/ HTTP/1.1
2332  Host: www.example.org
2333  ]]></artwork></figure>
2334<t>
2335   The Host header field MUST be sent in an HTTP/1.1 request even
2336   if the request-target is in the absolute-form, since this
2337   allows the Host information to be forwarded through ancient HTTP/1.0
2338   proxies that might not have implemented Host.
2339</t>
2340<t>
2341   When an HTTP/1.1 proxy receives a request with an absolute-form of
2342   request-target, the proxy MUST ignore the received
2343   Host header field (if any) and instead replace it with the host
2344   information of the request-target.  If the proxy forwards the request,
2345   it MUST generate a new Host field-value based on the received
2346   request-target rather than forward the received Host field-value.
2347</t>
2348<t>
2349   Since the Host header field acts as an application-level routing
2350   mechanism, it is a frequent target for malware seeking to poison
2351   a shared cache or redirect a request to an unintended server.
2352   An interception proxy is particularly vulnerable if it relies on
2353   the Host field-value for redirecting requests to internal
2354   servers, or for use as a cache key in a shared cache, without
2355   first verifying that the intercepted connection is targeting a
2356   valid IP address for that host.
2357</t>
2358<t>
2359   A server MUST respond with a 400 (Bad Request) status code to
2360   any HTTP/1.1 request message that lacks a Host header field and
2361   to any request message that contains more than one Host header field
2362   or a Host header field with an invalid field-value.
2363</t>
2364</section>
2365
2366<section title="Effective Request URI" anchor="effective.request.uri">
2367  <iref primary="true" item="effective request URI"/>
2368<t>
2369   A server that receives an HTTP request message MUST reconstruct
2370   the user agent's original target URI, based on the pieces of information
2371   learned from the request-target, Host, and connection context, in order
2372   to identify the intended target resource and properly service the request.
2373   The URI derived from this reconstruction process is referred to as the
2374   "effective request URI".
2375</t>
2376<t>
2377   For a user agent, the effective request URI is the target URI.
2378</t>
2379<t>
2380   If the request-target is in absolute-form, then the effective request URI
2381   is the same as the request-target.  Otherwise, the effective request URI
2382   is constructed as follows.
2383</t>
2384<t>
2385   If the request is received over an SSL/TLS-secured TCP connection,
2386   then the effective request URI's scheme is "https"; otherwise, the
2387   scheme is "http".
2388</t>
2389<t>
2390   If the request-target is in authority-form, then the effective
2391   request URI's authority component is the same as the request-target.
2392   Otherwise, if a Host header field is supplied with a non-empty field-value,
2393   then the authority component is the same as the Host field-value.
2394   Otherwise, the authority component is the concatenation of the default
2395   hostname configured for the server, a colon (":"), and the connection's
2396   incoming TCP port number in decimal form.
2397</t>
2398<t>
2399   If the request-target is in authority-form or asterisk-form, then the
2400   effective request URI's combined path and query component is empty.
2401   Otherwise, the combined path and query component is the same as the
2402   request-target.
2403</t>
2404<t>
2405   The components of the effective request URI, once determined as above,
2406   can be combined into absolute-URI form by concatenating the scheme,
2407   "://", authority, and combined path and query component.
2408</t>
2409<figure>
2410<preamble>
2411   Example 1: the following message received over an insecure TCP connection
2412</preamble>
2413<artwork type="example"><![CDATA[
2414  GET /pub/WWW/TheProject.html HTTP/1.1
2415  Host: www.example.org:8080
2416  ]]></artwork>
2417</figure>
2418<figure>
2419<preamble>
2420  has an effective request URI of
2421</preamble>
2422<artwork type="example"><![CDATA[
2423  http://www.example.org:8080/pub/WWW/TheProject.html
2424  ]]></artwork>
2425</figure>
2426<figure>
2427<preamble>
2428   Example 2: the following message received over an SSL/TLS-secured TCP
2429   connection
2430</preamble>
2431<artwork type="example"><![CDATA[
2432  OPTIONS * HTTP/1.1
2433  Host: www.example.org
2434  ]]></artwork>
2435</figure>
2436<figure>
2437<preamble>
2438  has an effective request URI of
2439</preamble>
2440<artwork type="example"><![CDATA[
2441  https://www.example.org
2442  ]]></artwork>
2443</figure>
2444<t>
2445   An origin server that does not allow resources to differ by requested
2446   host MAY ignore the Host field-value and instead replace it with a
2447   configured server name when constructing the effective request URI.
2448</t>
2449<t>
2450   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
2451   attempt to use heuristics (e.g., examination of the URI path for
2452   something unique to a particular host) in order to guess the
2453   effective request URI's authority component.
2454</t>
2455</section>
2456
2457<section title="Intermediary Forwarding" anchor="intermediary.forwarding">
2458<t>
2459   As described in <xref target="intermediaries"/>, intermediaries can serve
2460   a variety of roles in the processing of HTTP requests and responses.
2461   Some intermediaries are used to improve performance or availability.
2462   Others are used for access control or to filter content.
2463   Since an HTTP stream has characteristics similar to a pipe-and-filter
2464   architecture, there are no inherent limits to the extent an intermediary
2465   can enhance (or interfere) with either direction of the stream.
2466</t>
2467<t>
2468   In order to avoid request loops, a proxy that forwards requests to other
2469   proxies MUST be able to recognize and exclude all of its own server
2470   names, including any aliases, local variations, or literal IP addresses.
2471</t>
2472<t>
2473   If a proxy receives a request-target with a host name that is not a
2474   fully qualified domain name, it MAY add its domain to the host name
2475   it received when forwarding the request.  A proxy MUST NOT change the
2476   host name if it is a fully qualified domain name.
2477</t>
2478<t>
2479   A non-transforming proxy MUST NOT rewrite the "path-absolute" and "query"
2480   parts of the received request-target when forwarding it to the next inbound
2481   server, except as noted above to replace an empty path with "/" or "*".
2482</t>
2483<t>
2484   Intermediaries that forward a message MUST implement the
2485   Connection header field as specified in <xref target="header.connection"/>.
2486</t>
2487
2488<section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields">
2489<!--<t>
2490  <cref anchor="TODO-end-to-end" source="jre">
2491    Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1"/>.
2492    See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
2493  </cref>
2494</t>-->
2495<t>
2496   For the purpose of defining the behavior of caches and non-caching
2497   proxies, we divide HTTP header fields into two categories:
2498  <list style="symbols">
2499      <t>End-to-end header fields, which are  transmitted to the ultimate
2500        recipient of a request or response. End-to-end header fields in
2501        responses MUST be stored as part of a cache entry and MUST be
2502        transmitted in any response formed from a cache entry.</t>
2503
2504      <t>Hop-by-hop header fields, which are meaningful only for a single
2505        transport-level connection, and are not stored by caches or
2506        forwarded by proxies.</t>
2507  </list>
2508</t>
2509<t>
2510   The following HTTP/1.1 header fields are hop-by-hop header fields:
2511  <list style="symbols">
2512      <t>Connection</t>
2513      <t>Keep-Alive</t>
2514      <t>Proxy-Authenticate</t>
2515      <t>Proxy-Authorization</t>
2516      <t>TE</t>
2517      <t>Trailer</t>
2518      <t>Transfer-Encoding</t>
2519      <t>Upgrade</t>
2520  </list>
2521</t>
2522<t>
2523   All other header fields defined by HTTP/1.1 are end-to-end header fields.
2524</t>
2525<t>
2526   Other hop-by-hop header fields MUST be listed in a Connection header field
2527   (<xref target="header.connection"/>).
2528</t>
2529</section>
2530
2531<section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields">
2532<!--<t>
2533  <cref anchor="TODO-non-mod-headers" source="jre">
2534    Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2"/>.
2535    See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
2536  </cref>
2537</t>-->
2538<t>
2539   Some features of HTTP/1.1, such as Digest Authentication, depend on the
2540   value of certain end-to-end header fields. A non-transforming proxy SHOULD NOT
2541   modify an end-to-end header field unless the definition of that header field requires
2542   or specifically allows that.
2543</t>
2544<t>
2545   A non-transforming proxy MUST NOT modify any of the following fields in a
2546   request or response, and it MUST NOT add any of these fields if not
2547   already present:
2548  <list style="symbols">
2549    <t>Allow</t>
2550    <t>Content-Location</t>
2551    <t>Content-MD5</t>
2552    <t>ETag</t>
2553    <t>Last-Modified</t>
2554    <t>Server</t>
2555  </list>
2556</t>
2557<t>
2558   A non-transforming proxy MUST NOT modify any of the following fields in a
2559   response:
2560  <list style="symbols">
2561    <t>Expires</t>
2562  </list>
2563</t>
2564<t>
2565   but it MAY add any of these fields if not already present. If an
2566   Expires header field is added, it MUST be given a field-value identical to
2567   that of the Date header field in that response.
2568</t>
2569<t>
2570   A proxy MUST NOT modify or add any of the following fields in a
2571   message that contains the no-transform cache-control directive, or in
2572   any request:
2573  <list style="symbols">
2574    <t>Content-Encoding</t>
2575    <t>Content-Range</t>
2576    <t>Content-Type</t>
2577  </list>
2578</t>
2579<t>
2580   A transforming proxy MAY modify or add these fields to a message
2581   that does not include no-transform, but if it does so, it MUST add a
2582   Warning 214 (Transformation applied) if one does not already appear
2583   in the message (see Section 3.6 of <xref target="Part6"/>).
2584</t>
2585<t><list>
2586  <t>
2587    Warning: Unnecessary modification of end-to-end header fields might
2588    cause authentication failures if stronger authentication
2589    mechanisms are introduced in later versions of HTTP. Such
2590    authentication mechanisms MAY rely on the values of header fields
2591    not listed here.
2592  </t>
2593</list></t>
2594<t>
2595   A non-transforming proxy MUST preserve the message payload (<xref target="Part3"/>),
2596   though it MAY change the message body through application or removal
2597   of a transfer-coding (<xref target="transfer.codings"/>).
2598</t>
2599</section>
2600
2601</section>
2602
2603<section title="Associating a Response to a Request" anchor="associating.response.to.request">
2604<t>
2605   HTTP does not include a request identifier for associating a given
2606   request message with its corresponding one or more response messages.
2607   Hence, it relies on the order of response arrival to correspond exactly
2608   to the order in which requests are made on the same connection.
2609   More than one response message per request only occurs when one or more
2610   informational responses (1xx, see Section 7.1 of <xref target="Part2"/>) precede a final response
2611   to the same request.
2612</t>
2613<t>
2614   A client that uses persistent connections and sends more than one request
2615   per connection MUST maintain a list of outstanding requests in the
2616   order sent on that connection and MUST associate each received response
2617   message to the highest ordered request that has not yet received a final
2618   (non-1xx) response.
2619</t>
2620</section>
2621</section>
2622
2623<section title="Connection Management" anchor="connection.management">
2624
2625<section title="Connection" anchor="header.connection">
2626  <iref primary="true" item="Connection header field"/>
2627  <iref primary="true" item="Header Fields" subitem="Connection"/>
2628 
2629 
2630<t>
2631   The "Connection" header field allows the sender to specify
2632   options that are desired only for that particular connection.
2633   Such connection options MUST be removed or replaced before the
2634   message can be forwarded downstream by a proxy or gateway.
2635   This mechanism also allows the sender to indicate which HTTP
2636   header fields used in the message are only intended for the
2637   immediate recipient ("hop-by-hop"), as opposed to all recipients
2638   on the chain ("end-to-end"), enabling the message to be
2639   self-descriptive and allowing future connection-specific extensions
2640   to be deployed in HTTP without fear that they will be blindly
2641   forwarded by previously deployed intermediaries.
2642</t>
2643<t>
2644   The Connection header field's value has the following grammar:
2645</t>
2646<figure><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="connection-token"/><artwork type="abnf2616"><![CDATA[
2647  Connection       = 1#connection-token
2648  connection-token = token
2649]]></artwork></figure>
2650<t>
2651   A proxy or gateway MUST parse a received Connection
2652   header field before a message is forwarded and, for each
2653   connection-token in this field, remove any header field(s) from
2654   the message with the same name as the connection-token, and then
2655   remove the Connection header field itself or replace it with the
2656   sender's own connection options for the forwarded message.
2657</t>
2658<t>
2659   A sender MUST NOT include field-names in the Connection header
2660   field-value for fields that are defined as expressing constraints
2661   for all recipients in the request or response chain, such as the
2662   Cache-Control header field (Section 3.2 of <xref target="Part6"/>).
2663</t>
2664<t>
2665   The connection options do not have to correspond to a header field
2666   present in the message, since a connection-specific header field
2667   might not be needed if there are no parameters associated with that
2668   connection option.  Recipients that trigger certain connection
2669   behavior based on the presence of connection options MUST do so
2670   based on the presence of the connection-token rather than only the
2671   presence of the optional header field.  In other words, if the
2672   connection option is received as a header field but not indicated
2673   within the Connection field-value, then the recipient MUST ignore
2674   the connection-specific header field because it has likely been
2675   forwarded by an intermediary that is only partially conformant.
2676</t>
2677<t>
2678   When defining new connection options, specifications ought to
2679   carefully consider existing deployed header fields and ensure
2680   that the new connection-token does not share the same name as
2681   an unrelated header field that might already be deployed.
2682   Defining a new connection-token essentially reserves that potential
2683   field-name for carrying additional information related to the
2684   connection option, since it would be unwise for senders to use
2685   that field-name for anything else.
2686</t>
2687<t>
2688   HTTP/1.1 defines the "close" connection option for the sender to
2689   signal that the connection will be closed after completion of the
2690   response. For example,
2691</t>
2692<figure><artwork type="example"><![CDATA[
2693  Connection: close
2694]]></artwork></figure>
2695<t>
2696   in either the request or the response header fields indicates that
2697   the connection SHOULD NOT  be considered "persistent" (<xref target="persistent.connections"/>)
2698   after the current request/response is complete.
2699</t>
2700<t>
2701   An HTTP/1.1 client that does not support persistent connections MUST
2702   include the "close" connection option in every request message.
2703</t>
2704<t>
2705   An HTTP/1.1 server that does not support persistent connections MUST
2706   include the "close" connection option in every response message that
2707   does not have a 1xx (Informational) status code.
2708</t>
2709</section>
2710
2711<section title="Via" anchor="header.via">
2712  <iref primary="true" item="Via header field"/>
2713  <iref primary="true" item="Header Fields" subitem="Via"/>
2714 
2715 
2716 
2717 
2718<t>
2719   The "Via" header field MUST be sent by a proxy or gateway to
2720   indicate the intermediate protocols and recipients between the user
2721   agent and the server on requests, and between the origin server and
2722   the client on responses. It is analogous to the "Received" field
2723   used by email systems (Section 3.6.7 of <xref target="RFC5322"/>)
2724   and is intended to be used for tracking message forwards,
2725   avoiding request loops, and identifying the protocol capabilities of
2726   all senders along the request/response chain.
2727</t>
2728<figure><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/><artwork type="abnf2616"><![CDATA[
2729  Via               = 1#( received-protocol RWS received-by
2730                          [ RWS comment ] )
2731  received-protocol = [ protocol-name "/" ] protocol-version
2732  received-by       = ( uri-host [ ":" port ] ) / pseudonym
2733  pseudonym         = token
2734]]></artwork></figure>
2735<t>
2736   The received-protocol indicates the protocol version of the message
2737   received by the server or client along each segment of the
2738   request/response chain. The received-protocol version is appended to
2739   the Via field value when the message is forwarded so that information
2740   about the protocol capabilities of upstream applications remains
2741   visible to all recipients.
2742</t>
2743<t>
2744   The protocol-name is excluded if and only if it would be "HTTP". The
2745   received-by field is normally the host and optional port number of a
2746   recipient server or client that subsequently forwarded the message.
2747   However, if the real host is considered to be sensitive information,
2748   it MAY be replaced by a pseudonym. If the port is not given, it MAY
2749   be assumed to be the default port of the received-protocol.
2750</t>
2751<t>
2752   Multiple Via field values represent each proxy or gateway that has
2753   forwarded the message. Each recipient MUST append its information
2754   such that the end result is ordered according to the sequence of
2755   forwarding applications.
2756</t>
2757<t>
2758   Comments MAY be used in the Via header field to identify the software
2759   of each recipient, analogous to the User-Agent and Server header fields.
2760   However, all comments in the Via field are optional and MAY be removed
2761   by any recipient prior to forwarding the message.
2762</t>
2763<t>
2764   For example, a request message could be sent from an HTTP/1.0 user
2765   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
2766   forward the request to a public proxy at p.example.net, which completes
2767   the request by forwarding it to the origin server at www.example.com.
2768   The request received by www.example.com would then have the following
2769   Via header field:
2770</t>
2771<figure><artwork type="example"><![CDATA[
2772  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
2773]]></artwork></figure>
2774<t>
2775   A proxy or gateway used as a portal through a network firewall
2776   SHOULD NOT forward the names and ports of hosts within the firewall
2777   region unless it is explicitly enabled to do so. If not enabled, the
2778   received-by host of any host behind the firewall SHOULD be replaced
2779   by an appropriate pseudonym for that host.
2780</t>
2781<t>
2782   For organizations that have strong privacy requirements for hiding
2783   internal structures, a proxy or gateway MAY combine an ordered
2784   subsequence of Via header field entries with identical received-protocol
2785   values into a single such entry. For example,
2786</t>
2787<figure><artwork type="example"><![CDATA[
2788  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2789]]></artwork></figure>
2790<t>
2791  could be collapsed to
2792</t>
2793<figure><artwork type="example"><![CDATA[
2794  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2795]]></artwork></figure>
2796<t>
2797   Senders SHOULD NOT combine multiple entries unless they are all
2798   under the same organizational control and the hosts have already been
2799   replaced by pseudonyms. Senders MUST NOT combine entries which
2800   have different received-protocol values.
2801</t>
2802</section>
2803
2804<section title="Persistent Connections" anchor="persistent.connections">
2805
2806<section title="Purpose" anchor="persistent.purpose">
2807<t>
2808   Prior to persistent connections, a separate TCP connection was
2809   established for each request, increasing the load on HTTP servers
2810   and causing congestion on the Internet. The use of inline images and
2811   other associated data often requires a client to make multiple
2812   requests of the same server in a short amount of time. Analysis of
2813   these performance problems and results from a prototype
2814   implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and
2815   measurements of actual HTTP/1.1 implementations show good
2816   results <xref target="Nie1997"/>. Alternatives have also been explored, for example,
2817   T/TCP <xref target="Tou1998"/>.
2818</t>
2819<t>
2820   Persistent HTTP connections have a number of advantages:
2821  <list style="symbols">
2822      <t>
2823        By opening and closing fewer TCP connections, CPU time is saved
2824        in routers and hosts (clients, servers, proxies, gateways,
2825        tunnels, or caches), and memory used for TCP protocol control
2826        blocks can be saved in hosts.
2827      </t>
2828      <t>
2829        HTTP requests and responses can be pipelined on a connection.
2830        Pipelining allows a client to make multiple requests without
2831        waiting for each response, allowing a single TCP connection to
2832        be used much more efficiently, with much lower elapsed time.
2833      </t>
2834      <t>
2835        Network congestion is reduced by reducing the number of packets
2836        caused by TCP opens, and by allowing TCP sufficient time to
2837        determine the congestion state of the network.
2838      </t>
2839      <t>
2840        Latency on subsequent requests is reduced since there is no time
2841        spent in TCP's connection opening handshake.
2842      </t>
2843      <t>
2844        HTTP can evolve more gracefully, since errors can be reported
2845        without the penalty of closing the TCP connection. Clients using
2846        future versions of HTTP might optimistically try a new feature,
2847        but if communicating with an older server, retry with old
2848        semantics after an error is reported.
2849      </t>
2850    </list>
2851</t>
2852<t>
2853   HTTP implementations SHOULD implement persistent connections.
2854</t>
2855</section>
2856
2857<section title="Overall Operation" anchor="persistent.overall">
2858<t>
2859   A significant difference between HTTP/1.1 and earlier versions of
2860   HTTP is that persistent connections are the default behavior of any
2861   HTTP connection. That is, unless otherwise indicated, the client
2862   SHOULD assume that the server will maintain a persistent connection,
2863   even after error responses from the server.
2864</t>
2865<t>
2866   Persistent connections provide a mechanism by which a client and a
2867   server can signal the close of a TCP connection. This signaling takes
2868   place using the Connection header field (<xref target="header.connection"/>). Once a close
2869   has been signaled, the client MUST NOT send any more requests on that
2870   connection.
2871</t>
2872
2873<section title="Negotiation" anchor="persistent.negotiation">
2874<t>
2875   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2876   maintain a persistent connection unless a Connection header field including
2877   the connection-token "close" was sent in the request. If the server
2878   chooses to close the connection immediately after sending the
2879   response, it SHOULD send a Connection header field including the
2880   connection-token "close".
2881</t>
2882<t>
2883   An HTTP/1.1 client MAY expect a connection to remain open, but would
2884   decide to keep it open based on whether the response from a server
2885   contains a Connection header field with the connection-token close. In case
2886   the client does not want to maintain a connection for more than that
2887   request, it SHOULD send a Connection header field including the
2888   connection-token close.
2889</t>
2890<t>
2891   If either the client or the server sends the close token in the
2892   Connection header field, that request becomes the last one for the
2893   connection.
2894</t>
2895<t>
2896   Clients and servers SHOULD NOT  assume that a persistent connection is
2897   maintained for HTTP versions less than 1.1 unless it is explicitly
2898   signaled. See <xref target="compatibility.with.http.1.0.persistent.connections"/> for more information on backward
2899   compatibility with HTTP/1.0 clients.
2900</t>
2901<t>
2902   Each persistent connection applies to only one transport link.
2903</t>
2904<t>
2905   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2906   with an HTTP/1.0 client (but see Section 19.7.1 of <xref target="RFC2068"/>
2907   for information and discussion of the problems with the Keep-Alive header field
2908   implemented by many HTTP/1.0 clients).
2909</t>
2910<t>
2911   In order to remain persistent, all messages on the connection MUST
2912   have a self-defined message length (i.e., one not defined by closure
2913   of the connection), as described in <xref target="message.body"/>.
2914</t>
2915</section>
2916
2917<section title="Pipelining" anchor="pipelining">
2918<t>
2919   A client that supports persistent connections MAY "pipeline" its
2920   requests (i.e., send multiple requests without waiting for each
2921   response). A server MUST send its responses to those requests in the
2922   same order that the requests were received.
2923</t>
2924<t>
2925   Clients which assume persistent connections and pipeline immediately
2926   after connection establishment SHOULD be prepared to retry their
2927   connection if the first pipelined attempt fails. If a client does
2928   such a retry, it MUST NOT pipeline before it knows the connection is
2929   persistent. Clients MUST also be prepared to resend their requests if
2930   the server closes the connection before sending all of the
2931   corresponding responses.
2932</t>
2933<t>
2934   Clients SHOULD NOT pipeline requests using non-idempotent request methods or
2935   non-idempotent sequences of request methods (see Section 6.1.2 of <xref target="Part2"/>). Otherwise, a
2936   premature termination of the transport connection could lead to
2937   indeterminate results. A client wishing to send a non-idempotent
2938   request SHOULD wait to send that request until it has received the
2939   response status line for the previous request.
2940</t>
2941</section>
2942</section>
2943
2944<section title="Practical Considerations" anchor="persistent.practical">
2945<t>
2946   Servers will usually have some time-out value beyond which they will
2947   no longer maintain an inactive connection. Proxy servers might make
2948   this a higher value since it is likely that the client will be making
2949   more connections through the same server. The use of persistent
2950   connections places no requirements on the length (or existence) of
2951   this time-out for either the client or the server.
2952</t>
2953<t>
2954   When a client or server wishes to time-out it SHOULD issue a graceful
2955   close on the transport connection. Clients and servers SHOULD both
2956   constantly watch for the other side of the transport close, and
2957   respond to it as appropriate. If a client or server does not detect
2958   the other side's close promptly it could cause unnecessary resource
2959   drain on the network.
2960</t>
2961<t>
2962   A client, server, or proxy MAY close the transport connection at any
2963   time. For example, a client might have started to send a new request
2964   at the same time that the server has decided to close the "idle"
2965   connection. From the server's point of view, the connection is being
2966   closed while it was idle, but from the client's point of view, a
2967   request is in progress.
2968</t>
2969<t>
2970   Clients (including proxies) SHOULD limit the number of simultaneous
2971   connections that they maintain to a given server (including proxies).
2972</t>
2973<t>
2974   Previous revisions of HTTP gave a specific number of connections as a
2975   ceiling, but this was found to be impractical for many applications. As a
2976   result, this specification does not mandate a particular maximum number of
2977   connections, but instead encourages clients to be conservative when opening
2978   multiple connections.
2979</t>
2980<t>
2981   In particular, while using multiple connections avoids the "head-of-line
2982   blocking" problem (whereby a request that takes significant server-side
2983   processing and/or has a large payload can block subsequent requests on the
2984   same connection), each connection used consumes server resources (sometimes
2985   significantly), and furthermore using multiple connections can cause
2986   undesirable side effects in congested networks.
2987</t>
2988<t>
2989   Note that servers might reject traffic that they deem abusive, including an
2990   excessive number of connections from a client.
2991</t>
2992</section>
2993
2994<section title="Retrying Requests" anchor="persistent.retrying.requests">
2995<t>
2996   Senders can close the transport connection at any time. Therefore,
2997   clients, servers, and proxies MUST be able to recover
2998   from asynchronous close events. Client software MAY reopen the
2999   transport connection and retransmit the aborted sequence of requests
3000   without user interaction so long as the request sequence is
3001   idempotent (see Section 6.1.2 of <xref target="Part2"/>). Non-idempotent request methods or sequences
3002   MUST NOT be automatically retried, although user agents MAY offer a
3003   human operator the choice of retrying the request(s). Confirmation by
3004   user-agent software with semantic understanding of the application
3005   MAY substitute for user confirmation. The automatic retry SHOULD NOT
3006   be repeated if the second sequence of requests fails.
3007</t>
3008</section>
3009</section>
3010
3011<section title="Message Transmission Requirements" anchor="message.transmission.requirements">
3012
3013<section title="Persistent Connections and Flow Control" anchor="persistent.flow">
3014<t>
3015   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
3016   flow control mechanisms to resolve temporary overloads, rather than
3017   terminating connections with the expectation that clients will retry.
3018   The latter technique can exacerbate network congestion.
3019</t>
3020</section>
3021
3022<section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">
3023<t>
3024   An HTTP/1.1 (or later) client sending a message body SHOULD monitor
3025   the network connection for an error status code while it is transmitting
3026   the request. If the client sees an error status code, it SHOULD
3027   immediately cease transmitting the body. If the body is being sent
3028   using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
3029   empty trailer MAY be used to prematurely mark the end of the message.
3030   If the body was preceded by a Content-Length header field, the client MUST
3031   close the connection.
3032</t>
3033</section>
3034
3035<section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
3036<t>
3037   The purpose of the 100 (Continue) status code (see Section 7.1.1 of <xref target="Part2"/>) is to
3038   allow a client that is sending a request message with a request body
3039   to determine if the origin server is willing to accept the request
3040   (based on the request header fields) before the client sends the request
3041   body. In some cases, it might either be inappropriate or highly
3042   inefficient for the client to send the body if the server will reject
3043   the message without looking at the body.
3044</t>
3045<t>
3046   Requirements for HTTP/1.1 clients:
3047  <list style="symbols">
3048    <t>
3049        If a client will wait for a 100 (Continue) response before
3050        sending the request body, it MUST send an Expect header
3051        field (Section 10.3 of <xref target="Part2"/>) with the "100-continue" expectation.
3052    </t>
3053    <t>
3054        A client MUST NOT send an Expect header field (Section 10.3 of <xref target="Part2"/>)
3055        with the "100-continue" expectation if it does not intend
3056        to send a request body.
3057    </t>
3058  </list>
3059</t>
3060<t>
3061   Because of the presence of older implementations, the protocol allows
3062   ambiguous situations in which a client might send "Expect: 100-continue"
3063   without receiving either a 417 (Expectation Failed)
3064   or a 100 (Continue) status code. Therefore, when a client sends this
3065   header field to an origin server (possibly via a proxy) from which it
3066   has never seen a 100 (Continue) status code, the client SHOULD NOT 
3067   wait for an indefinite period before sending the request body.
3068</t>
3069<t>
3070   Requirements for HTTP/1.1 origin servers:
3071  <list style="symbols">
3072    <t> Upon receiving a request which includes an Expect header
3073        field with the "100-continue" expectation, an origin server MUST
3074        either respond with 100 (Continue) status code and continue to read
3075        from the input stream, or respond with a final status code. The
3076        origin server MUST NOT wait for the request body before sending
3077        the 100 (Continue) response. If it responds with a final status
3078        code, it MAY close the transport connection or it MAY continue
3079        to read and discard the rest of the request.  It MUST NOT
3080        perform the request method if it returns a final status code.
3081    </t>
3082    <t> An origin server SHOULD NOT  send a 100 (Continue) response if
3083        the request message does not include an Expect header
3084        field with the "100-continue" expectation, and MUST NOT send a
3085        100 (Continue) response if such a request comes from an HTTP/1.0
3086        (or earlier) client. There is an exception to this rule: for
3087        compatibility with <xref target="RFC2068"/>, a server MAY send a 100 (Continue)
3088        status code in response to an HTTP/1.1 PUT or POST request that does
3089        not include an Expect header field with the "100-continue"
3090        expectation. This exception, the purpose of which is
3091        to minimize any client processing delays associated with an
3092        undeclared wait for 100 (Continue) status code, applies only to
3093        HTTP/1.1 requests, and not to requests with any other HTTP-version
3094        value.
3095    </t>
3096    <t> An origin server MAY omit a 100 (Continue) response if it has
3097        already received some or all of the request body for the
3098        corresponding request.
3099    </t>
3100    <t> An origin server that sends a 100 (Continue) response MUST
3101        ultimately send a final status code, once the request body is
3102        received and processed, unless it terminates the transport
3103        connection prematurely.
3104    </t>
3105    <t> If an origin server receives a request that does not include an
3106        Expect header field with the "100-continue" expectation,
3107        the request includes a request body, and the server responds
3108        with a final status code before reading the entire request body
3109        from the transport connection, then the server SHOULD NOT  close
3110        the transport connection until it has read the entire request,
3111        or until the client closes the connection. Otherwise, the client
3112        might not reliably receive the response message. However, this
3113        requirement ought not be construed as preventing a server from
3114        defending itself against denial-of-service attacks, or from
3115        badly broken client implementations.
3116      </t>
3117    </list>
3118</t>
3119<t>
3120   Requirements for HTTP/1.1 proxies:
3121  <list style="symbols">
3122    <t> If a proxy receives a request that includes an Expect header
3123        field with the "100-continue" expectation, and the proxy
3124        either knows that the next-hop server complies with HTTP/1.1 or
3125        higher, or does not know the HTTP version of the next-hop
3126        server, it MUST forward the request, including the Expect header
3127        field.
3128    </t>
3129    <t> If the proxy knows that the version of the next-hop server is
3130        HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
3131        respond with a 417 (Expectation Failed) status code.
3132    </t>
3133    <t> Proxies SHOULD maintain a record of the HTTP version
3134        numbers received from recently-referenced next-hop servers.
3135    </t>
3136    <t> A proxy MUST NOT forward a 100 (Continue) response if the
3137        request message was received from an HTTP/1.0 (or earlier)
3138        client and did not include an Expect header field with
3139        the "100-continue" expectation. This requirement overrides the
3140        general rule for forwarding of 1xx responses (see Section 7.1 of <xref target="Part2"/>).
3141    </t>
3142  </list>
3143</t>
3144</section>
3145
3146<section title="Closing Connections on Error" anchor="closing.connections.on.error">
3147<t>
3148   If the client is sending data, a server implementation using TCP
3149   SHOULD be careful to ensure that the client acknowledges receipt of
3150   the packet(s) containing the response, before the server closes the
3151   input connection. If the client continues sending data to the server
3152   after the close, the server's TCP stack will send a reset packet to
3153   the client, which might erase the client's unacknowledged input buffers
3154   before they can be read and interpreted by the HTTP application.
3155</t>
3156</section>
3157
3158</section>
3159
3160<section title="Upgrade" anchor="header.upgrade">
3161  <iref primary="true" item="Upgrade header field"/>
3162  <iref primary="true" item="Header Fields" subitem="Upgrade"/>
3163 
3164 
3165 
3166 
3167<t>
3168   The "Upgrade" header field allows the client to specify what
3169   additional communication protocols it would like to use, if the server
3170   chooses to switch protocols. Servers can use it to indicate what protocols
3171   they are willing to switch to.
3172</t>
3173<figure><iref primary="true" item="Grammar" subitem="Upgrade"/><artwork type="abnf2616"><![CDATA[
3174  Upgrade          = 1#protocol
3175
3176  protocol         = protocol-name ["/" protocol-version]
3177  protocol-name    = token
3178  protocol-version = token
3179]]></artwork></figure>
3180<t>
3181   For example,
3182</t>
3183<figure><artwork type="example"><![CDATA[
3184  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
3185]]></artwork></figure>
3186<t>
3187   The Upgrade header field is intended to provide a simple mechanism
3188   for transitioning from HTTP/1.1 to some other, incompatible protocol. It
3189   does so by allowing the client to advertise its desire to use another
3190   protocol, such as a later version of HTTP with a higher major version
3191   number, even though the current request has been made using HTTP/1.1.
3192   This eases the difficult transition between incompatible protocols by
3193   allowing the client to initiate a request in the more commonly
3194   supported protocol while indicating to the server that it would like
3195   to use a "better" protocol if available (where "better" is determined
3196   by the server, possibly according to the nature of the request method
3197   or target resource).
3198</t>
3199<t>
3200   The Upgrade header field only applies to switching application-layer
3201   protocols upon the existing transport-layer connection. Upgrade
3202   cannot be used to insist on a protocol change; its acceptance and use
3203   by the server is optional. The capabilities and nature of the
3204   application-layer communication after the protocol change is entirely
3205   dependent upon the new protocol chosen, although the first action
3206   after changing the protocol MUST be a response to the initial HTTP
3207   request containing the Upgrade header field.
3208</t>
3209<t>
3210   The Upgrade header field only applies to the immediate connection.
3211   Therefore, the upgrade keyword MUST be supplied within a Connection
3212   header field (<xref target="header.connection"/>) whenever Upgrade is present in an
3213   HTTP/1.1 message.
3214</t>
3215<t>
3216   The Upgrade header field cannot be used to indicate a switch to a
3217   protocol on a different connection. For that purpose, it is more
3218   appropriate to use a 3xx redirection response (Section 7.3 of <xref target="Part2"/>).
3219</t>
3220<t>
3221   Servers MUST include the "Upgrade" header field in 101 (Switching
3222   Protocols) responses to indicate which protocol(s) are being switched to,
3223   and MUST include it in 426 (Upgrade Required) responses to indicate
3224   acceptable protocols to upgrade to. Servers MAY include it in any other
3225   response to indicate that they are willing to upgrade to one of the
3226   specified protocols.
3227</t>
3228<t>
3229   This specification only defines the protocol name "HTTP" for use by
3230   the family of Hypertext Transfer Protocols, as defined by the HTTP
3231   version rules of <xref target="http.version"/> and future updates to this
3232   specification. Additional tokens can be registered with IANA using the
3233   registration procedure defined in <xref target="upgrade.token.registry"/>.
3234</t>
3235</section>
3236
3237</section>
3238
3239<section title="IANA Considerations" anchor="IANA.considerations">
3240
3241<section title="Header Field Registration" anchor="header.field.registration">
3242<t>
3243   HTTP header fields are registered within the Message Header Field Registry
3244   <xref target="RFC3864"/> maintained by IANA at
3245   <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>.
3246</t>
3247<t>
3248   This document defines the following HTTP header fields, so their
3249   associated registry entries shall be updated according to the permanent
3250   registrations below:
3251</t>
3252
3253<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
3254<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
3255   <ttcol>Header Field Name</ttcol>
3256   <ttcol>Protocol</ttcol>
3257   <ttcol>Status</ttcol>
3258   <ttcol>Reference</ttcol>
3259
3260   <c>Connection</c>
3261   <c>http</c>
3262   <c>standard</c>
3263   <c>
3264      <xref target="header.connection"/>
3265   </c>
3266   <c>Content-Length</c>
3267   <c>http</c>
3268   <c>standard</c>
3269   <c>
3270      <xref target="header.content-length"/>
3271   </c>
3272   <c>Host</c>
3273   <c>http</c>
3274   <c>standard</c>
3275   <c>
3276      <xref target="header.host"/>
3277   </c>
3278   <c>TE</c>
3279   <c>http</c>
3280   <c>standard</c>
3281   <c>
3282      <xref target="header.te"/>
3283   </c>
3284   <c>Trailer</c>
3285   <c>http</c>
3286   <c>standard</c>
3287   <c>
3288      <xref target="header.trailer"/>
3289   </c>
3290   <c>Transfer-Encoding</c>
3291   <c>http</c>
3292   <c>standard</c>
3293   <c>
3294      <xref target="header.transfer-encoding"/>
3295   </c>
3296   <c>Upgrade</c>
3297   <c>http</c>
3298   <c>standard</c>
3299   <c>
3300      <xref target="header.upgrade"/>
3301   </c>
3302   <c>Via</c>
3303   <c>http</c>
3304   <c>standard</c>
3305   <c>
3306      <xref target="header.via"/>
3307   </c>
3308</texttable>
3309<!--(END)-->
3310
3311<t>
3312   Furthermore, the header field-name "Close" shall be registered as
3313   "reserved", since using that name as an HTTP header field might
3314   conflict with the "close" connection option of the "Connection"
3315   header field (<xref target="header.connection"/>).
3316</t>
3317<texttable align="left" suppress-title="true">
3318   <ttcol>Header Field Name</ttcol>
3319   <ttcol>Protocol</ttcol>
3320   <ttcol>Status</ttcol>
3321   <ttcol>Reference</ttcol>
3322
3323   <c>Close</c>
3324   <c>http</c>
3325   <c>reserved</c>
3326   <c>
3327      <xref target="header.field.registration"/>
3328   </c>
3329</texttable>
3330<t>
3331   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
3332</t>
3333</section>
3334
3335<section title="URI Scheme Registration" anchor="uri.scheme.registration">
3336<t>
3337   IANA maintains the registry of URI Schemes <xref target="RFC4395"/> at
3338   <eref target="http://www.iana.org/assignments/uri-schemes.html"/>.
3339</t>
3340<t>
3341   This document defines the following URI schemes, so their
3342   associated registry entries shall be updated according to the permanent
3343   registrations below:
3344</t>
3345<texttable align="left" suppress-title="true">
3346   <ttcol>URI Scheme</ttcol>
3347   <ttcol>Description</ttcol>
3348   <ttcol>Reference</ttcol>
3349
3350   <c>http</c>
3351   <c>Hypertext Transfer Protocol</c>
3352   <c><xref target="http.uri"/></c>
3353
3354   <c>https</c>
3355   <c>Hypertext Transfer Protocol Secure</c>
3356   <c><xref target="https.uri"/></c>
3357</texttable>
3358</section>
3359
3360<section title="Internet Media Type Registrations" anchor="internet.media.type.http">
3361<t>
3362   This document serves as the specification for the Internet media types
3363   "message/http" and "application/http". The following is to be registered with
3364   IANA (see <xref target="RFC4288"/>).
3365</t>
3366<section title="Internet Media Type message/http" anchor="internet.media.type.message.http">
3367<iref item="Media Type" subitem="message/http" primary="true"/>
3368<iref item="message/http Media Type" primary="true"/>
3369<t>
3370   The message/http type can be used to enclose a single HTTP request or
3371   response message, provided that it obeys the MIME restrictions for all
3372   "message" types regarding line length and encodings.
3373</t>
3374<t>
3375  <list style="hanging">
3376    <t hangText="Type name:">
3377      message
3378    </t>
3379    <t hangText="Subtype name:">
3380      http
3381    </t>
3382    <t hangText="Required parameters:">
3383      none
3384    </t>
3385    <t hangText="Optional parameters:">
3386      version, msgtype
3387      <list style="hanging">
3388        <t hangText="version:">
3389          The HTTP-version number of the enclosed message
3390          (e.g., "1.1"). If not present, the version can be
3391          determined from the first line of the body.
3392        </t>
3393        <t hangText="msgtype:">
3394          The message type — "request" or "response". If not
3395          present, the type can be determined from the first
3396          line of the body.
3397        </t>
3398      </list>
3399    </t>
3400    <t hangText="Encoding considerations:">
3401      only "7bit", "8bit", or "binary" are permitted
3402    </t>
3403    <t hangText="Security considerations:">
3404      none
3405    </t>
3406    <t hangText="Interoperability considerations:">
3407      none
3408    </t>
3409    <t hangText="Published specification:">
3410      This specification (see <xref target="internet.media.type.message.http"/>).
3411    </t>
3412    <t hangText="Applications that use this media type:">
3413    </t>
3414    <t hangText="Additional information:">
3415      <list style="hanging">
3416        <t hangText="Magic number(s):">none</t>
3417        <t hangText="File extension(s):">none</t>
3418        <t hangText="Macintosh file type code(s):">none</t>
3419      </list>
3420    </t>
3421    <t hangText="Person and email address to contact for further information:">
3422      See Authors Section.
3423    </t>
3424    <t hangText="Intended usage:">
3425      COMMON
3426    </t>
3427    <t hangText="Restrictions on usage:">
3428      none
3429    </t>
3430    <t hangText="Author/Change controller:">
3431      IESG
3432    </t>
3433  </list>
3434</t>
3435</section>
3436<section title="Internet Media Type application/http" anchor="internet.media.type.application.http">
3437<iref item="Media Type" subitem="application/http" primary="true"/>
3438<iref item="application/http Media Type" primary="true"/>
3439<t>
3440   The application/http type can be used to enclose a pipeline of one or more
3441   HTTP request or response messages (not intermixed).
3442</t>
3443<t>
3444  <list style="hanging">
3445    <t hangText="Type name:">
3446      application
3447    </t>
3448    <t hangText="Subtype name:">
3449      http
3450    </t>
3451    <t hangText="Required parameters:">
3452      none
3453    </t>
3454    <t hangText="Optional parameters:">
3455      version, msgtype
3456      <list style="hanging">
3457        <t hangText="version:">
3458          The HTTP-version number of the enclosed messages
3459          (e.g., "1.1"). If not present, the version can be
3460          determined from the first line of the body.
3461        </t>
3462        <t hangText="msgtype:">
3463          The message type — "request" or "response". If not
3464          present, the type can be determined from the first
3465          line of the body.
3466        </t>
3467      </list>
3468    </t>
3469    <t hangText="Encoding considerations:">
3470      HTTP messages enclosed by this type
3471      are in "binary" format; use of an appropriate
3472      Content-Transfer-Encoding is required when
3473      transmitted via E-mail.
3474    </t>
3475    <t hangText="Security considerations:">
3476      none
3477    </t>
3478    <t hangText="Interoperability considerations:">
3479      none
3480    </t>
3481    <t hangText="Published specification:">
3482      This specification (see <xref target="internet.media.type.application.http"/>).
3483    </t>
3484    <t hangText="Applications that use this media type:">
3485    </t>
3486    <t hangText="Additional information:">
3487      <list style="hanging">
3488        <t hangText="Magic number(s):">none</t>
3489        <t hangText="File extension(s):">none</t>
3490        <t hangText="Macintosh file type code(s):">none</t>
3491      </list>
3492    </t>
3493    <t hangText="Person and email address to contact for further information:">
3494      See Authors Section.
3495    </t>
3496    <t hangText="Intended usage:">
3497      COMMON
3498    </t>
3499    <t hangText="Restrictions on usage:">
3500      none
3501    </t>
3502    <t hangText="Author/Change controller:">
3503      IESG
3504    </t>
3505  </list>
3506</t>
3507</section>
3508</section>
3509
3510<section title="Transfer Coding Registry" anchor="transfer.coding.registry">
3511<t>
3512   The HTTP Transfer Coding Registry defines the name space for transfer
3513   coding names.
3514</t>
3515<t>
3516   Registrations MUST include the following fields:
3517   <list style="symbols">
3518     <t>Name</t>
3519     <t>Description</t>
3520     <t>Pointer to specification text</t>
3521   </list>
3522</t>
3523<t>
3524   Names of transfer codings MUST NOT overlap with names of content codings
3525   (Section 2.2 of <xref target="Part3"/>) unless the encoding transformation is identical, as it
3526   is the case for the compression codings defined in
3527   <xref target="compression.codings"/>.
3528</t>
3529<t>
3530   Values to be added to this name space require IETF Review (see
3531   Section 4.1 of <xref target="RFC5226"/>), and MUST
3532   conform to the purpose of transfer coding defined in this section.
3533</t>
3534<t>
3535   The registry itself is maintained at
3536   <eref target="http://www.iana.org/assignments/http-parameters"/>.
3537</t>
3538</section>
3539
3540<section title="Transfer Coding Registrations" anchor="transfer.coding.registration">
3541<t>
3542   The HTTP Transfer Coding Registry shall be updated with the registrations
3543   below:
3544</t>
3545<texttable align="left" suppress-title="true" anchor="iana.transfer.coding.registration.table">
3546   <ttcol>Name</ttcol>
3547   <ttcol>Description</ttcol>
3548   <ttcol>Reference</ttcol>
3549   <c>chunked</c>
3550   <c>Transfer in a series of chunks</c>
3551   <c>
3552      <xref target="chunked.encoding"/>
3553   </c>
3554   <c>compress</c>
3555   <c>UNIX "compress" program method</c>
3556   <c>
3557      <xref target="compress.coding"/>
3558   </c>
3559   <c>deflate</c>
3560   <c>"deflate" compression mechanism (<xref target="RFC1951"/>) used inside
3561   the "zlib" data format (<xref target="RFC1950"/>)
3562   </c>
3563   <c>
3564      <xref target="deflate.coding"/>
3565   </c>
3566   <c>gzip</c>
3567   <c>Same as GNU zip <xref target="RFC1952"/></c>
3568   <c>
3569      <xref target="gzip.coding"/>
3570   </c>
3571</texttable>
3572</section>
3573
3574<section title="Upgrade Token Registry" anchor="upgrade.token.registry">
3575<t>
3576   The HTTP Upgrade Token Registry defines the name space for protocol-name
3577   tokens used to identify protocols in the Upgrade header field.
3578   Each registered protocol-name is associated with contact information and
3579   an optional set of specifications that details how the connection
3580   will be processed after it has been upgraded.
3581</t>
3582<t>
3583   Registrations require IETF Review (see
3584   Section 4.1 of <xref target="RFC5226"/>) and are subject to the
3585   following rules:
3586  <list style="numbers">
3587    <t>A protocol-name token, once registered, stays registered forever.</t>
3588    <t>The registration MUST name a responsible party for the
3589       registration.</t>
3590    <t>The registration MUST name a point of contact.</t>
3591    <t>The registration MAY name a set of specifications associated with
3592       that token. Such specifications need not be publicly available.</t>
3593    <t>The registration SHOULD name a set of expected "protocol-version"
3594       tokens associated with that token at the time of registration.</t>
3595    <t>The responsible party MAY change the registration at any time.
3596       The IANA will keep a record of all such changes, and make them
3597       available upon request.</t>
3598    <t>The IESG MAY reassign responsibility for a protocol token.
3599       This will normally only be used in the case when a
3600       responsible party cannot be contacted.</t>
3601  </list>
3602</t>
3603<t>
3604   This registration procedure for HTTP Upgrade Tokens replaces that
3605   previously defined in Section 7.2 of <xref target="RFC2817"/>.
3606</t>
3607</section>
3608
3609<section title="Upgrade Token Registration" anchor="upgrade.token.registration">
3610<t>
3611   The HTTP Upgrade Token Registry shall be updated with the registration
3612   below:
3613</t>
3614<texttable align="left" suppress-title="true">
3615   <ttcol>Value</ttcol>
3616   <ttcol>Description</ttcol>
3617   <ttcol>Expected Version Tokens</ttcol>
3618   <ttcol>Reference</ttcol>
3619
3620   <c>HTTP</c>
3621   <c>Hypertext Transfer Protocol</c>
3622   <c>any DIGIT.DIGIT (e.g, "2.0")</c>
3623   <c><xref target="http.version"/></c>
3624</texttable>
3625<t>
3626   The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
3627</t>
3628</section>
3629
3630</section>
3631
3632<section title="Security Considerations" anchor="security.considerations">
3633<t>
3634   This section is meant to inform application developers, information
3635   providers, and users of the security limitations in HTTP/1.1 as
3636   described by this document. The discussion does not include
3637   definitive solutions to the problems revealed, though it does make
3638   some suggestions for reducing security risks.
3639</t>
3640
3641<section title="Personal Information" anchor="personal.information">
3642<t>
3643   HTTP clients are often privy to large amounts of personal information
3644   (e.g., the user's name, location, mail address, passwords, encryption
3645   keys, etc.), and SHOULD be very careful to prevent unintentional
3646   leakage of this information.
3647   We very strongly recommend that a convenient interface be provided
3648   for the user to control dissemination of such information, and that
3649   designers and implementors be particularly careful in this area.
3650   History shows that errors in this area often create serious security
3651   and/or privacy problems and generate highly adverse publicity for the
3652   implementor's company.
3653</t>
3654</section>
3655
3656<section title="Abuse of Server Log Information" anchor="abuse.of.server.log.information">
3657<t>
3658   A server is in the position to save personal data about a user's
3659   requests which might identify their reading patterns or subjects of
3660   interest.  In particular, log information gathered at an intermediary
3661   often contains a history of user agent interaction, across a multitude
3662   of sites, that can be traced to individual users.
3663</t>
3664<t>
3665   HTTP log information is confidential in nature; its handling is often
3666   constrained by laws and regulations.  Log information needs to be securely
3667   stored and appropriate guidelines followed for its analysis.
3668   Anonymization of personal information within individual entries helps,
3669   but is generally not sufficient to prevent real log traces from being
3670   re-identified based on correlation with other access characteristics.
3671   As such, access traces that are keyed to a specific client should not
3672   be published even if the key is pseudonymous.
3673</t>
3674<t>
3675   To minimize the risk of theft or accidental publication, log information
3676   should be purged of personally identifiable information, including
3677   user identifiers, IP addresses, and user-provided query parameters,
3678   as soon as that information is no longer necessary to support operational
3679   needs for security, auditing, or fraud control.
3680</t>
3681</section>
3682
3683<section title="Attacks Based On File and Path Names" anchor="attack.pathname">
3684<t>
3685   Implementations of HTTP origin servers SHOULD be careful to restrict
3686   the documents returned by HTTP requests to be only those that were
3687   intended by the server administrators. If an HTTP server translates
3688   HTTP URIs directly into file system calls, the server MUST take
3689   special care not to serve files that were not intended to be
3690   delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
3691   other operating systems use ".." as a path component to indicate a
3692   directory level above the current one. On such a system, an HTTP
3693   server MUST disallow any such construct in the request-target if it
3694   would otherwise allow access to a resource outside those intended to
3695   be accessible via the HTTP server. Similarly, files intended for
3696   reference only internally to the server (such as access control
3697   files, configuration files, and script code) MUST be protected from
3698   inappropriate retrieval, since they might contain sensitive
3699   information. Experience has shown that minor bugs in such HTTP server
3700   implementations have turned into security risks.
3701</t>
3702</section>
3703
3704<section title="DNS-related Attacks" anchor="dns.related.attacks">
3705<t>
3706   HTTP clients rely heavily on the Domain Name Service (DNS), and are thus
3707   generally prone to security attacks based on the deliberate misassociation
3708   of IP addresses and DNS names not protected by DNSSec. Clients need to be
3709   cautious in assuming the validity of an IP number/DNS name association unless
3710   the response is protected by DNSSec (<xref target="RFC4033"/>).
3711</t>
3712</section>
3713
3714<section title="Intermediaries and Caching" anchor="attack.intermediaries">
3715<t>
3716   By their very nature, HTTP intermediaries are men-in-the-middle, and
3717   represent an opportunity for man-in-the-middle attacks. Compromise of
3718   the systems on which the intermediaries run can result in serious security
3719   and privacy problems. Intermediaries have access to security-related
3720   information, personal information about individual users and
3721   organizations, and proprietary information belonging to users and
3722   content providers. A compromised intermediary, or an intermediary
3723   implemented or configured without regard to security and privacy
3724   considerations, might be used in the commission of a wide range of
3725   potential attacks.
3726</t>
3727<t>
3728   Intermediaries that contain a shared cache are especially vulnerable
3729   to cache poisoning attacks.
3730</t>
3731<t>
3732   Implementors need to consider the privacy and security
3733   implications of their design and coding decisions, and of the
3734   configuration options they provide to operators (especially the
3735   default configuration).
3736</t>
3737<t>
3738   Users need to be aware that intermediaries are no more trustworthy than
3739   the people who run them; HTTP itself cannot solve this problem.
3740</t>
3741<t>
3742   The judicious use of cryptography, when appropriate, might suffice to
3743   protect against a broad range of security and privacy attacks. Such
3744   cryptography is beyond the scope of the HTTP/1.1 specification.
3745</t>
3746</section>
3747
3748<section title="Protocol Element Size Overflows" anchor="attack.protocol.element.size.overflows">
3749<t>
3750   Because HTTP uses mostly textual, character-delimited fields, attackers can
3751   overflow buffers in implementations, and/or perform a Denial of Service
3752   against implementations that accept fields with unlimited lengths.
3753</t>
3754<t>
3755   To promote interoperability, this specification makes specific
3756   recommendations for minimum size limits on request-line
3757   (<xref target="request.line"/>)
3758   and blocks of header fields (<xref target="header.fields"/>). These are
3759   minimum recommendations, chosen to be supportable even by implementations
3760   with limited resources; it is expected that most implementations will
3761   choose substantially higher limits.
3762</t>
3763<t>
3764   This specification also provides a way for servers to reject messages that
3765   have request-targets that are too long (Section 7.4.12 of <xref target="Part2"/>) or request entities
3766   that are too large (Section 7.4 of <xref target="Part2"/>).
3767</t>
3768<t>
3769   Other fields (including but not limited to request methods, response status
3770   phrases, header field-names, and body chunks) SHOULD be limited by
3771   implementations carefully, so as to not impede interoperability.
3772</t>
3773</section>
3774</section>
3775
3776<section title="Acknowledgments" anchor="acks">
3777<t>
3778   This edition of HTTP builds on the many contributions that went into
3779   <xref target="RFC1945" format="none">RFC 1945</xref>,
3780   <xref target="RFC2068" format="none">RFC 2068</xref>,
3781   <xref target="RFC2145" format="none">RFC 2145</xref>, and
3782   <xref target="RFC2616" format="none">RFC 2616</xref>, including
3783   substantial contributions made by the previous authors, editors, and
3784   working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
3785   Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
3786   Paul J. Leach, and Mark Nottingham.
3787   See Section 16 of <xref target="RFC2616"/> for additional
3788   acknowledgements from prior revisions.
3789</t>
3790<t>
3791   Since 1999, the following contributors have helped improve the HTTP
3792   specification by reporting bugs, asking smart questions, drafting or
3793   reviewing text, and evaluating open issues:
3794</t>
3795
3796<t>Adam Barth,
3797Adam Roach,
3798Addison Phillips,
3799Adrian Chadd,
3800Adrien de Croy,
3801Alan Ford,
3802Alan Ruttenberg,
3803Albert Lunde,
3804Alex Rousskov,
3805Alexey Melnikov,
3806Alisha Smith,
3807Amichai Rothman,
3808Amit Klein,
3809Amos Jeffries,
3810Andreas Maier,
3811Andreas Petersson,
3812Anne van Kesteren,
3813Anthony Bryan,
3814Asbjorn Ulsberg,
3815Balachander Krishnamurthy,
3816Barry Leiba,
3817Ben Laurie,
3818Benjamin Niven-Jenkins,
3819Bil Corry,
3820Bill Burke,
3821Bjoern Hoehrmann,
3822Bob Scheifler,
3823Boris Zbarsky,
3824Brett Slatkin,
3825Brian Kell,
3826Brian McBarron,
3827Brian Pane,
3828Brian Smith,
3829Bryce Nesbitt,
3830Cameron Heavon-Jones,
3831Carl Kugler,
3832Carsten Bormann,
3833Charles Fry,
3834Chris Newman,
3835Cyrus Daboo,
3836Dale Robert Anderson,
3837Dan Winship,
3838Daniel Stenberg,
3839Dave Cridland,
3840Dave Crocker,
3841Dave Kristol,
3842David Booth,
3843David Singer,
3844David W. Morris,
3845Diwakar Shetty,
3846Dmitry Kurochkin,
3847Drummond Reed,
3848Duane Wessels,
3849Edward Lee,
3850Eliot Lear,
3851Eran Hammer-Lahav,
3852Eric D. Williams,
3853Eric J. Bowman,
3854Eric Lawrence,
3855Eric Rescorla,
3856Erik Aronesty,
3857Florian Weimer,
3858Frank Ellermann,
3859Fred Bohle,
3860Geoffrey Sneddon,
3861Gervase Markham,
3862Greg Wilkins,
3863Harald Tveit Alvestrand,
3864Harry Halpin,
3865Helge Hess,
3866Henrik Nordstrom,
3867Henry S. Thompson,
3868Henry Story,
3869Herbert van de Sompel,
3870Howard Melman,
3871Hugo Haas,
3872Ian Hickson,
3873Ingo Struck,
3874J. Ross Nicoll,
3875James H. Manger,
3876James Lacey,
3877James M. Snell,
3878Jamie Lokier,
3879Jan Algermissen,
3880Jeff Hodges (for coming up with the term 'effective Request-URI'),
3881Jeff Walden,
3882Jim Luther,
3883Joe D. Williams,
3884Joe Gregorio,
3885Joe Orton,
3886John C. Klensin,
3887John C. Mallery,
3888John Cowan,
3889John Kemp,
3890John Panzer,
3891John Schneider,
3892John Stracke,
3893Jonas Sicking,
3894Jonathan Billington,
3895Jonathan Moore,
3896Jonathan Rees,
3897Jordi Ros,
3898Joris Dobbelsteen,
3899Josh Cohen,
3900Julien Pierre,
3901Jungshik Shin,
3902Justin Chapweske,
3903Justin Erenkrantz,
3904Justin James,
3905Kalvinder Singh,
3906Karl Dubost,
3907Keith Hoffman,
3908Keith Moore,
3909Koen Holtman,
3910Konstantin Voronkov,
3911Kris Zyp,
3912Lisa Dusseault,
3913Maciej Stachowiak,
3914Marc Schneider,
3915Marc Slemko,
3916Mark Baker,
3917Mark Pauley,
3918Markus Lanthaler,
3919Martin J. Duerst,
3920Martin Thomson,
3921Matt Lynch,
3922Matthew Cox,
3923Max Clark,
3924Michael Burrows,
3925Michael Hausenblas,
3926Mike Amundsen,
3927Mike Belshe,
3928Mike Kelly,
3929Mike Schinkel,
3930Miles Sabin,
3931Mykyta Yevstifeyev,
3932Nathan Rixham,
3933Nicholas Shanks,
3934Nico Williams,
3935Nicolas Alvarez,
3936Nicolas Mailhot,
3937Noah Slater,
3938Pablo Castro,
3939Pat Hayes,
3940Patrick R. McManus,
3941Paul E. Jones,
3942Paul Hoffman,
3943Paul Marquess,
3944Peter Saint-Andre,
3945Peter Watkins,
3946Phil Archer,
3947Phillip Hallam-Baker,
3948Poul-Henning Kamp,
3949Preethi Natarajan,
3950Ray Polk,
3951Reto Bachmann-Gmuer,
3952Richard Cyganiak,
3953Robert Brewer,
3954Robert Collins,
3955Robert O'Callahan,
3956Robert Olofsson,
3957Robert Sayre,
3958Robert Siemer,
3959Robert de Wilde,
3960Roberto Javier Godoy,
3961Ronny Widjaja,
3962S. Mike Dierken,
3963Salvatore Loreto,
3964Sam Johnston,
3965Sam Ruby,
3966Scott Lawrence (for maintaining the original issues list),
3967Sean B. Palmer,
3968Shane McCarron,
3969Stefan Eissing,
3970Stefan Tilkov,
3971Stefanos Harhalakis,
3972Stephane Bortzmeyer,
3973Stephen Farrell,
3974Stuart Williams,
3975Subbu Allamaraju,
3976Sylvain Hellegouarch,
3977Tapan Divekar,
3978Ted Hardie,
3979Thomas Broyer,
3980Thomas Nordin,
3981Thomas Roessler,
3982Tim Morgan,
3983Tim Olsen,
3984Travis Snoozy,
3985Tyler Close,
3986Vincent Murphy,
3987Wenbo Zhu,
3988Werner Baumann,
3989Wilbur Streett,
3990Wilfredo Sanchez Vega,
3991William A. Rowe Jr.,
3992William Chan,
3993Willy Tarreau,
3994Xiaoshu Wang,
3995Yaron Goland,
3996Yngve Nysaeter Pettersen,
3997Yogesh Bang,
3998Yutaka Oiwa,
3999Zed A. Shaw, and
4000Zhong Yu.
4001</t>
4002
4003</section>
4004
4005</middle>
4006<back>
4007
4008<references title="Normative References">
4009
4010<reference anchor="ISO-8859-1">
4011  <front>
4012    <title>
4013     Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1
4014    </title>
4015    <author>
4016      <organization>International Organization for Standardization</organization>
4017    </author>
4018    <date year="1998"/>
4019  </front>
4020  <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
4021</reference>
4022
4023<reference anchor="Part2">
4024  <front>
4025    <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>
4026    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
4027      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4028      <address><email>fielding@gbiv.com</email></address>
4029    </author>
4030    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
4031      <organization abbrev="W3C">World Wide Web Consortium</organization>
4032      <address><email>ylafon@w3.org</email></address>
4033    </author>
4034    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
4035      <organization abbrev="greenbytes">greenbytes GmbH</organization>
4036      <address><email>julian.reschke@greenbytes.de</email></address>
4037    </author>
4038    <date month="March" year="2012"/>
4039  </front>
4040  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-19"/>
4041 
4042</reference>
4043
4044<reference anchor="Part3">
4045  <front>
4046    <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
4047    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
4048      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4049      <address><email>fielding@gbiv.com</email></address>
4050    </author>
4051    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
4052      <organization abbrev="W3C">World Wide Web Consortium</organization>
4053      <address><email>ylafon@w3.org</email></address>
4054    </author>
4055    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
4056      <organization abbrev="greenbytes">greenbytes GmbH</organization>
4057      <address><email>julian.reschke@greenbytes.de</email></address>
4058    </author>
4059    <date month="March" year="2012"/>
4060  </front>
4061  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-19"/>
4062 
4063</reference>
4064
4065<reference anchor="Part6">
4066  <front>
4067    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
4068    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
4069      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4070      <address><email>fielding@gbiv.com</email></address>
4071    </author>
4072    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
4073      <organization abbrev="W3C">World Wide Web Consortium</organization>
4074      <address><email>ylafon@w3.org</email></address>
4075    </author>
4076    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
4077      <organization>Rackspace</organization>
4078      <address><email>mnot@mnot.net</email></address>
4079    </author>
4080    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
4081      <organization abbrev="greenbytes">greenbytes GmbH</organization>
4082      <address><email>julian.reschke@greenbytes.de</email></address>
4083    </author>
4084    <date month="March" year="2012"/>
4085  </front>
4086  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-19"/>
4087 
4088</reference>
4089
4090<reference anchor="RFC5234">
4091  <front>
4092    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
4093    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
4094      <organization>Brandenburg InternetWorking</organization>
4095      <address>
4096        <email>dcrocker@bbiw.net</email>
4097      </address> 
4098    </author>
4099    <author initials="P." surname="Overell" fullname="Paul Overell">
4100      <organization>THUS plc.</organization>
4101      <address>
4102        <email>paul.overell@thus.net</email>
4103      </address>
4104    </author>
4105    <date month="January" year="2008"/>
4106  </front>
4107  <seriesInfo name="STD" value="68"/>
4108  <seriesInfo name="RFC" value="5234"/>
4109</reference>
4110
4111<reference anchor="RFC2119">
4112  <front>
4113    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
4114    <author initials="S." surname="Bradner" fullname="Scott Bradner">
4115      <organization>Harvard University</organization>
4116      <address><email>sob@harvard.edu</email></address>
4117    </author>
4118    <date month="March" year="1997"/>
4119  </front>
4120  <seriesInfo name="BCP" value="14"/>
4121  <seriesInfo name="RFC" value="2119"/>
4122</reference>
4123
4124<reference anchor="RFC3986">
4125 <front>
4126  <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
4127  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
4128    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
4129    <address>
4130       <email>timbl@w3.org</email>
4131       <uri>http://www.w3.org/People/Berners-Lee/</uri>
4132    </address>
4133  </author>
4134  <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
4135    <organization abbrev="Day Software">Day Software</organization>
4136    <address>
4137      <email>fielding@gbiv.com</email>
4138      <uri>http://roy.gbiv.com/</uri>
4139    </address>
4140  </author>
4141  <author initials="L." surname="Masinter" fullname="Larry Masinter">
4142    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
4143    <address>
4144      <email>LMM@acm.org</email>
4145      <uri>http://larry.masinter.net/</uri>
4146    </address>
4147  </author>
4148  <date month="January" year="2005"/>
4149 </front>
4150 <seriesInfo name="STD" value="66"/>
4151 <seriesInfo name="RFC" value="3986"/>
4152</reference>
4153
4154<reference anchor="USASCII">
4155  <front>
4156    <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
4157    <author>
4158      <organization>American National Standards Institute</organization>
4159    </author>
4160    <date year="1986"/>
4161  </front>
4162  <seriesInfo name="ANSI" value="X3.4"/>
4163</reference>
4164
4165<reference anchor="RFC1950">
4166  <front>
4167    <title>ZLIB Compressed Data Format Specification version 3.3</title>
4168    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
4169      <organization>Aladdin Enterprises</organization>
4170      <address><email>ghost@aladdin.com</email></address>
4171    </author>
4172    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"/>
4173    <date month="May" year="1996"/>
4174  </front>
4175  <seriesInfo name="RFC" value="1950"/>
4176  <!--<annotation>
4177    RFC 1950 is an Informational RFC, thus it might be less stable than
4178    this specification. On the other hand, this downward reference was
4179    present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,
4180    therefore it is unlikely to cause problems in practice. See also
4181    <xref target="BCP97"/>.
4182  </annotation>-->
4183</reference>
4184
4185<reference anchor="RFC1951">
4186  <front>
4187    <title>DEFLATE Compressed Data Format Specification version 1.3</title>
4188    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
4189      <organization>Aladdin Enterprises</organization>
4190      <address><email>ghost@aladdin.com</email></address>
4191    </author>
4192    <date month="May" year="1996"/>
4193  </front>
4194  <seriesInfo name="RFC" value="1951"/>
4195  <!--<annotation>
4196    RFC 1951 is an Informational RFC, thus it might be less stable than
4197    this specification. On the other hand, this downward reference was
4198    present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,
4199    therefore it is unlikely to cause problems in practice. See also
4200    <xref target="BCP97"/>.
4201  </annotation>-->
4202</reference>
4203
4204<reference anchor="RFC1952">
4205  <front>
4206    <title>GZIP file format specification version 4.3</title>
4207    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
4208      <organization>Aladdin Enterprises</organization>
4209      <address><email>ghost@aladdin.com</email></address>
4210    </author>
4211    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">
4212      <address><email>gzip@prep.ai.mit.edu</email></address>
4213    </author>
4214    <author initials="M." surname="Adler" fullname="Mark Adler">
4215      <address><email>madler@alumni.caltech.edu</email></address>
4216    </author>
4217    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
4218      <address><email>ghost@aladdin.com</email></address>
4219    </author>
4220    <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson">
4221      <address><email>randeg@alumni.rpi.edu</email></address>
4222    </author>
4223    <date month="May" year="1996"/>
4224  </front>
4225  <seriesInfo name="RFC" value="1952"/>
4226  <!--<annotation>
4227    RFC 1952 is an Informational RFC, thus it might be less stable than
4228    this specification. On the other hand, this downward reference was
4229    present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,
4230    therefore it is unlikely to cause problems in practice. See also
4231    <xref target="BCP97"/>.
4232  </annotation>-->
4233</reference>
4234
4235</references>
4236
4237<references title="Informative References">
4238
4239<reference anchor="Nie1997" target="http://doi.acm.org/10.1145/263105.263157">
4240  <front>
4241    <title>Network Performance Effects of HTTP/1.1, CSS1, and PNG</title>
4242    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"/>
4243    <author initials="J." surname="Gettys" fullname="J. Gettys"/>
4244    <author initials="E." surname="Prud'hommeaux" fullname="E. Prud'hommeaux"/>
4245    <author initials="H." surname="Lie" fullname="H. Lie"/>
4246    <author initials="C." surname="Lilley" fullname="C. Lilley"/>
4247    <date year="1997" month="September"/>
4248  </front>
4249  <seriesInfo name="ACM" value="Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication SIGCOMM '97"/>
4250</reference>
4251
4252<reference anchor="Pad1995" target="http://portal.acm.org/citation.cfm?id=219094">
4253  <front>
4254    <title>Improving HTTP Latency</title>
4255    <author initials="V.N." surname="Padmanabhan" fullname="Venkata N. Padmanabhan"/>
4256    <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"/>
4257    <date year="1995" month="December"/>
4258  </front>
4259  <seriesInfo name="Computer Networks and ISDN Systems" value="v. 28, pp. 25-35"/>
4260</reference>
4261
4262<reference anchor="RFC1919">
4263  <front>
4264    <title>Classical versus Transparent IP Proxies</title>
4265    <author initials="M." surname="Chatel" fullname="Marc Chatel">
4266      <address><email>mchatel@pax.eunet.ch</email></address>
4267    </author>
4268    <date year="1996" month="March"/>
4269  </front>
4270  <seriesInfo name="RFC" value="1919"/>
4271</reference>
4272
4273<reference anchor="RFC1945">
4274  <front>
4275    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
4276    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
4277      <organization>MIT, Laboratory for Computer Science</organization>
4278      <address><email>timbl@w3.org</email></address>
4279    </author>
4280    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
4281      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
4282      <address><email>fielding@ics.uci.edu</email></address>
4283    </author>
4284    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
4285      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
4286      <address><email>frystyk@w3.org</email></address>
4287    </author>
4288    <date month="May" year="1996"/>
4289  </front>
4290  <seriesInfo name="RFC" value="1945"/>
4291</reference>
4292
4293<reference anchor="RFC2045">
4294  <front>
4295    <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
4296    <author initials="N." surname="Freed" fullname="Ned Freed">
4297      <organization>Innosoft International, Inc.</organization>
4298      <address><email>ned@innosoft.com</email></address>
4299    </author>
4300    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
4301      <organization>First Virtual Holdings</organization>
4302      <address><email>nsb@nsb.fv.com</email></address>
4303    </author>
4304    <date month="November" year="1996"/>
4305  </front>
4306  <seriesInfo name="RFC" value="2045"/>
4307</reference>
4308
4309<reference anchor="RFC2047">
4310  <front>
4311    <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
4312    <author initials="K." surname="Moore" fullname="Keith Moore">
4313      <organization>University of Tennessee</organization>
4314      <address><email>moore@cs.utk.edu</email></address>
4315    </author>
4316    <date month="November" year="1996"/>
4317  </front>
4318  <seriesInfo name="RFC" value="2047"/>
4319</reference>
4320
4321<reference anchor="RFC2068">
4322  <front>
4323    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
4324    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
4325      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
4326      <address><email>fielding@ics.uci.edu</email></address>
4327    </author>
4328    <author initials="J." surname="Gettys" fullname="Jim Gettys">
4329      <organization>MIT Laboratory for Computer Science</organization>
4330      <address><email>jg@w3.org</email></address>
4331    </author>
4332    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
4333      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
4334      <address><email>mogul@wrl.dec.com</email></address>
4335    </author>
4336    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
4337      <organization>MIT Laboratory for Computer Science</organization>
4338      <address><email>frystyk@w3.org</email></address>
4339    </author>
4340    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
4341      <organization>MIT Laboratory for Computer Science</organization>
4342      <address><email>timbl@w3.org</email></address>
4343    </author>
4344    <date month="January" year="1997"/>
4345  </front>
4346  <seriesInfo name="RFC" value="2068"/>
4347</reference>
4348
4349<reference anchor="RFC2145">
4350  <front>
4351    <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
4352    <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
4353      <organization>Western Research Laboratory</organization>
4354      <address><email>mogul@wrl.dec.com</email></address>
4355    </author>
4356    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
4357      <organization>Department of Information and Computer Science</organization>
4358      <address><email>fielding@ics.uci.edu</email></address>
4359    </author>
4360    <author initials="J." surname="Gettys" fullname="Jim Gettys">
4361      <organization>MIT Laboratory for Computer Science</organization>
4362      <address><email>jg@w3.org</email></address>
4363    </author>
4364    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
4365      <organization>W3 Consortium</organization>
4366      <address><email>frystyk@w3.org</email></address>
4367    </author>
4368    <date month="May" year="1997"/>
4369  </front>
4370  <seriesInfo name="RFC" value="2145"/>
4371</reference>
4372
4373<reference anchor="RFC2616">
4374  <front>
4375    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
4376    <author initials="R." surname="Fielding" fullname="R. Fielding">
4377      <organization>University of California, Irvine</organization>
4378      <address><email>fielding@ics.uci.edu</email></address>
4379    </author>
4380    <author initials="J." surname="Gettys" fullname="J. Gettys">
4381      <organization>W3C</organization>
4382      <address><email>jg@w3.org</email></address>
4383    </author>
4384    <author initials="J." surname="Mogul" fullname="J. Mogul">
4385      <organization>Compaq Computer Corporation</organization>
4386      <address><email>mogul@wrl.dec.com</email></address>
4387    </author>
4388    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
4389      <organization>MIT Laboratory for Computer Science</organization>
4390      <address><email>frystyk@w3.org</email></address>
4391    </author>
4392    <author initials="L." surname="Masinter" fullname="L. Masinter">
4393      <organization>Xerox Corporation</organization>
4394      <address><email>masinter@parc.xerox.com</email></address>
4395    </author>
4396    <author initials="P." surname="Leach" fullname="P. Leach">
4397      <organization>Microsoft Corporation</organization>
4398      <address><email>paulle@microsoft.com</email></address>
4399    </author>
4400    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
4401      <organization>W3C</organization>
4402      <address><email>timbl@w3.org</email></address>
4403    </author>
4404    <date month="June" year="1999"/>
4405  </front>
4406  <seriesInfo name="RFC" value="2616"/>
4407</reference>
4408
4409<reference anchor="RFC2817">
4410  <front>
4411    <title>Upgrading to TLS Within HTTP/1.1</title>
4412    <author initials="R." surname="Khare" fullname="R. Khare">
4413      <organization>4K Associates / UC Irvine</organization>
4414      <address><email>rohit@4K-associates.com</email></address>
4415    </author>
4416    <author initials="S." surname="Lawrence" fullname="S. Lawrence">
4417      <organization>Agranat Systems, Inc.</organization>
4418      <address><email>lawrence@agranat.com</email></address>
4419    </author>
4420    <date year="2000" month="May"/>
4421  </front>
4422  <seriesInfo name="RFC" value="2817"/>
4423</reference>
4424
4425<reference anchor="RFC2818">
4426  <front>
4427    <title>HTTP Over TLS</title>
4428    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
4429      <organization>RTFM, Inc.</organization>
4430      <address><email>ekr@rtfm.com</email></address>
4431    </author>
4432    <date year="2000" month="May"/>
4433  </front>
4434  <seriesInfo name="RFC" value="2818"/>
4435</reference>
4436
4437<reference anchor="RFC2965">
4438  <front>
4439    <title>HTTP State Management Mechanism</title>
4440    <author initials="D. M." surname="Kristol" fullname="David M. Kristol">
4441      <organization>Bell Laboratories, Lucent Technologies</organization>
4442      <address><email>dmk@bell-labs.com</email></address>
4443    </author>
4444    <author initials="L." surname="Montulli" fullname="Lou Montulli">
4445      <organization>Epinions.com, Inc.</organization>
4446      <address><email>lou@montulli.org</email></address>
4447    </author>
4448    <date year="2000" month="October"/>
4449  </front>
4450  <seriesInfo name="RFC" value="2965"/>
4451</reference>
4452
4453<reference anchor="RFC3040">
4454  <front>
4455    <title>Internet Web Replication and Caching Taxonomy</title>
4456    <author initials="I." surname="Cooper" fullname="I. Cooper">
4457      <organization>Equinix, Inc.</organization>
4458    </author>
4459    <author initials="I." surname="Melve" fullname="I. Melve">
4460      <organization>UNINETT</organization>
4461    </author>
4462    <author initials="G." surname="Tomlinson" fullname="G. Tomlinson">
4463      <organization>CacheFlow Inc.</organization>
4464    </author>
4465    <date year="2001" month="January"/>
4466  </front>
4467  <seriesInfo name="RFC" value="3040"/>
4468</reference>
4469
4470<reference anchor="RFC3864">
4471  <front>
4472    <title>Registration Procedures for Message Header Fields</title>
4473    <author initials="G." surname="Klyne" fullname="G. Klyne">
4474      <organization>Nine by Nine</organization>
4475      <address><email>GK-IETF@ninebynine.org</email></address>
4476    </author>
4477    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
4478      <organization>BEA Systems</organization>
4479      <address><email>mnot@pobox.com</email></address>
4480    </author>
4481    <author initials="J." surname="Mogul" fullname="J. Mogul">
4482      <organization>HP Labs</organization>
4483      <address><email>JeffMogul@acm.org</email></address>
4484    </author>
4485    <date year="2004" month="September"/>
4486  </front>
4487  <seriesInfo name="BCP" value="90"/>
4488  <seriesInfo name="RFC" value="3864"/>
4489</reference>
4490
4491<reference anchor="RFC4033">
4492  <front>
4493    <title>DNS Security Introduction and Requirements</title>
4494    <author initials="R." surname="Arends" fullname="R. Arends"/>
4495    <author initials="R." surname="Austein" fullname="R. Austein"/>
4496    <author initials="M." surname="Larson" fullname="M. Larson"/>
4497    <author initials="D." surname="Massey" fullname="D. Massey"/>
4498    <author initials="S." surname="Rose" fullname="S. Rose"/>
4499    <date year="2005" month="March"/>
4500  </front>
4501  <seriesInfo name="RFC" value="4033"/>
4502</reference>
4503
4504<reference anchor="RFC4288">
4505  <front>
4506    <title>Media Type Specifications and Registration Procedures</title>
4507    <author initials="N." surname="Freed" fullname="N. Freed">
4508      <organization>Sun Microsystems</organization>
4509      <address>
4510        <email>ned.freed@mrochek.com</email>
4511      </address>
4512    </author>
4513    <author initials="J." surname="Klensin" fullname="J. Klensin">
4514      <address>
4515        <email>klensin+ietf@jck.com</email>
4516      </address>
4517    </author>
4518    <date year="2005" month="December"/>
4519  </front>
4520  <seriesInfo name="BCP" value="13"/>
4521  <seriesInfo name="RFC" value="4288"/>
4522</reference>
4523
4524<reference anchor="RFC4395">
4525  <front>
4526    <title>Guidelines and Registration Procedures for New URI Schemes</title>
4527    <author initials="T." surname="Hansen" fullname="T. Hansen">
4528      <organization>AT&amp;T Laboratories</organization>
4529      <address>
4530        <email>tony+urireg@maillennium.att.com</email>
4531      </address>
4532    </author>
4533    <author initials="T." surname="Hardie" fullname="T. Hardie">
4534      <organization>Qualcomm, Inc.</organization>
4535      <address>
4536        <email>hardie@qualcomm.com</email>
4537      </address>
4538    </author>
4539    <author initials="L." surname="Masinter" fullname="L. Masinter">
4540      <organization>Adobe Systems</organization>
4541      <address>
4542        <email>LMM@acm.org</email>
4543      </address>
4544    </author>
4545    <date year="2006" month="February"/>
4546  </front>
4547  <seriesInfo name="BCP" value="115"/>
4548  <seriesInfo name="RFC" value="4395"/>
4549</reference>
4550
4551<reference anchor="RFC4559">
4552  <front>
4553    <title>SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</title>
4554    <author initials="K." surname="Jaganathan" fullname="K. Jaganathan"/>
4555    <author initials="L." surname="Zhu" fullname="L. Zhu"/>
4556    <author initials="J." surname="Brezak" fullname="J. Brezak"/>
4557    <date year="2006" month="June"/>
4558  </front>
4559  <seriesInfo name="RFC" value="4559"/>
4560</reference>
4561
4562<reference anchor="RFC5226">
4563  <front>
4564    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
4565    <author initials="T." surname="Narten" fullname="T. Narten">
4566      <organization>IBM</organization>
4567      <address><email>narten@us.ibm.com</email></address>
4568    </author>
4569    <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
4570      <organization>Google</organization>
4571      <address><email>Harald@Alvestrand.no</email></address>
4572    </author>
4573    <date year="2008" month="May"/>
4574  </front>
4575  <seriesInfo name="BCP" value="26"/>
4576  <seriesInfo name="RFC" value="5226"/>
4577</reference>
4578
4579<reference anchor="RFC5322">
4580  <front>
4581    <title>Internet Message Format</title>
4582    <author initials="P." surname="Resnick" fullname="P. Resnick">
4583      <organization>Qualcomm Incorporated</organization>
4584    </author>
4585    <date year="2008" month="October"/>
4586  </front>
4587  <seriesInfo name="RFC" value="5322"/>
4588</reference>
4589
4590<reference anchor="RFC6265">
4591  <front>
4592    <title>HTTP State Management Mechanism</title>
4593    <author initials="A." surname="Barth" fullname="Adam Barth">
4594      <organization abbrev="U.C. Berkeley">
4595        University of California, Berkeley
4596      </organization>
4597      <address><email>abarth@eecs.berkeley.edu</email></address>
4598    </author>
4599    <date year="2011" month="April"/>
4600  </front>
4601  <seriesInfo name="RFC" value="6265"/>
4602</reference>
4603
4604<!--<reference anchor='BCP97'>
4605  <front>
4606    <title>Handling Normative References to Standards-Track Documents</title>
4607    <author initials='J.' surname='Klensin' fullname='J. Klensin'>
4608      <address>
4609        <email>klensin+ietf@jck.com</email>
4610      </address>
4611    </author>
4612    <author initials='S.' surname='Hartman' fullname='S. Hartman'>
4613      <organization>MIT</organization>
4614      <address>
4615        <email>hartmans-ietf@mit.edu</email>
4616      </address>
4617    </author>
4618    <date year='2007' month='June' />
4619  </front>
4620  <seriesInfo name='BCP' value='97' />
4621  <seriesInfo name='RFC' value='4897' />
4622</reference>-->
4623
4624<reference anchor="Kri2001" target="http://arxiv.org/abs/cs.SE/0105018">
4625  <front>
4626    <title>HTTP Cookies: Standards, Privacy, and Politics</title>
4627    <author initials="D." surname="Kristol" fullname="David M. Kristol"/>
4628    <date year="2001" month="November"/>
4629  </front>
4630  <seriesInfo name="ACM Transactions on Internet Technology" value="Vol. 1, #2"/>
4631</reference>
4632
4633<reference anchor="Spe" target="http://sunsite.unc.edu/mdma-release/http-prob.html">
4634  <front>
4635    <title>Analysis of HTTP Performance Problems</title>
4636    <author initials="S." surname="Spero" fullname="Simon E. Spero"/>
4637    <date/>
4638  </front>
4639</reference>
4640
4641<reference anchor="Tou1998" target="http://www.isi.edu/touch/pubs/http-perf96/">
4642  <front>
4643  <title>Analysis of HTTP Performance</title>
4644  <author initials="J." surname="Touch" fullname="Joe Touch">
4645    <organization>USC/Information Sciences Institute</organization>
4646    <address><email>touch@isi.edu</email></address>
4647  </author>
4648  <author initials="J." surname="Heidemann" fullname="John Heidemann">
4649    <organization>USC/Information Sciences Institute</organization>
4650    <address><email>johnh@isi.edu</email></address>
4651  </author>
4652  <author initials="K." surname="Obraczka" fullname="Katia Obraczka">
4653    <organization>USC/Information Sciences Institute</organization>
4654    <address><email>katia@isi.edu</email></address>
4655  </author>
4656  <date year="1998" month="Aug"/>
4657  </front>
4658  <seriesInfo name="ISI Research Report" value="ISI/RR-98-463"/>
4659  <annotation>(original report dated Aug. 1996)</annotation>
4660</reference>
4661
4662</references>
4663
4664
4665<section title="HTTP Version History" anchor="compatibility">
4666<t>
4667   HTTP has been in use by the World-Wide Web global information initiative
4668   since 1990. The first version of HTTP, later referred to as HTTP/0.9,
4669   was a simple protocol for hypertext data transfer across the Internet
4670   with only a single request method (GET) and no metadata.
4671   HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request
4672   methods and MIME-like messaging that could include metadata about the data
4673   transferred and modifiers on the request/response semantics. However,
4674   HTTP/1.0 did not sufficiently take into consideration the effects of
4675   hierarchical proxies, caching, the need for persistent connections, or
4676   name-based virtual hosts. The proliferation of incompletely-implemented
4677   applications calling themselves "HTTP/1.0" further necessitated a
4678   protocol version change in order for two communicating applications
4679   to determine each other's true capabilities.
4680</t>
4681<t>
4682   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
4683   requirements that enable reliable implementations, adding only
4684   those new features that will either be safely ignored by an HTTP/1.0
4685   recipient or only sent when communicating with a party advertising
4686   conformance with HTTP/1.1.
4687</t>
4688<t>
4689   It is beyond the scope of a protocol specification to mandate
4690   conformance with previous versions. HTTP/1.1 was deliberately
4691   designed, however, to make supporting previous versions easy.
4692   We would expect a general-purpose HTTP/1.1 server to understand
4693   any valid request in the format of HTTP/1.0 and respond appropriately
4694   with an HTTP/1.1 message that only uses features understood (or
4695   safely ignored) by HTTP/1.0 clients.  Likewise, we would expect
4696   an HTTP/1.1 client to understand any valid HTTP/1.0 response.
4697</t>
4698<t>
4699   Since HTTP/0.9 did not support header fields in a request,
4700   there is no mechanism for it to support name-based virtual
4701   hosts (selection of resource by inspection of the Host header
4702   field).  Any server that implements name-based virtual hosts
4703   ought to disable support for HTTP/0.9.  Most requests that
4704   appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x
4705   requests wherein a buggy client failed to properly encode
4706   linear whitespace found in a URI reference and placed in
4707   the request-target.
4708</t>
4709
4710<section title="Changes from HTTP/1.0" anchor="changes.from.1.0">
4711<t>
4712   This section summarizes major differences between versions HTTP/1.0
4713   and HTTP/1.1.
4714</t>
4715
4716<section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
4717<t>
4718   The requirements that clients and servers support the Host header
4719   field (<xref target="header.host"/>), report an error if it is
4720   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
4721   are among the most important changes defined by HTTP/1.1.
4722</t>
4723<t>
4724   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
4725   addresses and servers; there was no other established mechanism for
4726   distinguishing the intended server of a request than the IP address
4727   to which that request was directed. The Host header field was
4728   introduced during the development of HTTP/1.1 and, though it was
4729   quickly implemented by most HTTP/1.0 browsers, additional requirements
4730   were placed on all HTTP/1.1 requests in order to ensure complete
4731   adoption.  At the time of this writing, most HTTP-based services
4732   are dependent upon the Host header field for targeting requests.
4733</t>
4734</section>
4735
4736<section title="Keep-Alive Connections" anchor="compatibility.with.http.1.0.persistent.connections">
4737<t>
4738   In HTTP/1.0, each connection is established by the client prior to the
4739   request and closed by the server after sending the response. However, some
4740   implementations implement the explicitly negotiated ("Keep-Alive") version
4741   of persistent connections described in Section 19.7.1 of <xref target="RFC2068"/>.
4742</t>
4743<t>
4744   Some clients and servers might wish to be compatible with these previous
4745   approaches to persistent connections, by explicitly negotiating for them
4746   with a "Connection: keep-alive" request header field. However, some
4747   experimental implementations of HTTP/1.0 persistent connections are faulty;
4748   for example, if a HTTP/1.0 proxy server doesn't understand Connection, it
4749   will erroneously forward that header to the next inbound server, which
4750   would result in a hung connection.
4751</t>
4752<t>
4753   One attempted solution was the introduction of a Proxy-Connection header,
4754   targeted specifically at proxies. In practice, this was also unworkable,
4755   because proxies are often deployed in multiple layers, bringing about the
4756   same problem discussed above.
4757</t>
4758<t>
4759   As a result, clients are encouraged not to send the Proxy-Connection header
4760   in any requests.
4761</t>
4762<t>
4763   Clients are also encouraged to consider the use of Connection: keep-alive
4764   in requests carefully; while they can enable persistent connections with
4765   HTTP/1.0 servers, clients using them need will need to monitor the
4766   connection for "hung" requests (which indicate that the client ought stop
4767   sending the header), and this mechanism ought not be used by clients at all
4768   when a proxy is being used.
4769</t>
4770</section>
4771</section>
4772
4773<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
4774<t>
4775  Clarify that the string "HTTP" in the HTTP-version ABFN production is case
4776  sensitive. Restrict the version numbers to be single digits due to the fact
4777  that implementations are known to handle multi-digit version numbers
4778  incorrectly.
4779  (<xref target="http.version"/>)
4780</t>
4781<t>
4782  Update use of abs_path production from RFC 1808 to the path-absolute + query
4783  components of RFC 3986. State that the asterisk form is allowed for the OPTIONS
4784  request method only.
4785  (<xref target="request-target"/>)
4786</t>
4787<t>
4788  Require that invalid whitespace around field-names be rejected.
4789  (<xref target="header.fields"/>)
4790</t>
4791<t>
4792  Rules about implicit linear whitespace between certain grammar productions
4793  have been removed; now whitespace is only allowed where specifically
4794  defined in the ABNF.
4795  (<xref target="whitespace"/>)
4796</t>
4797<t> 
4798  The NUL octet is no longer allowed in comment and quoted-string
4799  text. The quoted-pair rule no longer allows escaping control characters other than HTAB.
4800  Non-ASCII content in header fields and reason phrase has been obsoleted and
4801  made opaque (the TEXT rule was removed).
4802  (<xref target="field.components"/>)
4803</t>
4804<t>
4805  Empty list elements in list productions have been deprecated.
4806  (<xref target="abnf.extension"/>)
4807</t>
4808<t>
4809  Require recipients to handle bogus Content-Length header fields as errors.
4810  (<xref target="message.body"/>)
4811</t>
4812<t>
4813  Remove reference to non-existent identity transfer-coding value tokens.
4814  (Sections <xref format="counter" target="message.body"/> and
4815  <xref format="counter" target="transfer.codings"/>)
4816</t>
4817<t>
4818  Clarification that the chunk length does not include the count of the octets
4819  in the chunk header and trailer. Furthermore disallowed line folding
4820  in chunk extensions, and deprecate their use.
4821  (<xref target="chunked.encoding"/>)
4822</t>
4823<t>
4824  Registration of Transfer Codings now requires IETF Review
4825  (<xref target="transfer.coding.registry"/>)
4826</t>
4827<t>
4828  Remove hard limit of two connections per server.
4829  Remove requirement to retry a sequence of requests as long it was idempotent.
4830  Remove requirements about when servers are allowed to close connections
4831  prematurely.
4832  (<xref target="persistent.practical"/>)
4833</t>
4834<t>
4835  Remove requirement to retry requests under certain cirumstances when the
4836  server prematurely closes the connection.
4837  (<xref target="message.transmission.requirements"/>)
4838</t>
4839<t>
4840  Change ABNF productions for header fields to only define the field value.
4841</t>
4842<t>
4843  Clarify exactly when close connection options must be sent.
4844  (<xref target="header.connection"/>)
4845</t>
4846<t>
4847  Define the semantics of the "Upgrade" header field in responses other than
4848  101 (this was incorporated from <xref target="RFC2817"/>).
4849  (<xref target="header.upgrade"/>)
4850</t>
4851</section>
4852
4853<section title="Changes from RFC 2817" anchor="changes.from.rfc.2817">
4854<t>
4855  Registration of Upgrade tokens now requires IETF Review
4856  (<xref target="upgrade.token.registry"/>)
4857</t>
4858</section>
4859</section>
4860
4861
4862<section title="Collected ABNF" anchor="collected.abnf">
4863<figure>
4864<artwork type="abnf" name="p1-messaging.parsed-abnf"><![CDATA[
4865BWS = OWS
4866
4867Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
4868 connection-token ] )
4869Content-Length = 1*DIGIT
4870
4871HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
4872 ]
4873HTTP-name = %x48.54.54.50 ; HTTP
4874HTTP-version = HTTP-name "/" DIGIT "." DIGIT
4875Host = uri-host [ ":" port ]
4876
4877OWS = *( SP / HTAB )
4878
4879RWS = 1*( SP / HTAB )
4880
4881TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
4882Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
4883Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
4884 transfer-coding ] )
4885
4886URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
4887Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
4888
4889Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
4890 *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ]
4891 )
4892
4893absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
4894absolute-form = absolute-URI
4895asterisk-form = "*"
4896attribute = token
4897authority = <authority, defined in [RFC3986], Section 3.2>
4898authority-form = authority
4899
4900chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
4901chunk-data = 1*OCTET
4902chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
4903chunk-ext-name = token
4904chunk-ext-val = token / quoted-str-nf
4905chunk-size = 1*HEXDIG
4906chunked-body = *chunk last-chunk trailer-part CRLF
4907comment = "(" *( ctext / quoted-cpair / comment ) ")"
4908connection-token = token
4909ctext = OWS / %x21-27 ; '!'-'''
4910 / %x2A-5B ; '*'-'['
4911 / %x5D-7E ; ']'-'~'
4912 / obs-text
4913
4914field-content = *( HTAB / SP / VCHAR / obs-text )
4915field-name = token
4916field-value = *( field-content / obs-fold )
4917
4918header-field = field-name ":" OWS field-value BWS
4919http-URI = "http://" authority path-abempty [ "?" query ]
4920https-URI = "https://" authority path-abempty [ "?" query ]
4921
4922last-chunk = 1*"0" [ chunk-ext ] CRLF
4923
4924message-body = *OCTET
4925method = token
4926
4927obs-fold = CRLF ( SP / HTAB )
4928obs-text = %x80-FF
4929origin-form = path-absolute [ "?" query ]
4930
4931partial-URI = relative-part [ "?" query ]
4932path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
4933path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
4934port = <port, defined in [RFC3986], Section 3.2.3>
4935protocol = protocol-name [ "/" protocol-version ]
4936protocol-name = token
4937protocol-version = token
4938pseudonym = token
4939
4940qdtext = OWS / "!" / %x23-5B ; '#'-'['
4941 / %x5D-7E ; ']'-'~'
4942 / obs-text
4943qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'['
4944 / %x5D-7E ; ']'-'~'
4945 / obs-text
4946query = <query, defined in [RFC3986], Section 3.4>
4947quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text )
4948quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
4949quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
4950quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
4951qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
4952
4953reason-phrase = *( HTAB / SP / VCHAR / obs-text )
4954received-by = ( uri-host [ ":" port ] ) / pseudonym
4955received-protocol = [ protocol-name "/" ] protocol-version
4956relative-part = <relative-part, defined in [RFC3986], Section 4.2>
4957request-line = method SP request-target SP HTTP-version CRLF
4958request-target = origin-form / absolute-form / authority-form /
4959 asterisk-form
4960
4961special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
4962 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
4963start-line = request-line / status-line
4964status-code = 3DIGIT
4965status-line = HTTP-version SP status-code SP reason-phrase CRLF
4966
4967t-codings = "trailers" / ( transfer-extension [ te-params ] )
4968tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
4969 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
4970te-ext = OWS ";" OWS token [ "=" word ]
4971te-params = OWS ";" OWS "q=" qvalue *te-ext
4972token = 1*tchar
4973trailer-part = *( header-field CRLF )
4974transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
4975 transfer-extension
4976transfer-extension = token *( OWS ";" OWS transfer-parameter )
4977transfer-parameter = attribute BWS "=" BWS value
4978
4979uri-host = <host, defined in [RFC3986], Section 3.2.2>
4980
4981value = word
4982
4983word = token / quoted-string
4984]]></artwork>
4985</figure>
4986<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[
4987; Connection defined but not used
4988; Content-Length defined but not used
4989; HTTP-message defined but not used
4990; Host defined but not used
4991; TE defined but not used
4992; Trailer defined but not used
4993; Transfer-Encoding defined but not used
4994; URI-reference defined but not used
4995; Upgrade defined but not used
4996; Via defined but not used
4997; chunked-body defined but not used
4998; http-URI defined but not used
4999; https-URI defined but not used
5000; partial-URI defined but not used
5001; special defined but not used
5002]]></artwork></figure></section>
5003
5004
5005<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
5006
5007<section title="Since RFC 2616">
5008<t>
5009  Extracted relevant partitions from <xref target="RFC2616"/>.
5010</t>
5011</section>
5012
5013<section title="Since draft-ietf-httpbis-p1-messaging-00">
5014<t>
5015  Closed issues:
5016  <list style="symbols">
5017    <t>
5018      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/1"/>:
5019      "HTTP Version should be case sensitive"
5020      (<eref target="http://purl.org/NET/http-errata#verscase"/>)
5021    </t>
5022    <t>
5023      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/2"/>:
5024      "'unsafe' characters"
5025      (<eref target="http://purl.org/NET/http-errata#unsafe-uri"/>)
5026    </t>
5027    <t>
5028      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/3"/>:
5029      "Chunk Size Definition"
5030      (<eref target="http://purl.org/NET/http-errata#chunk-size"/>)
5031    </t>
5032    <t>
5033      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/4"/>:
5034      "Message Length"
5035      (<eref target="http://purl.org/NET/http-errata#msg-len-chars"/>)
5036    </t>
5037    <t>
5038      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/8"/>:
5039      "Media Type Registrations"
5040      (<eref target="http://purl.org/NET/http-errata#media-reg"/>)
5041    </t>
5042    <t>
5043      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/11"/>:
5044      "URI includes query"
5045      (<eref target="http://purl.org/NET/http-errata#uriquery"/>)
5046    </t>
5047    <t>
5048      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/15"/>:
5049      "No close on 1xx responses"
5050      (<eref target="http://purl.org/NET/http-errata#noclose1xx"/>)
5051    </t>
5052    <t>
5053      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/16"/>:
5054      "Remove 'identity' token references"
5055      (<eref target="http://purl.org/NET/http-errata#identity"/>)
5056    </t>
5057    <t>
5058      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/26"/>:
5059      "Import query BNF"
5060    </t>
5061    <t>
5062      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/31"/>:
5063      "qdtext BNF"
5064    </t>
5065    <t>
5066      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
5067      "Normative and Informative references"
5068    </t>
5069    <t>
5070      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/42"/>:
5071      "RFC2606 Compliance"
5072    </t>
5073    <t>
5074      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/45"/>:
5075      "RFC977 reference"
5076    </t>
5077    <t>
5078      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/46"/>:
5079      "RFC1700 references"
5080    </t>
5081    <t>
5082      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/47"/>:
5083      "inconsistency in date format explanation"
5084    </t>
5085    <t>
5086      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/48"/>:
5087      "Date reference typo"
5088    </t>
5089    <t>
5090      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>:
5091      "Informative references"
5092    </t>
5093    <t>
5094      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/66"/>:
5095      "ISO-8859-1 Reference"
5096    </t>
5097    <t>
5098      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86"/>:
5099      "Normative up-to-date references"
5100    </t>
5101  </list>
5102</t>
5103<t>
5104  Other changes:
5105  <list style="symbols">
5106    <t>
5107      Update media type registrations to use RFC4288 template.
5108    </t>
5109    <t>
5110      Use names of RFC4234 core rules DQUOTE and HTAB,
5111      fix broken ABNF for chunk-data
5112      (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>)
5113    </t>
5114  </list>
5115</t>
5116</section>
5117
5118<section title="Since draft-ietf-httpbis-p1-messaging-01">
5119<t>
5120  Closed issues:
5121  <list style="symbols">
5122    <t>
5123      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/19"/>:
5124      "Bodies on GET (and other) requests"
5125    </t>
5126    <t>
5127      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/55"/>:
5128      "Updating to RFC4288"
5129    </t>
5130    <t>
5131      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/57"/>:
5132      "Status Code and Reason Phrase"
5133    </t>
5134    <t>
5135      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/82"/>:
5136      "rel_path not used"
5137    </t>
5138  </list>
5139</t>
5140<t>
5141  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
5142  <list style="symbols">
5143    <t>
5144      Get rid of duplicate BNF rule names ("host" -&gt; "uri-host", "trailer" -&gt;
5145      "trailer-part").
5146    </t>
5147    <t>
5148      Avoid underscore character in rule names ("http_URL" -&gt;
5149      "http-URL", "abs_path" -&gt; "path-absolute").
5150    </t>
5151    <t>
5152      Add rules for terms imported from URI spec ("absoluteURI", "authority",
5153      "path-absolute", "port", "query", "relativeURI", "host) — these will
5154      have to be updated when switching over to RFC3986.
5155    </t>
5156    <t>
5157      Synchronize core rules with RFC5234.
5158    </t>
5159    <t>
5160      Get rid of prose rules that span multiple lines.
5161    </t>
5162    <t>
5163      Get rid of unused rules LOALPHA and UPALPHA.
5164    </t>
5165    <t>
5166      Move "Product Tokens" section (back) into Part 1, as "token" is used
5167      in the definition of the Upgrade header field.
5168    </t>
5169    <t>
5170      Add explicit references to BNF syntax and rules imported from other parts of the specification.
5171    </t>
5172    <t>
5173      Rewrite prose rule "token" in terms of "tchar", rewrite prose rule "TEXT".
5174    </t>
5175  </list>
5176</t>
5177</section>
5178
5179<section title="Since draft-ietf-httpbis-p1-messaging-02" anchor="changes.since.02">
5180<t>
5181  Closed issues:
5182  <list style="symbols">
5183    <t>
5184      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/51"/>:
5185      "HTTP-date vs. rfc1123-date"
5186    </t>
5187    <t>
5188      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/64"/>:
5189      "WS in quoted-pair"
5190    </t>
5191  </list>
5192</t>
5193<t>
5194  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
5195  <list style="symbols">
5196    <t>
5197      Reference RFC 3984, and update header field registrations for headers defined
5198      in this document.
5199    </t>
5200  </list>
5201</t>
5202<t>
5203  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
5204  <list style="symbols">
5205    <t>
5206      Replace string literals when the string really is case-sensitive (HTTP-version).
5207    </t>
5208  </list>
5209</t>
5210</section>
5211
5212<section title="Since draft-ietf-httpbis-p1-messaging-03" anchor="changes.since.03">
5213<t>
5214  Closed issues:
5215  <list style="symbols">
5216    <t>
5217      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/28"/>:
5218      "Connection closing"
5219    </t>
5220    <t>
5221      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/97"/>:
5222      "Move registrations and registry information to IANA Considerations"
5223    </t>
5224    <t>
5225      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/120"/>:
5226      "need new URL for PAD1995 reference"
5227    </t>
5228    <t>
5229      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/127"/>:
5230      "IANA Considerations: update HTTP URI scheme registration"
5231    </t>
5232    <t>
5233      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/128"/>:
5234      "Cite HTTPS URI scheme definition"
5235    </t>
5236    <t>
5237      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/129"/>:
5238      "List-type headers vs Set-Cookie"
5239    </t>
5240  </list>
5241</t>
5242<t>
5243  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
5244  <list style="symbols">
5245    <t>
5246      Replace string literals when the string really is case-sensitive (HTTP-Date).
5247    </t>
5248    <t>
5249      Replace HEX by HEXDIG for future consistence with RFC 5234's core rules.
5250    </t>
5251  </list>
5252</t>
5253</section>
5254
5255<section title="Since draft-ietf-httpbis-p1-messaging-04" anchor="changes.since.04">
5256<t>
5257  Closed issues:
5258  <list style="symbols">
5259    <t>
5260      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/34"/>:
5261      "Out-of-date reference for URIs"
5262    </t>
5263    <t>
5264      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>:
5265      "RFC 2822 is updated by RFC 5322"
5266    </t>
5267  </list>
5268</t>
5269<t>
5270  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
5271  <list style="symbols">
5272    <t>
5273      Use "/" instead of "|" for alternatives.
5274    </t>
5275    <t>
5276      Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
5277    </t>
5278    <t>
5279      Only reference RFC 5234's core rules.
5280    </t>
5281    <t>
5282      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
5283      whitespace ("OWS") and required whitespace ("RWS").
5284    </t>
5285    <t>
5286      Rewrite ABNFs to spell out whitespace rules, factor out
5287      header field value format definitions.
5288    </t>
5289  </list>
5290</t>
5291</section>
5292
5293<section title="Since draft-ietf-httpbis-p1-messaging-05" anchor="changes.since.05">
5294<t>
5295  Closed issues:
5296  <list style="symbols">
5297    <t>
5298      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/30"/>:
5299      "Header LWS"
5300    </t>
5301    <t>
5302      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/52"/>:
5303      "Sort 1.3 Terminology"
5304    </t>
5305    <t>
5306      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/63"/>:
5307      "RFC2047 encoded words"
5308    </t>
5309    <t>
5310      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/74"/>:
5311      "Character Encodings in TEXT"
5312    </t>
5313    <t>
5314      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/77"/>:
5315      "Line Folding"
5316    </t>
5317    <t>
5318      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/83"/>:
5319      "OPTIONS * and proxies"
5320    </t>
5321    <t>
5322      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/94"/>:
5323      "reason-phrase BNF"
5324    </t>
5325    <t>
5326      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/111"/>:
5327      "Use of TEXT"
5328    </t>
5329    <t>
5330      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/118"/>:
5331      "Join "Differences Between HTTP Entities and RFC 2045 Entities"?"
5332    </t>
5333    <t>
5334      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/134"/>:
5335      "RFC822 reference left in discussion of date formats"
5336    </t>
5337  </list>
5338</t>
5339<t>
5340  Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
5341  <list style="symbols">
5342    <t>
5343      Rewrite definition of list rules, deprecate empty list elements.
5344    </t>
5345    <t>
5346      Add appendix containing collected and expanded ABNF.
5347    </t>
5348  </list>
5349</t>
5350<t>
5351  Other changes:
5352  <list style="symbols">
5353    <t>
5354      Rewrite introduction; add mostly new Architecture Section.
5355    </t>
5356    <t>
5357      Move definition of quality values from Part 3 into Part 1;
5358      make TE request header field grammar independent of accept-params (defined in Part 3).
5359    </t>
5360  </list>
5361</t>
5362</section>
5363
5364<section title="Since draft-ietf-httpbis-p1-messaging-06" anchor="changes.since.06">
5365<t>
5366  Closed issues:
5367  <list style="symbols">
5368    <t>
5369      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/161"/>:
5370      "base for numeric protocol elements"
5371    </t>
5372    <t>
5373      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/162"/>:
5374      "comment ABNF"
5375    </t>
5376  </list>
5377</t>
5378<t>
5379  Partly resolved issues:
5380  <list style="symbols">
5381    <t>
5382      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>:
5383      "205 Bodies" (took out language that implied that there might be
5384      methods for which a request body MUST NOT be included)
5385    </t>
5386    <t>
5387      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/163"/>:
5388      "editorial improvements around HTTP-date"
5389    </t>
5390  </list>
5391</t>
5392</section>
5393
5394<section title="Since draft-ietf-httpbis-p1-messaging-07" anchor="changes.since.07">
5395<t>
5396  Closed issues:
5397  <list style="symbols">
5398    <t>
5399      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/93"/>:
5400      "Repeating single-value headers"
5401    </t>
5402    <t>
5403      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/131"/>:
5404      "increase connection limit"
5405    </t>
5406    <t>
5407      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/157"/>:
5408      "IP addresses in URLs"
5409    </t>
5410    <t>
5411      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/172"/>:
5412      "take over HTTP Upgrade Token Registry"
5413    </t>
5414    <t>
5415      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/173"/>:
5416      "CR and LF in chunk extension values"
5417    </t>
5418    <t>
5419      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/184"/>:
5420      "HTTP/0.9 support"
5421    </t>
5422    <t>
5423      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/188"/>:
5424      "pick IANA policy (RFC5226) for Transfer Coding / Content Coding"
5425    </t>
5426    <t>
5427      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/189"/>:
5428      "move definitions of gzip/deflate/compress to part 1"
5429    </t>
5430    <t>
5431      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/194"/>:
5432      "disallow control characters in quoted-pair"
5433    </t>
5434  </list>
5435</t>
5436<t>
5437  Partly resolved issues:
5438  <list style="symbols">
5439    <t>
5440      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/148"/>:
5441      "update IANA requirements wrt Transfer-Coding values" (add the
5442      IANA Considerations subsection)
5443    </t>
5444  </list>
5445</t>
5446</section>
5447
5448<section title="Since draft-ietf-httpbis-p1-messaging-08" anchor="changes.since.08">
5449<t>
5450  Closed issues:
5451  <list style="symbols">
5452    <t>
5453      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/201"/>:
5454      "header parsing, treatment of leading and trailing OWS"
5455    </t>
5456  </list>
5457</t>
5458<t>
5459  Partly resolved issues:
5460  <list style="symbols">
5461    <t>
5462      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>:
5463      "Placement of 13.5.1 and 13.5.2"
5464    </t>
5465    <t>
5466      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
5467      "use of term "word" when talking about header structure"
5468    </t>
5469  </list>
5470</t>
5471</section>
5472
5473<section title="Since draft-ietf-httpbis-p1-messaging-09" anchor="changes.since.09">
5474<t>
5475  Closed issues:
5476  <list style="symbols">
5477    <t>
5478      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/73"/>:
5479      "Clarification of the term 'deflate'"
5480    </t>
5481    <t>
5482      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/83"/>:
5483      "OPTIONS * and proxies"
5484    </t>
5485    <t>
5486      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/122"/>:
5487      "MIME-Version not listed in P1, general header fields"
5488    </t>
5489    <t>
5490      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/143"/>:
5491      "IANA registry for content/transfer encodings"
5492    </t>
5493    <t>
5494      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/165"/>:
5495      "Case-sensitivity of HTTP-date"
5496    </t>
5497    <t>
5498      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
5499      "use of term "word" when talking about header structure"
5500    </t>
5501  </list>
5502</t>
5503<t>
5504  Partly resolved issues:
5505  <list style="symbols">
5506    <t>
5507      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
5508      "Term for the requested resource's URI"
5509    </t>
5510  </list>
5511</t>
5512</section>
5513
5514<section title="Since draft-ietf-httpbis-p1-messaging-10" anchor="changes.since.10">
5515<t>
5516  Closed issues:
5517  <list style="symbols">
5518    <t>
5519      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/28"/>:
5520      "Connection Closing"
5521    </t>
5522    <t>
5523      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/90"/>:
5524      "Delimiting messages with multipart/byteranges"
5525    </t>
5526    <t>
5527      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>:
5528      "Handling multiple Content-Length headers"
5529    </t>
5530    <t>
5531      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
5532      "Clarify entity / representation / variant terminology"
5533    </t>
5534    <t>
5535      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
5536      "consider removing the 'changes from 2068' sections"
5537    </t>
5538  </list>
5539</t>
5540<t>
5541  Partly resolved issues:
5542  <list style="symbols">
5543    <t>
5544      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/159"/>:
5545      "HTTP(s) URI scheme definitions"
5546    </t>
5547  </list>
5548</t>
5549</section>
5550
5551<section title="Since draft-ietf-httpbis-p1-messaging-11" anchor="changes.since.11">
5552<t>
5553  Closed issues:
5554  <list style="symbols">
5555    <t>
5556      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/193"/>:
5557      "Trailer requirements"
5558    </t>
5559    <t>
5560      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/204"/>:
5561      "Text about clock requirement for caches belongs in p6"
5562    </t>
5563    <t>
5564      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/221"/>:
5565      "effective request URI: handling of missing host in HTTP/1.0"
5566    </t>
5567    <t>
5568      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/248"/>:
5569      "confusing Date requirements for clients"
5570    </t>
5571  </list>
5572</t>
5573<t>
5574  Partly resolved issues:
5575  <list style="symbols">
5576    <t>
5577      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>:
5578      "Handling multiple Content-Length headers"
5579    </t>
5580  </list>
5581</t>
5582</section>
5583
5584<section title="Since draft-ietf-httpbis-p1-messaging-12" anchor="changes.since.12">
5585<t>
5586  Closed issues:
5587  <list style="symbols">
5588    <t>
5589      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/75"/>:
5590      "RFC2145 Normative"
5591    </t>
5592    <t>
5593      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/159"/>:
5594      "HTTP(s) URI scheme definitions" (tune the requirements on userinfo)
5595    </t>
5596    <t>
5597      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/210"/>:
5598      "define 'transparent' proxy"
5599    </t>
5600    <t>
5601      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
5602      "Header Classification"
5603    </t>
5604    <t>
5605      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/233"/>:
5606      "Is * usable as a request-uri for new methods?"
5607    </t>
5608    <t>
5609      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/240"/>:
5610      "Migrate Upgrade details from RFC2817"
5611    </t>
5612    <t>
5613      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
5614      "untangle ABNFs for header fields"
5615    </t>
5616    <t>
5617      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/279"/>:
5618      "update RFC 2109 reference"
5619    </t>
5620  </list>
5621</t>
5622</section>
5623
5624<section title="Since draft-ietf-httpbis-p1-messaging-13" anchor="changes.since.13">
5625<t>
5626  Closed issues:
5627  <list style="symbols">
5628    <t>
5629      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/53"/>:
5630      "Allow is not in 13.5.2"
5631    </t>
5632    <t>
5633      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>:
5634      "Handling multiple Content-Length headers"
5635    </t>
5636    <t>
5637      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
5638      "untangle ABNFs for header fields"
5639    </t>
5640    <t>
5641      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/286"/>:
5642      "Content-Length ABNF broken"
5643    </t>
5644  </list>
5645</t>
5646</section>
5647
5648<section title="Since draft-ietf-httpbis-p1-messaging-14" anchor="changes.since.14">
5649<t>
5650  Closed issues:
5651  <list style="symbols">
5652    <t>
5653      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/273"/>:
5654      "HTTP-version should be redefined as fixed length pair of DIGIT . DIGIT"
5655    </t>
5656    <t>
5657      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/282"/>:
5658      "Recommend minimum sizes for protocol elements"
5659    </t>
5660    <t>
5661      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/283"/>:
5662      "Set expectations around buffering"
5663    </t>
5664    <t>
5665      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/288"/>:
5666      "Considering messages in isolation"
5667    </t>
5668  </list>
5669</t>
5670</section>
5671
5672<section title="Since draft-ietf-httpbis-p1-messaging-15" anchor="changes.since.15">
5673<t>
5674  Closed issues:
5675  <list style="symbols">
5676    <t>
5677      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/100"/>:
5678      "DNS Spoofing / DNS Binding advice"
5679    </t>
5680    <t>
5681      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/254"/>:
5682      "move RFCs 2145, 2616, 2817 to Historic status"
5683    </t>
5684    <t>
5685      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/270"/>:
5686      "\-escaping in quoted strings"
5687    </t>
5688    <t>
5689      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/305"/>:
5690      "'Close' should be reserved in the HTTP header field registry"
5691    </t>
5692  </list>
5693</t>
5694</section>
5695
5696<section title="Since draft-ietf-httpbis-p1-messaging-16" anchor="changes.since.16">
5697<t>
5698  Closed issues:
5699  <list style="symbols">
5700    <t>
5701      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
5702      "Document HTTP's error-handling philosophy"
5703    </t>
5704    <t>
5705      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/215"/>:
5706      "Explain header registration"
5707    </t>
5708    <t>
5709      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/219"/>:
5710      "Revise Acknowledgements Sections"
5711    </t>
5712    <t>
5713      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/297"/>:
5714      "Retrying Requests"
5715    </t>
5716    <t>
5717      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/318"/>:
5718      "Closing the connection on server error"
5719    </t>
5720  </list>
5721</t>
5722</section>
5723
5724<section title="Since draft-ietf-httpbis-p1-messaging-17" anchor="changes.since.17">
5725<t>
5726  Closed issues:
5727  <list style="symbols">
5728    <t>
5729      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/166"/>:
5730      "Clarify 'User Agent'"
5731    </t>
5732    <t>
5733      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/300"/>:
5734      "Define non-final responses"
5735    </t>
5736    <t>
5737      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/323"/>:
5738      "intended maturity level vs normative references"
5739    </t>
5740    <t>
5741      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/324"/>:
5742      "Intermediary rewriting of queries"
5743    </t>
5744    <t>
5745      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/158"/>:
5746      "Proxy-Connection and Keep-Alive"
5747    </t>
5748  </list>
5749</t>
5750</section>
5751
5752<section title="Since draft-ietf-httpbis-p1-messaging-18" anchor="changes.since.18">
5753<t>
5754  Closed issues:
5755  <list style="symbols">
5756    <t>
5757      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/250"/>:
5758      "message-body in CONNECT response"
5759    </t>
5760    <t>
5761      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/302"/>:
5762      "Misplaced text on connection handling in p2"
5763    </t>
5764    <t>
5765      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/335"/>:
5766      "wording of line folding rule"
5767    </t>
5768    <t>
5769      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/343"/>:
5770      "chunk-extensions"
5771    </t>
5772    <t>
5773      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/346"/>:
5774      "make IANA policy definitions consistent"
5775    </t>
5776  </list>
5777</t>
5778</section>
5779
5780</section>
5781
5782</back>
5783</rfc>
Note: See TracBrowser for help on using the repository browser.