source: draft-ietf-httpbis/05/draft-ietf-httpbis-p1-messaging-05.xml @ 381

Last change on this file since 381 was 381, checked in by julian.reschke@…, 11 years ago

Prepare release of draft 05.

File size: 183.2 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<!DOCTYPE rfc
17  PUBLIC "" "rfc2629.dtd">
18<rfc obsoletes="2616" category="std" ipr="full3978" docName="draft-ietf-httpbis-p1-messaging-05">
19<front>
20
21  <title abbrev="HTTP/1.1, Part 1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
22
23  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
24    <organization abbrev="Day Software">Day Software</organization>
25    <address>
26      <postal>
27        <street>23 Corporate Plaza DR, Suite 280</street>
28        <city>Newport Beach</city>
29        <region>CA</region>
30        <code>92660</code>
31        <country>USA</country>
32      </postal>
33      <phone>+1-949-706-5300</phone>
34      <facsimile>+1-949-706-5305</facsimile>
35      <email>fielding@gbiv.com</email>
36      <uri>http://roy.gbiv.com/</uri>
37    </address>
38  </author>
39
40  <author initials="J." surname="Gettys" fullname="Jim Gettys">
41    <organization>One Laptop per Child</organization>
42    <address>
43      <postal>
44        <street>21 Oak Knoll Road</street>
45        <city>Carlisle</city>
46        <region>MA</region>
47        <code>01741</code>
48        <country>USA</country>
49      </postal>
50      <email>jg@laptop.org</email>
51      <uri>http://www.laptop.org/</uri>
52    </address>
53  </author>
54 
55  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
56    <organization abbrev="HP">Hewlett-Packard Company</organization>
57    <address>
58      <postal>
59        <street>HP Labs, Large Scale Systems Group</street>
60        <street>1501 Page Mill Road, MS 1177</street>
61        <city>Palo Alto</city>
62        <region>CA</region>
63        <code>94304</code>
64        <country>USA</country>
65      </postal>
66      <email>JeffMogul@acm.org</email>
67    </address>
68  </author>
69
70  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
71    <organization abbrev="Microsoft">Microsoft Corporation</organization>
72    <address>
73      <postal>
74        <street>1 Microsoft Way</street>
75        <city>Redmond</city>
76        <region>WA</region>
77        <code>98052</code>
78        <country>USA</country>
79      </postal>
80      <email>henrikn@microsoft.com</email>
81    </address>
82  </author>
83
84  <author initials="L." surname="Masinter" fullname="Larry Masinter">
85    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
86    <address>
87      <postal>
88        <street>345 Park Ave</street>
89        <city>San Jose</city>
90        <region>CA</region>
91        <code>95110</code>
92        <country>USA</country>
93      </postal>
94      <email>LMM@acm.org</email>
95      <uri>http://larry.masinter.net/</uri>
96    </address>
97  </author>
98 
99  <author initials="P." surname="Leach" fullname="Paul J. Leach">
100    <organization abbrev="Microsoft">Microsoft Corporation</organization>
101    <address>
102      <postal>
103        <street>1 Microsoft Way</street>
104        <city>Redmond</city>
105        <region>WA</region>
106        <code>98052</code>
107      </postal>
108      <email>paulle@microsoft.com</email>
109    </address>
110  </author>
111   
112  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
113    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
114    <address>
115      <postal>
116        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
117        <street>The Stata Center, Building 32</street>
118        <street>32 Vassar Street</street>
119        <city>Cambridge</city>
120        <region>MA</region>
121        <code>02139</code>
122        <country>USA</country>
123      </postal>
124      <email>timbl@w3.org</email>
125      <uri>http://www.w3.org/People/Berners-Lee/</uri>
126    </address>
127  </author>
128
129  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
130    <organization abbrev="W3C">World Wide Web Consortium</organization>
131    <address>
132      <postal>
133        <street>W3C / ERCIM</street>
134        <street>2004, rte des Lucioles</street>
135        <city>Sophia-Antipolis</city>
136        <region>AM</region>
137        <code>06902</code>
138        <country>France</country>
139      </postal>
140      <email>ylafon@w3.org</email>
141      <uri>http://www.raubacapeu.net/people/yves/</uri>
142    </address>
143  </author>
144
145  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
146    <organization abbrev="greenbytes">greenbytes GmbH</organization>
147    <address>
148      <postal>
149        <street>Hafenweg 16</street>
150        <city>Muenster</city><region>NW</region><code>48155</code>
151        <country>Germany</country>
152      </postal>
153      <phone>+49 251 2807760</phone>   
154      <facsimile>+49 251 2807761</facsimile>   
155      <email>julian.reschke@greenbytes.de</email>       
156      <uri>http://greenbytes.de/tech/webdav/</uri>     
157    </address>
158  </author>
159
160  <date month="November" year="2008" day="16"/>
161
162<abstract>
163<t>
164   The Hypertext Transfer Protocol (HTTP) is an application-level
165   protocol for distributed, collaborative, hypermedia information
166   systems. HTTP has been in use by the World Wide Web global information
167   initiative since 1990. This document is Part 1 of the seven-part specification
168   that defines the protocol referred to as "HTTP/1.1" and, taken together,
169   obsoletes RFC 2616.  Part 1 provides an overview of HTTP and
170   its associated terminology, defines the "http" and "https" Uniform
171   Resource Identifier (URI) schemes, defines the generic message syntax
172   and parsing requirements for HTTP message frames, and describes
173   general security concerns for implementations.
174</t>
175</abstract>
176
177<note title="Editorial Note (To be removed by RFC Editor)">
178  <t>
179    Discussion of this draft should take place on the HTTPBIS working group
180    mailing list (ietf-http-wg@w3.org). The current issues list is
181    at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/11"/>
182    and related documents (including fancy diffs) can be found at
183    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
184  </t>
185  <t>
186    The changes in this draft are summarized in <xref target="changes.since.04"/>.
187  </t>
188</note>
189</front>
190<middle>
191<section title="Introduction" anchor="introduction">
192<t>
193   The Hypertext Transfer Protocol (HTTP) is an application-level
194   request/response protocol that uses extensible semantics and MIME-like
195   message payloads for flexible interaction with network-based hypermedia
196   information systems. HTTP relies upon the Uniform Resource Identifier (URI)
197   standard <xref target="RFC3986"/> to indicate resource targets for
198   interaction and to identify other resources.
199   Messages are passed in a format similar to that used by Internet mail
200   <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
201   (MIME) <xref target="RFC2045"/> (see Appendix A of <xref target="Part3"/> for the differences
202   between HTTP and MIME messages).
203</t>
204<t>
205   HTTP is also designed for use as a generic protocol for translating
206   communication to and from other Internet information systems, such as
207   USENET news services via NNTP <xref target="RFC3977"/>,
208   file services via FTP <xref target="RFC959"/>,
209   Gopher <xref target="RFC1436"/>, and WAIS <xref target="WAIS"/>.
210   HTTP proxies and gateways provide access to alternative information
211   services by translating their diverse protocols into a hypermedia
212   format that can be viewed and manipulated by clients in the same way
213   as HTTP services.
214</t>
215<t>
216   This document is Part 1 of the seven-part specification of HTTP,
217   defining the protocol referred to as "HTTP/1.1" and obsoleting
218   <xref target="RFC2616"/>.
219   Part 1 defines how clients determine when to use HTTP, the URI schemes
220   specific to HTTP-based resources, overall network operation with
221   transport protocol connection management, and HTTP message framing.
222   Our goal is to define all of the mechanisms necessary for HTTP message
223   handling that are independent of message semantics, thereby defining the
224   complete set of requirements for an HTTP message relay or generic
225   message parser.
226</t>
227
228<section title="Requirements" anchor="intro.requirements">
229<t>
230   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
231   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
232   document are to be interpreted as described in <xref target="RFC2119"/>.
233</t>
234<t>
235   An implementation is not compliant if it fails to satisfy one or more
236   of the MUST or REQUIRED level requirements for the protocols it
237   implements. An implementation that satisfies all the MUST or REQUIRED
238   level and all the SHOULD level requirements for its protocols is said
239   to be "unconditionally compliant"; one that satisfies all the MUST
240   level requirements but not all the SHOULD level requirements for its
241   protocols is said to be "conditionally compliant."
242</t>
243</section>
244
245<section title="Overall Operation" anchor="intro.overall.operation">
246<t>
247   HTTP is a request/response protocol. A client sends a
248   request to the server in the form of a request method, URI, and
249   protocol version, followed by a MIME-like message containing request
250   modifiers, client information, and possible body content over a
251   connection with a server. The server responds with a status line,
252   including the message's protocol version and a success or error code,
253   followed by a MIME-like message containing server information, entity
254   metainformation, and possible entity-body content. The relationship
255   between HTTP and MIME is described in Appendix A of <xref target="Part3"/>.
256</t>
257<t>
258   Most HTTP communication is initiated by a user agent and consists of
259   a request to be applied to a resource on some origin server. In the
260   simplest case, this may be accomplished via a single connection (v)
261   between the user agent (UA) and the origin server (O).
262</t>
263<figure><artwork type="drawing"><![CDATA[
264       request chain ------------------------>
265    UA -------------------v------------------- O
266       <----------------------- response chain
267]]></artwork></figure>
268<t>
269   A more complicated situation occurs when one or more intermediaries
270   are present in the request/response chain. There are three common
271   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
272   forwarding agent, receiving requests for a URI in its absolute form,
273   rewriting all or part of the message, and forwarding the reformatted
274   request toward the server identified by the URI. A gateway is a
275   receiving agent, acting as a layer above some other server(s) and, if
276   necessary, translating the requests to the underlying server's
277   protocol. A tunnel acts as a relay point between two connections
278   without changing the messages; tunnels are used when the
279   communication needs to pass through an intermediary (such as a
280   firewall) even when the intermediary cannot understand the contents
281   of the messages.
282</t>
283<figure><artwork type="drawing"><![CDATA[
284       request chain -------------------------------------->
285    UA -----v----- A -----v----- B -----v----- C -----v----- O
286       <------------------------------------- response chain
287]]></artwork></figure>
288<t>
289   The figure above shows three intermediaries (A, B, and C) between the
290   user agent and origin server. A request or response message that
291   travels the whole chain will pass through four separate connections.
292   This distinction is important because some HTTP communication options
293   may apply only to the connection with the nearest, non-tunnel
294   neighbor, only to the end-points of the chain, or to all connections
295   along the chain. Although the diagram is linear, each participant may
296   be engaged in multiple, simultaneous communications. For example, B
297   may be receiving requests from many clients other than A, and/or
298   forwarding requests to servers other than C, at the same time that it
299   is handling A's request.
300</t>
301<t>
302   Any party to the communication which is not acting as a tunnel may
303   employ an internal cache for handling requests. The effect of a cache
304   is that the request/response chain is shortened if one of the
305   participants along the chain has a cached response applicable to that
306   request. The following illustrates the resulting chain if B has a
307   cached copy of an earlier response from O (via C) for a request which
308   has not been cached by UA or A.
309</t>
310<figure><artwork type="drawing"><![CDATA[
311          request chain ---------->
312       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
313          <--------- response chain
314]]></artwork></figure>
315<t>
316   Not all responses are usefully cacheable, and some requests may
317   contain modifiers which place special requirements on cache behavior.
318   HTTP requirements for cache behavior and cacheable responses are
319   defined in Section 1 of <xref target="Part6"/>.
320</t>
321<t>
322   In fact, there are a wide variety of architectures and configurations
323   of caches and proxies currently being experimented with or deployed
324   across the World Wide Web. These systems include national hierarchies
325   of proxy caches to save transoceanic bandwidth, systems that
326   broadcast or multicast cache entries, organizations that distribute
327   subsets of cached data via CD-ROM, and so on. HTTP systems are used
328   in corporate intranets over high-bandwidth links, and for access via
329   PDAs with low-power radio links and intermittent connectivity. The
330   goal of HTTP/1.1 is to support the wide diversity of configurations
331   already deployed while introducing protocol constructs that meet the
332   needs of those who build web applications that require high
333   reliability and, failing that, at least reliable indications of
334   failure.
335</t>
336<t>
337   HTTP communication usually takes place over TCP/IP connections. The
338   default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
339   not preclude HTTP from being implemented on top of any other protocol
340   on the Internet, or on other networks. HTTP only presumes a reliable
341   transport; any protocol that provides such guarantees can be used;
342   the mapping of the HTTP/1.1 request and response structures onto the
343   transport data units of the protocol in question is outside the scope
344   of this specification.
345</t>
346<t>
347   In HTTP/1.0, most implementations used a new connection for each
348   request/response exchange. In HTTP/1.1, a connection may be used for
349   one or more request/response exchanges, although connections may be
350   closed for a variety of reasons (see <xref target="persistent.connections"/>).
351</t>
352</section>
353</section>
354
355<section title="Notational Conventions and Generic Grammar" anchor="notation">
356
357<section title="ABNF Extension: #rule" anchor="notation.abnf">
358  <t>
359    One extension to the ABNF rules of <xref target="RFC5234"/> is used to
360    improve readability.
361  </t>
362  <t>
363    A construct "#" is defined, similar to "*", for defining lists of
364    elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at least
365    &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas
366    (",") and OPTIONAL linear white space (OWS). This makes the usual
367    form of lists very easy; a rule such as
368    <figure><artwork type="example"><![CDATA[
369 ( *OWS element *( *OWS "," *OWS element ))]]></artwork></figure>
370  </t>
371  <t>
372    can be shown as
373    <figure><artwork type="example"><![CDATA[
374 1#element]]></artwork></figure>
375  </t>
376  <t>
377    Wherever this construct is used, null elements are allowed, but do
378    not contribute to the count of elements present. That is,
379    "(element), , (element) " is permitted, but counts as only two
380    elements. Therefore, where at least one element is required, at
381    least one non-null element MUST be present. Default values are 0
382    and infinity so that "#element" allows any number, including zero;
383    "1#element" requires at least one; and "1#2element" allows one or
384    two.
385  </t>
386  <t>
387    <cref anchor="abnf.list">
388      At a later point of time, we may want to add an appendix containing
389      the whole ABNF, with the list rules expanded to strict RFC 5234
390      notation.
391    </cref>
392  </t>
393</section>
394
395<section title="Basic Rules" anchor="basic.rules">
396<t anchor="core.rules">
397 
398 
399 
400 
401 
402 
403 
404 
405 
406 
407 
408 
409 
410   This specification uses the Augmented Backus-Naur Form (ABNF) notation
411   of <xref target="RFC5234"/>.  The following core rules are included by
412   reference, as defined in <xref target="RFC5234"/>, Appendix B.1:
413   ALPHA (letters), CHAR (any <xref target="USASCII"/> character,
414   excluding NUL), CR (carriage return), CRLF (CR LF), CTL (controls),
415   DIGIT (decimal 0-9), DQUOTE (double quote),
416   HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab),
417   LF (line feed), OCTET (any 8-bit sequence of data), SP (space)
418   and WSP (white space).
419</t>
420<t anchor="rule.CRLF">
421 
422   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
423   protocol elements except the entity-body (see <xref target="tolerant.applications"/> for
424   tolerant applications). The end-of-line marker within an entity-body
425   is defined by its associated media type, as described in Section 3.3 of <xref target="Part3"/>.
426</t>
427<t anchor="rule.LWS">
428   All linear white space (LWS) in header field-values has the same semantics as SP. A
429   recipient MAY replace any such linear white space with a single SP before
430   interpreting the field value or forwarding the message downstream.
431</t>
432<t>
433   Historically, HTTP/1.1 header field values allow linear white space folding across
434   multiple lines. However, this specification deprecates its use; senders MUST NOT
435   produce messages that include LWS folding (i.e., use the obs-fold rule), except
436   within the message/http media type (<xref target="internet.media.type.message.http"/>).
437   Receivers SHOULD still parse folded linear white space.
438</t>
439<t>
440   This specification uses three rules to denote the use of linear white space;
441   BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space).
442</t>
443<t>
444   "Bad" white space is allowed by the BNF, but senders SHOULD NOT produce it in messages.
445   Receivers MUST accept it in incoming messages.
446</t>
447<t>
448   Required white space is used when at least one linear white space character
449   is required to separate field tokens. In all such cases, a single SP character
450   SHOULD be used.
451</t>
452<t anchor="rule.whitespace">
453 
454 
455 
456 
457</t>
458<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[
459  OWS            = *( [ obs-fold ] WSP )
460                 ; "optional" white space
461  RWS            = 1*( [ obs-fold ] WSP )
462                 ; "required" white space
463  BWS            = OWS
464                 ; "bad" white space
465  obs-fold       = CRLF
466]]></artwork></figure>
467<t anchor="rule.TEXT">
468 
469   The TEXT rule is only used for descriptive field contents and values
470   that are not intended to be interpreted by the message parser. Words
471   of *TEXT MAY contain characters from character sets other than ISO-8859-1
472   <xref target="ISO-8859-1"/> only when encoded according to the rules of
473   <xref target="RFC2047"/>.
474</t>
475<figure><iref primary="true" item="Grammar" subitem="TEXT"/><artwork type="abnf2616"><![CDATA[
476  TEXT           = %x20-7E / %x80-FF / OWS
477                 ; any OCTET except CTLs, but including OWS
478]]></artwork></figure>
479<t>
480   A CRLF is allowed in the definition of TEXT only as part of a header
481   field continuation. It is expected that the folding LWS will be
482   replaced with a single SP before interpretation of the TEXT value.
483</t>
484<t anchor="rule.token.separators">
485 
486 
487   Many HTTP/1.1 header field values consist of words separated by LWS
488   or special characters. These special characters MUST be in a quoted
489   string to be used within a parameter value (as defined in
490   <xref target="transfer.codings"/>).
491</t>
492<figure><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><artwork type="abnf2616"><![CDATA[
493  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
494                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
495                 / DIGIT / ALPHA
496                 
497  token          = 1*tchar
498]]></artwork></figure>
499<t anchor="rule.comment">
500 
501 
502   Comments can be included in some HTTP header fields by surrounding
503   the comment text with parentheses. Comments are only allowed in
504   fields containing "comment" as part of their field value definition.
505   In all other fields, parentheses are considered part of the field
506   value.
507</t>
508<figure><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/><artwork type="abnf2616"><![CDATA[
509  comment        = "(" *( ctext / quoted-pair / comment ) ")"
510  ctext          = <any TEXT excluding "(" and ")">
511]]></artwork></figure>
512<t anchor="rule.quoted-string">
513 
514 
515   A string of text is parsed as a single word if it is quoted using
516   double-quote marks.
517</t>
518<figure><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><artwork type="abnf2616"><![CDATA[
519  quoted-string  = DQUOTE *(qdtext / quoted-pair ) DQUOTE
520  qdtext         = <any TEXT excluding DQUOTE and "\">
521]]></artwork></figure>
522<t anchor="rule.quoted-pair">
523 
524 
525   The backslash character ("\") MAY be used as a single-character
526   quoting mechanism only within quoted-string and comment constructs.
527</t>
528<figure><iref primary="true" item="Grammar" subitem="quoted-text"/><iref primary="true" item="Grammar" subitem="quoted-pair"/><artwork type="abnf2616"><![CDATA[
529  quoted-text    = %x01-09 /
530                   %x0B-0C /
531                   %x0E-FF ; Characters excluding NUL, CR and LF
532  quoted-pair    = "\" quoted-text
533]]></artwork></figure>
534</section>
535
536<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
537 
538 
539 
540 
541 
542 
543 
544 
545<t>
546  The ABNF rules below are defined in other parts:
547</t>
548<figure><!-- Part2--><artwork type="abnf2616"><![CDATA[
549  request-header  = <request-header, defined in [Part2], Section 4>
550  response-header = <response-header, defined in [Part2], Section 6>
551]]></artwork></figure>
552<figure><!-- Part3--><artwork type="abnf2616"><![CDATA[
553  accept-params   = <accept-params, defined in [Part3], Section 6.1>
554  entity-body     = <entity-body, defined in [Part3], Section 4.2>
555  entity-header   = <entity-header, defined in [Part3], Section 4.1>
556]]></artwork></figure>
557<figure><!-- Part6--><artwork type="abnf2616"><![CDATA[
558  Cache-Control   = <Cache-Control, defined in [Part6], Section 16.4>
559  Pragma          = <Pragma, defined in [Part6], Section 16.4>
560  Warning         = <Warning, defined in [Part6], Section 16.6>
561]]></artwork></figure>
562</section>
563
564</section>
565
566<section title="Protocol Parameters" anchor="protocol.parameters">
567
568<section title="HTTP Version" anchor="http.version">
569 
570 
571<t>
572   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions
573   of the protocol. The protocol versioning policy is intended to allow
574   the sender to indicate the format of a message and its capacity for
575   understanding further HTTP communication, rather than the features
576   obtained via that communication. No change is made to the version
577   number for the addition of message components which do not affect
578   communication behavior or which only add to extensible field values.
579   The &lt;minor&gt; number is incremented when the changes made to the
580   protocol add features which do not change the general message parsing
581   algorithm, but which may add to the message semantics and imply
582   additional capabilities of the sender. The &lt;major&gt; number is
583   incremented when the format of a message within the protocol is
584   changed. See <xref target="RFC2145"/> for a fuller explanation.
585</t>
586<t>
587   The version of an HTTP message is indicated by an HTTP-Version field
588   in the first line of the message. HTTP-Version is case-sensitive.
589</t>
590<figure><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/><artwork type="abnf2616"><![CDATA[
591  HTTP-Version   = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
592  HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
593]]></artwork></figure>
594<t>
595   Note that the major and minor numbers MUST be treated as separate
596   integers and that each MAY be incremented higher than a single digit.
597   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
598   lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
599   MUST NOT be sent.
600</t>
601<t>
602   An application that sends a request or response message that includes
603   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
604   with this specification. Applications that are at least conditionally
605   compliant with this specification SHOULD use an HTTP-Version of
606   "HTTP/1.1" in their messages, and MUST do so for any message that is
607   not compatible with HTTP/1.0. For more details on when to send
608   specific HTTP-Version values, see <xref target="RFC2145"/>.
609</t>
610<t>
611   The HTTP version of an application is the highest HTTP version for
612   which the application is at least conditionally compliant.
613</t>
614<t>
615   Proxy and gateway applications need to be careful when forwarding
616   messages in protocol versions different from that of the application.
617   Since the protocol version indicates the protocol capability of the
618   sender, a proxy/gateway MUST NOT send a message with a version
619   indicator which is greater than its actual version. If a higher
620   version request is received, the proxy/gateway MUST either downgrade
621   the request version, or respond with an error, or switch to tunnel
622   behavior.
623</t>
624<t>
625   Due to interoperability problems with HTTP/1.0 proxies discovered
626   since the publication of <xref target="RFC2068"/>, caching proxies MUST, gateways
627   MAY, and tunnels MUST NOT upgrade the request to the highest version
628   they support. The proxy/gateway's response to that request MUST be in
629   the same major version as the request.
630</t>
631<t>
632  <list>
633    <t>
634      Note: Converting between versions of HTTP may involve modification
635      of header fields required or forbidden by the versions involved.
636    </t>
637  </list>
638</t>
639</section>
640
641<section title="Uniform Resource Identifiers" anchor="uri">
642<t>
643   Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP
644   to indicate the target of a request and to identify additional resources related
645   to that resource, the request, or the response. Each protocol element in HTTP
646   that allows a URI reference will indicate in its ABNF whether the element allows
647   only a URI in absolute form, any relative reference, or some limited subset of
648   the URI-reference grammar. Unless otherwise indicated, relative URI references
649   are to be parsed relative to the URI corresponding to the request target
650   (the base URI).
651</t>
652 
653 
654 
655 
656 
657 
658 
659 
660 
661 
662 
663<t>
664   This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port",
665   "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>:
666</t>
667<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"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="relative-part"/><artwork type="abnf2616"><![CDATA[
668  absolute-URI   = <absolute-URI, defined in [RFC3986], Section 4.3>
669  authority     = <authority, defined in [RFC3986], Section 3.2>
670  fragment      = <fragment, defined in [RFC3986], Section 3.5>
671  path-abempty  = <path-abempty, defined in [RFC3986], Section 3.3>
672  path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
673  port          = <port, defined in [RFC3986], Section 3.2.3>
674  query         = <query, defined in [RFC3986], Section 3.4>
675  uri-host      = <host, defined in [RFC3986], Section 3.2.2>
676
677  relative-part = <relative-part, defined in [RFC3986], Section 4.2>
678  relativeURI   = relative-part [ "?" query ]
679]]></artwork></figure>
680<t>
681   HTTP does not place an a priori limit on the length of
682   a URI. Servers MUST be able to handle the URI of any resource they
683   serve, and SHOULD be able to handle URIs of unbounded length if they
684   provide GET-based forms that could generate such URIs. A server
685   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
686   than the server can handle (see Section 9.4.15 of <xref target="Part2"/>).
687</t>
688<t>
689  <list>
690    <t>
691      Note: Servers ought to be cautious about depending on URI lengths
692      above 255 bytes, because some older client or proxy
693      implementations might not properly support these lengths.
694    </t>
695  </list>
696</t>
697
698<section title="http URI scheme" anchor="http.uri">
699 
700  <iref item="http URI scheme" primary="true"/>
701  <iref item="URI scheme" subitem="http" primary="true"/>
702<t>
703   The "http" scheme is used to locate network resources via the HTTP
704   protocol. This section defines the syntax and semantics for identifiers
705   using the http or https URI schemes.
706</t>
707<figure><iref primary="true" item="Grammar" subitem="http-URI"/><artwork type="abnf2616"><![CDATA[
708  http-URI = "http:" "//" authority path-abempty [ "?" query ]
709]]></artwork></figure>
710<t>
711   If the port is empty or not given, port 80 is assumed. The semantics
712   are that the identified resource is located at the server listening
713   for TCP connections on that port of that host, and the Request-URI
714   for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses
715   in URLs SHOULD be avoided whenever possible (see <xref target="RFC1900"/>). If
716   the path-absolute is not present in the URL, it MUST be given as "/" when
717   used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
718   receives a host name which is not a fully qualified domain name, it
719   MAY add its domain to the host name it received. If a proxy receives
720   a fully qualified domain name, the proxy MUST NOT change the host
721   name.
722</t>
723<t><list><t>
724  <iref item="https URI scheme"/>
725  <iref item="URI scheme" subitem="https"/>
726  Note: the "https" scheme is defined in <xref target="RFC2818"/>.
727</t></list></t>
728</section>
729
730<section title="URI Comparison" anchor="uri.comparison">
731<t>
732   When comparing two URIs to decide if they match or not, a client
733   SHOULD use a case-sensitive octet-by-octet comparison of the entire
734   URIs, with these exceptions:
735  <list style="symbols">
736    <t>A port that is empty or not given is equivalent to the default
737        port for that URI-reference;</t>
738    <t>Comparisons of host names MUST be case-insensitive;</t>
739    <t>Comparisons of scheme names MUST be case-insensitive;</t>
740    <t>An empty path-absolute is equivalent to an path-absolute of "/".</t>
741  </list>
742</t>
743<t>
744   Characters other than those in the "reserved" set (see
745   <xref target="RFC3986"/>, Section 2.2) are equivalent to their
746   ""%" <xref target="core.rules" format="none">HEXDIG</xref> <xref target="core.rules" format="none">HEXDIG</xref>" encoding.
747</t>
748<t>
749   For example, the following three URIs are equivalent:
750</t>
751<figure><artwork type="example"><![CDATA[
752   http://example.com:80/~smith/home.html
753   http://EXAMPLE.com/%7Esmith/home.html
754   http://EXAMPLE.com:/%7esmith/home.html
755]]></artwork></figure>
756</section>
757</section>
758
759<section title="Date/Time Formats" anchor="date.time.formats">
760<section title="Full Date" anchor="full.date">
761 
762 
763 
764 
765 
766 
767 
768 
769 
770 
771 
772 
773 
774<t>
775   HTTP applications have historically allowed three different formats
776   for the representation of date/time stamps:
777</t>
778<figure><artwork type="example"><![CDATA[
779   Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
780   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
781   Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
782]]></artwork></figure>
783<t>
784   The first format is preferred as an Internet standard and represents
785   a fixed-length subset of that defined by <xref target="RFC1123"/> (an update to
786   <xref target="RFC822"/>). The other formats are described here only for
787   compatibility with obsolete implementations.
788   HTTP/1.1 clients and servers that parse the date value MUST accept
789   all three formats (for compatibility with HTTP/1.0), though they MUST
790   only generate the RFC 1123 format for representing HTTP-date values
791   in header fields. See <xref target="tolerant.applications"/> for further information.
792</t>
793<t><list><t>
794      Note: Recipients of date values are encouraged to be robust in
795      accepting date values that may have been sent by non-HTTP
796      applications, as is sometimes the case when retrieving or posting
797      messages via proxies/gateways to SMTP or NNTP.
798</t></list></t>
799<t>
800   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
801   (GMT), without exception. For the purposes of HTTP, GMT is exactly
802   equal to UTC (Coordinated Universal Time). This is indicated in the
803   first two formats by the inclusion of "GMT" as the three-letter
804   abbreviation for time zone, and MUST be assumed when reading the
805   asctime format. HTTP-date is case sensitive and MUST NOT include
806   additional LWS beyond that specifically included as SP in the
807   grammar.
808</t>
809<figure><iref primary="true" item="Grammar" subitem="HTTP-date"/><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="obsolete-date"/><iref primary="true" item="Grammar" subitem="rfc850-date"/><iref primary="true" item="Grammar" subitem="asctime-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/><iref primary="true" item="Grammar" subitem="time"/><iref primary="true" item="Grammar" subitem="wkday"/><iref primary="true" item="Grammar" subitem="weekday"/><iref primary="true" item="Grammar" subitem="month"/><artwork type="abnf2616"><![CDATA[
810  HTTP-date    = rfc1123-date / obsolete-date
811  obsolete-date = rfc850-date / asctime-date
812  rfc1123-date = wkday "," SP date1 SP time SP GMT
813  rfc850-date  = weekday "," SP date2 SP time SP GMT
814  asctime-date = wkday SP date3 SP time SP 4DIGIT
815  date1        = 2DIGIT SP month SP 4DIGIT
816                 ; day month year (e.g., 02 Jun 1982)
817  date2        = 2DIGIT "-" month "-" 2DIGIT
818                 ; day-month-year (e.g., 02-Jun-82)
819  date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
820                 ; month day (e.g., Jun  2)
821  time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
822                 ; 00:00:00 - 23:59:59
823  wkday        = s-Mon / s-Tue / s-Wed
824               / s-Thu / s-Fri / s-Sat / s-Sun
825  weekday      = l-Mon / l-Tue / l-Wed
826               / l-Thu / l-Fri / l-Sat / l-Sun
827  month        = s-Jan / s-Feb / s-Mar / s-Apr
828               / s-May / s-Jun / s-Jul / s-Aug
829               / s-Sep / s-Oct / s-Nov / s-Dec
830               
831  GMT   = %x47.4D.54 ; "GMT", case-sensitive
832
833  s-Mon = %x4D.6F.6E ; "Mon", case-sensitive
834  s-Tue = %x54.75.65 ; "Tue", case-sensitive
835  s-Wed = %x57.65.64 ; "Wed", case-sensitive
836  s-Thu = %x54.68.75 ; "Thu", case-sensitive
837  s-Fri = %x46.72.69 ; "Fri", case-sensitive
838  s-Sat = %x53.61.74 ; "Sat", case-sensitive
839  s-Sun = %x53.75.6E ; "Sun", case-sensitive
840
841  l-Mon = %x4D.6F.6E.64.61.79          ; "Monday", case-sensitive
842  l-Tue = %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
843  l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
844  l-Thu = %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
845  l-Fri = %x46.72.69.64.61.79          ; "Friday", case-sensitive
846  l-Sat = %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
847  l-Sun = %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
848
849  s-Jan = %x4A.61.6E ; "Jan", case-sensitive
850  s-Feb = %x46.65.62 ; "Feb", case-sensitive
851  s-Mar = %x4D.61.72 ; "Mar", case-sensitive
852  s-Apr = %x41.70.72 ; "Apr", case-sensitive
853  s-May = %x4D.61.79 ; "May", case-sensitive
854  s-Jun = %x4A.75.6E ; "Jun", case-sensitive
855  s-Jul = %x4A.75.6C ; "Jul", case-sensitive
856  s-Aug = %x41.75.67 ; "Aug", case-sensitive
857  s-Sep = %x53.65.70 ; "Sep", case-sensitive
858  s-Oct = %x4F.63.74 ; "Oct", case-sensitive
859  s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
860  s-Dec = %x44.65.63 ; "Dec", case-sensitive
861]]></artwork></figure>
862<t>
863      Note: HTTP requirements for the date/time stamp format apply only
864      to their usage within the protocol stream. Clients and servers are
865      not required to use these formats for user presentation, request
866      logging, etc.
867</t>
868</section>
869</section>
870
871<section title="Transfer Codings" anchor="transfer.codings">
872 
873 
874 
875<t>
876   Transfer-coding values are used to indicate an encoding
877   transformation that has been, can be, or may need to be applied to an
878   entity-body in order to ensure "safe transport" through the network.
879   This differs from a content coding in that the transfer-coding is a
880   property of the message, not of the original entity.
881</t>
882<figure><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/><artwork type="abnf2616"><![CDATA[
883  transfer-coding         = "chunked" / transfer-extension
884  transfer-extension      = token *( OWS ";" OWS parameter )
885]]></artwork></figure>
886<t anchor="rule.parameter">
887 
888 
889 
890   Parameters are in  the form of attribute/value pairs.
891</t>
892<figure><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/><artwork type="abnf2616"><![CDATA[
893  parameter               = attribute BWS "=" BWS value
894  attribute               = token
895  value                   = token / quoted-string
896]]></artwork></figure>
897<t>
898   All transfer-coding values are case-insensitive. HTTP/1.1 uses
899   transfer-coding values in the TE header field (<xref target="header.te"/>) and in
900   the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
901</t>
902<t>
903   Whenever a transfer-coding is applied to a message-body, the set of
904   transfer-codings MUST include "chunked", unless the message indicates it
905   is terminated by closing the connection. When the "chunked" transfer-coding
906   is used, it MUST be the last transfer-coding applied to the
907   message-body. The "chunked" transfer-coding MUST NOT be applied more
908   than once to a message-body. These rules allow the recipient to
909   determine the transfer-length of the message (<xref target="message.length"/>).
910</t>
911<t>
912   Transfer-codings are analogous to the Content-Transfer-Encoding
913   values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of
914   binary data over a 7-bit transport service. However, safe transport
915   has a different focus for an 8bit-clean transfer protocol. In HTTP,
916   the only unsafe characteristic of message-bodies is the difficulty in
917   determining the exact body length (<xref target="message.length"/>), or the desire to
918   encrypt data over a shared transport.
919</t>
920<t>
921   The Internet Assigned Numbers Authority (IANA) acts as a registry for
922   transfer-coding value tokens. Initially, the registry contains the
923   following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>),
924   "gzip", "compress", and "deflate" (Section 3.2 of <xref target="Part3"/>).
925</t>
926<t>
927   New transfer-coding value tokens SHOULD be registered in the same way
928   as new content-coding value tokens (Section 3.2 of <xref target="Part3"/>).
929</t>
930<t>
931   A server which receives an entity-body with a transfer-coding it does
932   not understand SHOULD return 501 (Not Implemented), and close the
933   connection. A server MUST NOT send transfer-codings to an HTTP/1.0
934   client.
935</t>
936
937<section title="Chunked Transfer Coding" anchor="chunked.transfer.encoding">
938 
939 
940 
941 
942 
943 
944 
945 
946 
947<t>
948   The chunked encoding modifies the body of a message in order to
949   transfer it as a series of chunks, each with its own size indicator,
950   followed by an OPTIONAL trailer containing entity-header fields. This
951   allows dynamically produced content to be transferred along with the
952   information necessary for the recipient to verify that it has
953   received the full message.
954</t>
955<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"/><artwork type="abnf2616"><![CDATA[
956  Chunked-Body   = *chunk
957                   last-chunk
958                   trailer-part
959                   CRLF
960 
961  chunk          = chunk-size *WSP [ chunk-ext ] CRLF
962                   chunk-data CRLF
963  chunk-size     = 1*HEXDIG
964  last-chunk     = 1*("0") *WSP [ chunk-ext ] CRLF
965 
966  chunk-ext      = *( ";" *WSP chunk-ext-name
967                      [ "=" chunk-ext-val ] *WSP )
968  chunk-ext-name = token
969  chunk-ext-val  = token / quoted-string
970  chunk-data     = 1*OCTET ; a sequence of chunk-size octets
971  trailer-part   = *(entity-header CRLF)
972]]></artwork></figure>
973<t>
974   The chunk-size field is a string of hex digits indicating the size of
975   the chunk-data in octets. The chunked encoding is ended by any chunk whose size is
976   zero, followed by the trailer, which is terminated by an empty line.
977</t>
978<t>
979   The trailer allows the sender to include additional HTTP header
980   fields at the end of the message. The Trailer header field can be
981   used to indicate which header fields are included in a trailer (see
982   <xref target="header.trailer"/>).
983</t>
984<t>
985   A server using chunked transfer-coding in a response MUST NOT use the
986   trailer for any header fields unless at least one of the following is
987   true:
988  <list style="numbers">
989    <t>the request included a TE header field that indicates "trailers" is
990     acceptable in the transfer-coding of the  response, as described in
991     <xref target="header.te"/>; or,</t>
992
993    <t>the server is the origin server for the response, the trailer
994     fields consist entirely of optional metadata, and the recipient
995     could use the message (in a manner acceptable to the origin server)
996     without receiving this metadata.  In other words, the origin server
997     is willing to accept the possibility that the trailer fields might
998     be silently discarded along the path to the client.</t>
999  </list>
1000</t>
1001<t>
1002   This requirement prevents an interoperability failure when the
1003   message is being received by an HTTP/1.1 (or later) proxy and
1004   forwarded to an HTTP/1.0 recipient. It avoids a situation where
1005   compliance with the protocol would have necessitated a possibly
1006   infinite buffer on the proxy.
1007</t>
1008<t>
1009   A process for decoding the "chunked" transfer-coding
1010   can be represented in pseudo-code as:
1011</t>
1012<figure><artwork type="code"><![CDATA[
1013  length := 0
1014  read chunk-size, chunk-ext (if any) and CRLF
1015  while (chunk-size > 0) {
1016     read chunk-data and CRLF
1017     append chunk-data to entity-body
1018     length := length + chunk-size
1019     read chunk-size and CRLF
1020  }
1021  read entity-header
1022  while (entity-header not empty) {
1023     append entity-header to existing header fields
1024     read entity-header
1025  }
1026  Content-Length := length
1027  Remove "chunked" from Transfer-Encoding
1028]]></artwork></figure>
1029<t>
1030   All HTTP/1.1 applications MUST be able to receive and decode the
1031   "chunked" transfer-coding, and MUST ignore chunk-ext extensions
1032   they do not understand.
1033</t>
1034</section>
1035</section>
1036
1037<section title="Product Tokens" anchor="product.tokens">
1038 
1039 
1040<t>
1041   Product tokens are used to allow communicating applications to
1042   identify themselves by software name and version. Most fields using
1043   product tokens also allow sub-products which form a significant part
1044   of the application to be listed, separated by white space. By
1045   convention, the products are listed in order of their significance
1046   for identifying the application.
1047</t>
1048<figure><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/><artwork type="abnf2616"><![CDATA[
1049  product         = token ["/" product-version]
1050  product-version = token
1051]]></artwork></figure>
1052<t>
1053   Examples:
1054</t>
1055<figure><artwork type="example"><![CDATA[
1056    User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1057    Server: Apache/0.8.4
1058]]></artwork></figure>
1059<t>
1060   Product tokens SHOULD be short and to the point. They MUST NOT be
1061   used for advertising or other non-essential information. Although any
1062   token character MAY appear in a product-version, this token SHOULD
1063   only be used for a version identifier (i.e., successive versions of
1064   the same product SHOULD only differ in the product-version portion of
1065   the product value).
1066</t>
1067</section>
1068
1069</section>
1070
1071<section title="HTTP Message" anchor="http.message">
1072
1073<section title="Message Types" anchor="message.types">
1074 
1075 
1076 
1077<t>
1078   HTTP messages consist of requests from client to server and responses
1079   from server to client.
1080</t>
1081<figure><iref primary="true" item="Grammar" subitem="HTTP-message"/><artwork type="abnf2616"><![CDATA[
1082  HTTP-message   = Request / Response     ; HTTP/1.1 messages
1083]]></artwork></figure>
1084<t>
1085   Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic
1086   message format of <xref target="RFC5322"/> for transferring entities (the payload
1087   of the message). Both types of message consist of a start-line, zero
1088   or more header fields (also known as "headers"), an empty line (i.e.,
1089   a line with nothing preceding the CRLF) indicating the end of the
1090   header fields, and possibly a message-body.
1091</t>
1092<figure><iref primary="true" item="Grammar" subitem="generic-message"/><iref primary="true" item="Grammar" subitem="start-line"/><artwork type="abnf2616"><![CDATA[
1093  generic-message = start-line
1094                    *(message-header CRLF)
1095                    CRLF
1096                    [ message-body ]
1097  start-line      = Request-Line / Status-Line
1098]]></artwork></figure>
1099<t>
1100   In the interest of robustness, servers SHOULD ignore any empty
1101   line(s) received where a Request-Line is expected. In other words, if
1102   the server is reading the protocol stream at the beginning of a
1103   message and receives a CRLF first, it should ignore the CRLF.
1104</t>
1105<t>
1106   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
1107   after a POST request. To restate what is explicitly forbidden by the
1108   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
1109   extra CRLF.
1110</t>
1111</section>
1112
1113<section title="Message Headers" anchor="message.headers">
1114 
1115 
1116 
1117 
1118<t>
1119   HTTP header fields, which include general-header (<xref target="general.header.fields"/>),
1120   request-header (Section 4 of <xref target="Part2"/>), response-header (Section 6 of <xref target="Part2"/>), and
1121   entity-header (Section 4.1 of <xref target="Part3"/>) fields, follow the same generic format as
1122   that given in Section 2.1 of <xref target="RFC5322"/>. Each header field consists
1123   of a name followed by a colon (":") and the field value. Field names
1124   are case-insensitive. The field value MAY be preceded by any amount
1125   of LWS, though a single SP is preferred. Header fields can be
1126   extended over multiple lines by preceding each extra line with at
1127   least one SP or HTAB. Applications ought to follow "common form", where
1128   one is known or indicated, when generating HTTP constructs, since
1129   there might exist some implementations that fail to accept anything
1130   beyond the common forms.
1131</t>
1132<figure><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/><artwork type="abnf2616"><![CDATA[
1133  message-header = field-name ":" [ field-value ]
1134  field-name     = token
1135  field-value    = *( field-content / OWS )
1136  field-content  = <field content>
1137]]></artwork></figure>
1138<t>
1139  <cref>whitespace between field-name and colon is an error and MUST NOT be accepted</cref>
1140</t>
1141<t>
1142   The field-content does not include any leading or trailing LWS:
1143   linear white space occurring before the first non-whitespace
1144   character of the field-value or after the last non-whitespace
1145   character of the field-value. Such leading or trailing LWS MAY be
1146   removed without changing the semantics of the field value. Any LWS
1147   that occurs between field-content MAY be replaced with a single SP
1148   before interpreting the field value or forwarding the message
1149   downstream.
1150</t>
1151<t>
1152   The order in which header fields with differing field names are
1153   received is not significant. However, it is "good practice" to send
1154   general-header fields first, followed by request-header or response-header
1155   fields, and ending with the entity-header fields.
1156</t>
1157<t>
1158   Multiple message-header fields with the same field-name MAY be
1159   present in a message if and only if the entire field-value for that
1160   header field is defined as a comma-separated list [i.e., #(values)].
1161   It MUST be possible to combine the multiple header fields into one
1162   "field-name: field-value" pair, without changing the semantics of the
1163   message, by appending each subsequent field-value to the first, each
1164   separated by a comma. The order in which header fields with the same
1165   field-name are received is therefore significant to the
1166   interpretation of the combined field value, and thus a proxy MUST NOT
1167   change the order of these field values when a message is forwarded.
1168</t>
1169<t>
1170  <list><t>
1171   Note: the "Set-Cookie" header as implemented in
1172   practice (as opposed to how it is specified in <xref target="RFC2109"/>)
1173   can occur multiple times, but does not use the list syntax, and thus cannot
1174   be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/>
1175   for details.) Also note that the Set-Cookie2 header specified in
1176   <xref target="RFC2965"/> does not share this problem.
1177  </t></list>
1178</t>
1179 
1180</section>
1181
1182<section title="Message Body" anchor="message.body">
1183 
1184<t>
1185   The message-body (if any) of an HTTP message is used to carry the
1186   entity-body associated with the request or response. The message-body
1187   differs from the entity-body only when a transfer-coding has been
1188   applied, as indicated by the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
1189</t>
1190<figure><iref primary="true" item="Grammar" subitem="message-body"/><artwork type="abnf2616"><![CDATA[
1191  message-body = entity-body
1192               / <entity-body encoded as per Transfer-Encoding>
1193]]></artwork></figure>
1194<t>
1195   Transfer-Encoding MUST be used to indicate any transfer-codings
1196   applied by an application to ensure safe and proper transfer of the
1197   message. Transfer-Encoding is a property of the message, not of the
1198   entity, and thus MAY be added or removed by any application along the
1199   request/response chain. (However, <xref target="transfer.codings"/> places restrictions on
1200   when certain transfer-codings may be used.)
1201</t>
1202<t>
1203   The rules for when a message-body is allowed in a message differ for
1204   requests and responses.
1205</t>
1206<t>
1207   The presence of a message-body in a request is signaled by the
1208   inclusion of a Content-Length or Transfer-Encoding header field in
1209   the request's message-headers. A message-body MUST NOT be included in
1210   a request if the specification of the request method (Section 3 of <xref target="Part2"/>)
1211   explicitly disallows an entity-body in requests.
1212   When a request message contains both a message-body of non-zero
1213   length and a method that does not define any semantics for that
1214   request message-body, then an origin server SHOULD either ignore
1215   the message-body or respond with an appropriate error message
1216   (e.g., 413).  A proxy or gateway, when presented the same request,
1217   SHOULD either forward the request inbound with the message-body or
1218   ignore the message-body when determining a response.
1219</t>
1220<t>
1221   For response messages, whether or not a message-body is included with
1222   a message is dependent on both the request method and the response
1223   status code (<xref target="status.code.and.reason.phrase"/>). All responses to the HEAD request method
1224   MUST NOT include a message-body, even though the presence of entity-header
1225   fields might lead one to believe they do. All 1xx
1226   (informational), 204 (No Content), and 304 (Not Modified) responses
1227   MUST NOT include a message-body. All other responses do include a
1228   message-body, although it MAY be of zero length.
1229</t>
1230</section>
1231
1232<section title="Message Length" anchor="message.length">
1233<t>
1234   The transfer-length of a message is the length of the message-body as
1235   it appears in the message; that is, after any transfer-codings have
1236   been applied. When a message-body is included with a message, the
1237   transfer-length of that body is determined by one of the following
1238   (in order of precedence):
1239</t>
1240<t>
1241  <list style="numbers">
1242    <t>
1243     Any response message which "MUST NOT" include a message-body (such
1244     as the 1xx, 204, and 304 responses and any response to a HEAD
1245     request) is always terminated by the first empty line after the
1246     header fields, regardless of the entity-header fields present in
1247     the message.
1248    </t>
1249    <t>
1250     If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>)
1251     is present and the "chunked" transfer-coding (<xref target="transfer.codings"/>)
1252     is used, the transfer-length is defined by the use of this transfer-coding.
1253     If a Transfer-Encoding header field is present and the "chunked" transfer-coding
1254     is not present, the transfer-length is defined by the sender closing the connection.
1255    </t>
1256    <t>
1257     If a Content-Length header field (<xref target="header.content-length"/>) is present, its
1258     decimal value in OCTETs represents both the entity-length and the
1259     transfer-length. The Content-Length header field MUST NOT be sent
1260     if these two lengths are different (i.e., if a Transfer-Encoding
1261     header field is present). If a message is received with both a
1262     Transfer-Encoding header field and a Content-Length header field,
1263     the latter MUST be ignored.
1264    </t>
1265    <t>
1266     If the message uses the media type "multipart/byteranges", and the
1267     transfer-length is not otherwise specified, then this self-delimiting
1268     media type defines the transfer-length. This media type
1269     MUST NOT be used unless the sender knows that the recipient can parse
1270     it; the presence in a request of a Range header with multiple byte-range
1271     specifiers from a 1.1 client implies that the client can parse
1272     multipart/byteranges responses.
1273    <list style="empty"><t>
1274       A range header might be forwarded by a 1.0 proxy that does not
1275       understand multipart/byteranges; in this case the server MUST
1276       delimit the message using methods defined in items 1, 3 or 5 of
1277       this section.
1278    </t></list>
1279    </t>
1280    <t>
1281     By the server closing the connection. (Closing the connection
1282     cannot be used to indicate the end of a request body, since that
1283     would leave no possibility for the server to send back a response.)
1284    </t>
1285  </list>
1286</t>
1287<t>
1288   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1289   containing a message-body MUST include a valid Content-Length header
1290   field unless the server is known to be HTTP/1.1 compliant. If a
1291   request contains a message-body and a Content-Length is not given,
1292   the server SHOULD respond with 400 (Bad Request) if it cannot
1293   determine the length of the message, or with 411 (Length Required) if
1294   it wishes to insist on receiving a valid Content-Length.
1295</t>
1296<t>
1297   All HTTP/1.1 applications that receive entities MUST accept the
1298   "chunked" transfer-coding (<xref target="transfer.codings"/>), thus allowing this mechanism
1299   to be used for messages when the message length cannot be determined
1300   in advance.
1301</t>
1302<t>
1303   Messages MUST NOT include both a Content-Length header field and a
1304   transfer-coding. If the message does include a
1305   transfer-coding, the Content-Length MUST be ignored.
1306</t>
1307<t>
1308   When a Content-Length is given in a message where a message-body is
1309   allowed, its field value MUST exactly match the number of OCTETs in
1310   the message-body. HTTP/1.1 user agents MUST notify the user when an
1311   invalid length is received and detected.
1312</t>
1313</section>
1314
1315<section title="General Header Fields" anchor="general.header.fields">
1316 
1317<t>
1318   There are a few header fields which have general applicability for
1319   both request and response messages, but which do not apply to the
1320   entity being transferred. These header fields apply only to the
1321   message being transmitted.
1322</t>
1323<figure><iref primary="true" item="Grammar" subitem="general-header"/><artwork type="abnf2616"><![CDATA[
1324  general-header = Cache-Control            ; [Part6], Section 16.2
1325                 / Connection               ; Section 8.1
1326                 / Date                     ; Section 8.3
1327                 / Pragma                   ; [Part6], Section 16.4
1328                 / Trailer                  ; Section 8.6
1329                 / Transfer-Encoding        ; Section 8.7
1330                 / Upgrade                  ; Section 8.8
1331                 / Via                      ; Section 8.9
1332                 / Warning                  ; [Part6], Section 16.6
1333]]></artwork></figure>
1334<t>
1335   General-header field names can be extended reliably only in
1336   combination with a change in the protocol version. However, new or
1337   experimental header fields may be given the semantics of general
1338   header fields if all parties in the communication recognize them to
1339   be general-header fields. Unrecognized header fields are treated as
1340   entity-header fields.
1341</t>
1342</section>
1343</section>
1344
1345<section title="Request" anchor="request">
1346 
1347<t>
1348   A request message from a client to a server includes, within the
1349   first line of that message, the method to be applied to the resource,
1350   the identifier of the resource, and the protocol version in use.
1351</t>
1352<!--                 Host                      ; should be moved here eventually -->
1353<figure><iref primary="true" item="Grammar" subitem="Request"/><artwork type="abnf2616"><![CDATA[
1354  Request       = Request-Line              ; Section 5.1
1355                  *(( general-header        ; Section 4.5
1356                   / request-header         ; [Part2], Section 4
1357                   / entity-header ) CRLF)  ; [Part3], Section 4.1
1358                  CRLF
1359                  [ message-body ]          ; Section 4.3
1360]]></artwork></figure>
1361
1362<section title="Request-Line" anchor="request-line">
1363 
1364<t>
1365   The Request-Line begins with a method token, followed by the
1366   Request-URI and the protocol version, and ending with CRLF. The
1367   elements are separated by SP characters. No CR or LF is allowed
1368   except in the final CRLF sequence.
1369</t>
1370<figure><iref primary="true" item="Grammar" subitem="Request-Line"/><artwork type="abnf2616"><![CDATA[
1371  Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
1372]]></artwork></figure>
1373
1374<section title="Method" anchor="method">
1375 
1376<t>
1377   The Method  token indicates the method to be performed on the
1378   resource identified by the Request-URI. The method is case-sensitive.
1379</t>
1380<figure><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/><artwork type="abnf2616"><![CDATA[
1381  Method         = token
1382]]></artwork></figure>
1383</section>
1384
1385<section title="Request-URI" anchor="request-uri">
1386 
1387<t>
1388   The Request-URI is a Uniform Resource Identifier (<xref target="uri"/>) and
1389   identifies the resource upon which to apply the request.
1390</t>
1391<figure><iref primary="true" item="Grammar" subitem="Request-URI"/><artwork type="abnf2616"><![CDATA[
1392  Request-URI    = "*"
1393                 / absolute-URI
1394                 / ( path-absolute [ "?" query ] )
1395                 / authority
1396]]></artwork></figure>
1397<t>
1398   The four options for Request-URI are dependent on the nature of the
1399   request. The asterisk "*" means that the request does not apply to a
1400   particular resource, but to the server itself, and is only allowed
1401   when the method used does not necessarily apply to a resource. One
1402   example would be
1403</t>
1404<figure><artwork type="example"><![CDATA[
1405    OPTIONS * HTTP/1.1
1406]]></artwork></figure>
1407<t>
1408   The absolute-URI form is REQUIRED when the request is being made to a
1409   proxy. The proxy is requested to forward the request or service it
1410   from a valid cache, and return the response. Note that the proxy MAY
1411   forward the request on to another proxy or directly to the server
1412   specified by the absolute-URI. In order to avoid request loops, a
1413   proxy MUST be able to recognize all of its server names, including
1414   any aliases, local variations, and the numeric IP address. An example
1415   Request-Line would be:
1416</t>
1417<figure><artwork type="example"><![CDATA[
1418    GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
1419]]></artwork></figure>
1420<t>
1421   To allow for transition to absolute-URIs in all requests in future
1422   versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
1423   form in requests, even though HTTP/1.1 clients will only generate
1424   them in requests to proxies.
1425</t>
1426<t>
1427   The authority form is only used by the CONNECT method (Section 8.9 of <xref target="Part2"/>).
1428</t>
1429<t>
1430   The most common form of Request-URI is that used to identify a
1431   resource on an origin server or gateway. In this case the absolute
1432   path of the URI MUST be transmitted (see <xref target="http.uri"/>, path-absolute) as
1433   the Request-URI, and the network location of the URI (authority) MUST
1434   be transmitted in a Host header field. For example, a client wishing
1435   to retrieve the resource above directly from the origin server would
1436   create a TCP connection to port 80 of the host "www.example.org" and send
1437   the lines:
1438</t>
1439<figure><artwork type="example"><![CDATA[
1440    GET /pub/WWW/TheProject.html HTTP/1.1
1441    Host: www.example.org
1442]]></artwork></figure>
1443<t>
1444   followed by the remainder of the Request. Note that the absolute path
1445   cannot be empty; if none is present in the original URI, it MUST be
1446   given as "/" (the server root).
1447</t>
1448<t>
1449   The Request-URI is transmitted in the format specified in
1450   <xref target="http.uri"/>. If the Request-URI is encoded using the
1451   "% <xref target="core.rules" format="none">HEXDIG</xref> <xref target="core.rules" format="none">HEXDIG</xref>" encoding
1452   (<xref target="RFC3986"/>, Section 2.4), the origin server
1453   MUST decode the Request-URI in order to
1454   properly interpret the request. Servers SHOULD respond to invalid
1455   Request-URIs with an appropriate status code.
1456</t>
1457<t>
1458   A transparent proxy MUST NOT rewrite the "path-absolute" part of the
1459   received Request-URI when forwarding it to the next inbound server,
1460   except as noted above to replace a null path-absolute with "/".
1461</t>
1462<t>
1463  <list><t>
1464      Note: The "no rewrite" rule prevents the proxy from changing the
1465      meaning of the request when the origin server is improperly using
1466      a non-reserved URI character for a reserved purpose.  Implementors
1467      should be aware that some pre-HTTP/1.1 proxies have been known to
1468      rewrite the Request-URI.
1469  </t></list>
1470</t>
1471</section>
1472</section>
1473
1474<section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
1475<t>
1476   The exact resource identified by an Internet request is determined by
1477   examining both the Request-URI and the Host header field.
1478</t>
1479<t>
1480   An origin server that does not allow resources to differ by the
1481   requested host MAY ignore the Host header field value when
1482   determining the resource identified by an HTTP/1.1 request. (But see
1483   <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/>
1484   for other requirements on Host support in HTTP/1.1.)
1485</t>
1486<t>
1487   An origin server that does differentiate resources based on the host
1488   requested (sometimes referred to as virtual hosts or vanity host
1489   names) MUST use the following rules for determining the requested
1490   resource on an HTTP/1.1 request:
1491  <list style="numbers">
1492    <t>If Request-URI is an absolute-URI, the host is part of the
1493     Request-URI. Any Host header field value in the request MUST be
1494     ignored.</t>
1495    <t>If the Request-URI is not an absolute-URI, and the request includes
1496     a Host header field, the host is determined by the Host header
1497     field value.</t>
1498    <t>If the host as determined by rule 1 or 2 is not a valid host on
1499     the server, the response MUST be a 400 (Bad Request) error message.</t>
1500  </list>
1501</t>
1502<t>
1503   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
1504   attempt to use heuristics (e.g., examination of the URI path for
1505   something unique to a particular host) in order to determine what
1506   exact resource is being requested.
1507</t>
1508</section>
1509
1510</section>
1511
1512
1513<section title="Response" anchor="response">
1514 
1515<t>
1516   After receiving and interpreting a request message, a server responds
1517   with an HTTP response message.
1518</t>
1519<figure><iref primary="true" item="Grammar" subitem="Response"/><artwork type="abnf2616"><![CDATA[
1520  Response      = Status-Line               ; Section 6.1
1521                  *(( general-header        ; Section 4.5
1522                   / response-header        ; [Part2], Section 6
1523                   / entity-header ) CRLF)  ; [Part3], Section 4.1
1524                  CRLF
1525                  [ message-body ]          ; Section 4.3
1526]]></artwork></figure>
1527
1528<section title="Status-Line" anchor="status-line">
1529 
1530<t>
1531   The first line of a Response message is the Status-Line, consisting
1532   of the protocol version followed by a numeric status code and its
1533   associated textual phrase, with each element separated by SP
1534   characters. No CR or LF is allowed except in the final CRLF sequence.
1535</t>
1536<figure><iref primary="true" item="Grammar" subitem="Status-Line"/><artwork type="abnf2616"><![CDATA[
1537  Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1538]]></artwork></figure>
1539
1540<section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase">
1541 
1542 
1543<t>
1544   The Status-Code element is a 3-digit integer result code of the
1545   attempt to understand and satisfy the request. These codes are fully
1546   defined in Section 9 of <xref target="Part2"/>.  The Reason Phrase exists for the sole
1547   purpose of providing a textual description associated with the numeric
1548   status code, out of deference to earlier Internet application protocols
1549   that were more frequently used with interactive text clients.
1550   A client SHOULD ignore the content of the Reason Phrase.
1551</t>
1552<t>
1553   The first digit of the Status-Code defines the class of response. The
1554   last two digits do not have any categorization role. There are 5
1555   values for the first digit:
1556  <list style="symbols">
1557    <t>
1558      1xx: Informational - Request received, continuing process
1559    </t>
1560    <t>
1561      2xx: Success - The action was successfully received,
1562        understood, and accepted
1563    </t>
1564    <t>
1565      3xx: Redirection - Further action must be taken in order to
1566        complete the request
1567    </t>
1568    <t>
1569      4xx: Client Error - The request contains bad syntax or cannot
1570        be fulfilled
1571    </t>
1572    <t>
1573      5xx: Server Error - The server failed to fulfill an apparently
1574        valid request
1575    </t>
1576  </list>
1577</t>
1578<figure><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/><artwork type="abnf2616"><![CDATA[
1579  Status-Code    = 3DIGIT
1580  Reason-Phrase  = *<TEXT, excluding CR, LF>
1581]]></artwork></figure>
1582</section>
1583</section>
1584
1585</section>
1586
1587
1588<section title="Connections" anchor="connections">
1589
1590<section title="Persistent Connections" anchor="persistent.connections">
1591
1592<section title="Purpose" anchor="persistent.purpose">
1593<t>
1594   Prior to persistent connections, a separate TCP connection was
1595   established to fetch each URL, increasing the load on HTTP servers
1596   and causing congestion on the Internet. The use of inline images and
1597   other associated data often require a client to make multiple
1598   requests of the same server in a short amount of time. Analysis of
1599   these performance problems and results from a prototype
1600   implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and
1601   measurements of actual HTTP/1.1 (RFC 2068) implementations show good
1602   results <xref target="Nie1997"/>. Alternatives have also been explored, for example,
1603   T/TCP <xref target="Tou1998"/>.
1604</t>
1605<t>
1606   Persistent HTTP connections have a number of advantages:
1607  <list style="symbols">
1608      <t>
1609        By opening and closing fewer TCP connections, CPU time is saved
1610        in routers and hosts (clients, servers, proxies, gateways,
1611        tunnels, or caches), and memory used for TCP protocol control
1612        blocks can be saved in hosts.
1613      </t>
1614      <t>
1615        HTTP requests and responses can be pipelined on a connection.
1616        Pipelining allows a client to make multiple requests without
1617        waiting for each response, allowing a single TCP connection to
1618        be used much more efficiently, with much lower elapsed time.
1619      </t>
1620      <t>
1621        Network congestion is reduced by reducing the number of packets
1622        caused by TCP opens, and by allowing TCP sufficient time to
1623        determine the congestion state of the network.
1624      </t>
1625      <t>
1626        Latency on subsequent requests is reduced since there is no time
1627        spent in TCP's connection opening handshake.
1628      </t>
1629      <t>
1630        HTTP can evolve more gracefully, since errors can be reported
1631        without the penalty of closing the TCP connection. Clients using
1632        future versions of HTTP might optimistically try a new feature,
1633        but if communicating with an older server, retry with old
1634        semantics after an error is reported.
1635      </t>
1636    </list>
1637</t>
1638<t>
1639   HTTP implementations SHOULD implement persistent connections.
1640</t>
1641</section>
1642
1643<section title="Overall Operation" anchor="persistent.overall">
1644<t>
1645   A significant difference between HTTP/1.1 and earlier versions of
1646   HTTP is that persistent connections are the default behavior of any
1647   HTTP connection. That is, unless otherwise indicated, the client
1648   SHOULD assume that the server will maintain a persistent connection,
1649   even after error responses from the server.
1650</t>
1651<t>
1652   Persistent connections provide a mechanism by which a client and a
1653   server can signal the close of a TCP connection. This signaling takes
1654   place using the Connection header field (<xref target="header.connection"/>). Once a close
1655   has been signaled, the client MUST NOT send any more requests on that
1656   connection.
1657</t>
1658
1659<section title="Negotiation" anchor="persistent.negotiation">
1660<t>
1661   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
1662   maintain a persistent connection unless a Connection header including
1663   the connection-token "close" was sent in the request. If the server
1664   chooses to close the connection immediately after sending the
1665   response, it SHOULD send a Connection header including the
1666   connection-token close.
1667</t>
1668<t>
1669   An HTTP/1.1 client MAY expect a connection to remain open, but would
1670   decide to keep it open based on whether the response from a server
1671   contains a Connection header with the connection-token close. In case
1672   the client does not want to maintain a connection for more than that
1673   request, it SHOULD send a Connection header including the
1674   connection-token close.
1675</t>
1676<t>
1677   If either the client or the server sends the close token in the
1678   Connection header, that request becomes the last one for the
1679   connection.
1680</t>
1681<t>
1682   Clients and servers SHOULD NOT  assume that a persistent connection is
1683   maintained for HTTP versions less than 1.1 unless it is explicitly
1684   signaled. See <xref target="compatibility.with.http.1.0.persistent.connections"/> for more information on backward
1685   compatibility with HTTP/1.0 clients.
1686</t>
1687<t>
1688   In order to remain persistent, all messages on the connection MUST
1689   have a self-defined message length (i.e., one not defined by closure
1690   of the connection), as described in <xref target="message.length"/>.
1691</t>
1692</section>
1693
1694<section title="Pipelining" anchor="pipelining">
1695<t>
1696   A client that supports persistent connections MAY "pipeline" its
1697   requests (i.e., send multiple requests without waiting for each
1698   response). A server MUST send its responses to those requests in the
1699   same order that the requests were received.
1700</t>
1701<t>
1702   Clients which assume persistent connections and pipeline immediately
1703   after connection establishment SHOULD be prepared to retry their
1704   connection if the first pipelined attempt fails. If a client does
1705   such a retry, it MUST NOT pipeline before it knows the connection is
1706   persistent. Clients MUST also be prepared to resend their requests if
1707   the server closes the connection before sending all of the
1708   corresponding responses.
1709</t>
1710<t>
1711   Clients SHOULD NOT  pipeline requests using non-idempotent methods or
1712   non-idempotent sequences of methods (see Section 8.1.2 of <xref target="Part2"/>). Otherwise, a
1713   premature termination of the transport connection could lead to
1714   indeterminate results. A client wishing to send a non-idempotent
1715   request SHOULD wait to send that request until it has received the
1716   response status for the previous request.
1717</t>
1718</section>
1719</section>
1720
1721<section title="Proxy Servers" anchor="persistent.proxy">
1722<t>
1723   It is especially important that proxies correctly implement the
1724   properties of the Connection header field as specified in <xref target="header.connection"/>.
1725</t>
1726<t>
1727   The proxy server MUST signal persistent connections separately with
1728   its clients and the origin servers (or other proxy servers) that it
1729   connects to. Each persistent connection applies to only one transport
1730   link.
1731</t>
1732<t>
1733   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
1734   with an HTTP/1.0 client (but see <xref target="RFC2068"/> for information and
1735   discussion of the problems with the Keep-Alive header implemented by
1736   many HTTP/1.0 clients).
1737</t>
1738</section>
1739
1740<section title="Practical Considerations" anchor="persistent.practical">
1741<t>
1742   Servers will usually have some time-out value beyond which they will
1743   no longer maintain an inactive connection. Proxy servers might make
1744   this a higher value since it is likely that the client will be making
1745   more connections through the same server. The use of persistent
1746   connections places no requirements on the length (or existence) of
1747   this time-out for either the client or the server.
1748</t>
1749<t>
1750   When a client or server wishes to time-out it SHOULD issue a graceful
1751   close on the transport connection. Clients and servers SHOULD both
1752   constantly watch for the other side of the transport close, and
1753   respond to it as appropriate. If a client or server does not detect
1754   the other side's close promptly it could cause unnecessary resource
1755   drain on the network.
1756</t>
1757<t>
1758   A client, server, or proxy MAY close the transport connection at any
1759   time. For example, a client might have started to send a new request
1760   at the same time that the server has decided to close the "idle"
1761   connection. From the server's point of view, the connection is being
1762   closed while it was idle, but from the client's point of view, a
1763   request is in progress.
1764</t>
1765<t>
1766   This means that clients, servers, and proxies MUST be able to recover
1767   from asynchronous close events. Client software SHOULD reopen the
1768   transport connection and retransmit the aborted sequence of requests
1769   without user interaction so long as the request sequence is
1770   idempotent (see Section 8.1.2 of <xref target="Part2"/>). Non-idempotent methods or sequences
1771   MUST NOT be automatically retried, although user agents MAY offer a
1772   human operator the choice of retrying the request(s). Confirmation by
1773   user-agent software with semantic understanding of the application
1774   MAY substitute for user confirmation. The automatic retry SHOULD NOT
1775   be repeated if the second sequence of requests fails.
1776</t>
1777<t>
1778   Servers SHOULD always respond to at least one request per connection,
1779   if at all possible. Servers SHOULD NOT  close a connection in the
1780   middle of transmitting a response, unless a network or client failure
1781   is suspected.
1782</t>
1783<t>
1784   Clients that use persistent connections SHOULD limit the number of
1785   simultaneous connections that they maintain to a given server. A
1786   single-user client SHOULD NOT maintain more than 2 connections with
1787   any server or proxy. A proxy SHOULD use up to 2*N connections to
1788   another server or proxy, where N is the number of simultaneously
1789   active users. These guidelines are intended to improve HTTP response
1790   times and avoid congestion.
1791</t>
1792</section>
1793</section>
1794
1795<section title="Message Transmission Requirements" anchor="message.transmission.requirements">
1796
1797<section title="Persistent Connections and Flow Control" anchor="persistent.flow">
1798<t>
1799   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
1800   flow control mechanisms to resolve temporary overloads, rather than
1801   terminating connections with the expectation that clients will retry.
1802   The latter technique can exacerbate network congestion.
1803</t>
1804</section>
1805
1806<section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">
1807<t>
1808   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
1809   the network connection for an error status while it is transmitting
1810   the request. If the client sees an error status, it SHOULD
1811   immediately cease transmitting the body. If the body is being sent
1812   using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
1813   empty trailer MAY be used to prematurely mark the end of the message.
1814   If the body was preceded by a Content-Length header, the client MUST
1815   close the connection.
1816</t>
1817</section>
1818
1819<section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
1820<t>
1821   The purpose of the 100 (Continue) status (see Section 9.1.1 of <xref target="Part2"/>) is to
1822   allow a client that is sending a request message with a request body
1823   to determine if the origin server is willing to accept the request
1824   (based on the request headers) before the client sends the request
1825   body. In some cases, it might either be inappropriate or highly
1826   inefficient for the client to send the body if the server will reject
1827   the message without looking at the body.
1828</t>
1829<t>
1830   Requirements for HTTP/1.1 clients:
1831  <list style="symbols">
1832    <t>
1833        If a client will wait for a 100 (Continue) response before
1834        sending the request body, it MUST send an Expect request-header
1835        field (Section 10.2 of <xref target="Part2"/>) with the "100-continue" expectation.
1836    </t>
1837    <t>
1838        A client MUST NOT send an Expect request-header field (Section 10.2 of <xref target="Part2"/>)
1839        with the "100-continue" expectation if it does not intend
1840        to send a request body.
1841    </t>
1842  </list>
1843</t>
1844<t>
1845   Because of the presence of older implementations, the protocol allows
1846   ambiguous situations in which a client may send "Expect: 100-continue"
1847   without receiving either a 417 (Expectation Failed) status
1848   or a 100 (Continue) status. Therefore, when a client sends this
1849   header field to an origin server (possibly via a proxy) from which it
1850   has never seen a 100 (Continue) status, the client SHOULD NOT  wait
1851   for an indefinite period before sending the request body.
1852</t>
1853<t>
1854   Requirements for HTTP/1.1 origin servers:
1855  <list style="symbols">
1856    <t> Upon receiving a request which includes an Expect request-header
1857        field with the "100-continue" expectation, an origin server MUST
1858        either respond with 100 (Continue) status and continue to read
1859        from the input stream, or respond with a final status code. The
1860        origin server MUST NOT wait for the request body before sending
1861        the 100 (Continue) response. If it responds with a final status
1862        code, it MAY close the transport connection or it MAY continue
1863        to read and discard the rest of the request.  It MUST NOT
1864        perform the requested method if it returns a final status code.
1865    </t>
1866    <t> An origin server SHOULD NOT  send a 100 (Continue) response if
1867        the request message does not include an Expect request-header
1868        field with the "100-continue" expectation, and MUST NOT send a
1869        100 (Continue) response if such a request comes from an HTTP/1.0
1870        (or earlier) client. There is an exception to this rule: for
1871        compatibility with <xref target="RFC2068"/>, a server MAY send a 100 (Continue)
1872        status in response to an HTTP/1.1 PUT or POST request that does
1873        not include an Expect request-header field with the "100-continue"
1874        expectation. This exception, the purpose of which is
1875        to minimize any client processing delays associated with an
1876        undeclared wait for 100 (Continue) status, applies only to
1877        HTTP/1.1 requests, and not to requests with any other HTTP-version
1878        value.
1879    </t>
1880    <t> An origin server MAY omit a 100 (Continue) response if it has
1881        already received some or all of the request body for the
1882        corresponding request.
1883    </t>
1884    <t> An origin server that sends a 100 (Continue) response MUST
1885    ultimately send a final status code, once the request body is
1886        received and processed, unless it terminates the transport
1887        connection prematurely.
1888    </t>
1889    <t> If an origin server receives a request that does not include an
1890        Expect request-header field with the "100-continue" expectation,
1891        the request includes a request body, and the server responds
1892        with a final status code before reading the entire request body
1893        from the transport connection, then the server SHOULD NOT  close
1894        the transport connection until it has read the entire request,
1895        or until the client closes the connection. Otherwise, the client
1896        might not reliably receive the response message. However, this
1897        requirement is not be construed as preventing a server from
1898        defending itself against denial-of-service attacks, or from
1899        badly broken client implementations.
1900      </t>
1901    </list>
1902</t>
1903<t>
1904   Requirements for HTTP/1.1 proxies:
1905  <list style="symbols">
1906    <t> If a proxy receives a request that includes an Expect request-header
1907        field with the "100-continue" expectation, and the proxy
1908        either knows that the next-hop server complies with HTTP/1.1 or
1909        higher, or does not know the HTTP version of the next-hop
1910        server, it MUST forward the request, including the Expect header
1911        field.
1912    </t>
1913    <t> If the proxy knows that the version of the next-hop server is
1914        HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
1915        respond with a 417 (Expectation Failed) status.
1916    </t>
1917    <t> Proxies SHOULD maintain a cache recording the HTTP version
1918        numbers received from recently-referenced next-hop servers.
1919    </t>
1920    <t> A proxy MUST NOT forward a 100 (Continue) response if the
1921        request message was received from an HTTP/1.0 (or earlier)
1922        client and did not include an Expect request-header field with
1923        the "100-continue" expectation. This requirement overrides the
1924        general rule for forwarding of 1xx responses (see Section 9.1 of <xref target="Part2"/>).
1925    </t>
1926  </list>
1927</t>
1928</section>
1929
1930<section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature">
1931<t>
1932   If an HTTP/1.1 client sends a request which includes a request body,
1933   but which does not include an Expect request-header field with the
1934   "100-continue" expectation, and if the client is not directly
1935   connected to an HTTP/1.1 origin server, and if the client sees the
1936   connection close before receiving any status from the server, the
1937   client SHOULD retry the request.  If the client does retry this
1938   request, it MAY use the following "binary exponential backoff"
1939   algorithm to be assured of obtaining a reliable response:
1940  <list style="numbers">
1941    <t>
1942      Initiate a new connection to the server
1943    </t>
1944    <t>
1945      Transmit the request-headers
1946    </t>
1947    <t>
1948      Initialize a variable R to the estimated round-trip time to the
1949         server (e.g., based on the time it took to establish the
1950         connection), or to a constant value of 5 seconds if the round-trip
1951         time is not available.
1952    </t>
1953    <t>
1954       Compute T = R * (2**N), where N is the number of previous
1955         retries of this request.
1956    </t>
1957    <t>
1958       Wait either for an error response from the server, or for T
1959         seconds (whichever comes first)
1960    </t>
1961    <t>
1962       If no error response is received, after T seconds transmit the
1963         body of the request.
1964    </t>
1965    <t>
1966       If client sees that the connection is closed prematurely,
1967         repeat from step 1 until the request is accepted, an error
1968         response is received, or the user becomes impatient and
1969         terminates the retry process.
1970    </t>
1971  </list>
1972</t>
1973<t>
1974   If at any point an error status is received, the client
1975  <list style="symbols">
1976      <t>SHOULD NOT  continue and</t>
1977
1978      <t>SHOULD close the connection if it has not completed sending the
1979        request message.</t>
1980    </list>
1981</t>
1982</section>
1983</section>
1984</section>
1985
1986
1987<section title="Header Field Definitions" anchor="header.fields">
1988<t>
1989   This section defines the syntax and semantics of HTTP/1.1 header fields
1990   related to message framing and transport protocols.
1991</t>
1992<t>
1993   For entity-header fields, both sender and recipient refer to either the
1994   client or the server, depending on who sends and who receives the entity.
1995</t>
1996
1997<section title="Connection" anchor="header.connection">
1998  <iref primary="true" item="Connection header"/>
1999  <iref primary="true" item="Headers" subitem="Connection"/>
2000 
2001 
2002 
2003<t>
2004   The general-header field "Connection" allows the sender to specify
2005   options that are desired for that particular connection and MUST NOT
2006   be communicated by proxies over further connections.
2007</t>
2008<t>
2009   The Connection header's value has the following grammar:
2010</t>
2011<figure><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="Connection-v"/><iref primary="true" item="Grammar" subitem="connection-token"/><artwork type="abnf2616"><![CDATA[
2012  Connection       = "Connection" ":" OWS Connection-v
2013  Connection-v     = 1#connection-token
2014  connection-token = token
2015]]></artwork></figure>
2016<t>
2017   HTTP/1.1 proxies MUST parse the Connection header field before a
2018   message is forwarded and, for each connection-token in this field,
2019   remove any header field(s) from the message with the same name as the
2020   connection-token. Connection options are signaled by the presence of
2021   a connection-token in the Connection header field, not by any
2022   corresponding additional header field(s), since the additional header
2023   field may not be sent if there are no parameters associated with that
2024   connection option.
2025</t>
2026<t>
2027   Message headers listed in the Connection header MUST NOT include
2028   end-to-end headers, such as Cache-Control.
2029</t>
2030<t>
2031   HTTP/1.1 defines the "close" connection option for the sender to
2032   signal that the connection will be closed after completion of the
2033   response. For example,
2034</t>
2035<figure><artwork type="example"><![CDATA[
2036  Connection: close
2037]]></artwork></figure>
2038<t>
2039   in either the request or the response header fields indicates that
2040   the connection SHOULD NOT  be considered `persistent' (<xref target="persistent.connections"/>)
2041   after the current request/response is complete.
2042</t>
2043<t>
2044   An HTTP/1.1 client that does not support persistent connections MUST
2045   include the "close" connection option in every request message.
2046</t>
2047<t>
2048   An HTTP/1.1 server that does not support persistent connections MUST
2049   include the "close" connection option in every response message that
2050   does not have a 1xx (informational) status code.
2051</t>
2052<t>
2053   A system receiving an HTTP/1.0 (or lower-version) message that
2054   includes a Connection header MUST, for each connection-token in this
2055   field, remove and ignore any header field(s) from the message with
2056   the same name as the connection-token. This protects against mistaken
2057   forwarding of such header fields by pre-HTTP/1.1 proxies. See <xref target="compatibility.with.http.1.0.persistent.connections"/>.
2058</t>
2059</section>
2060
2061<section title="Content-Length" anchor="header.content-length">
2062  <iref primary="true" item="Content-Length header"/>
2063  <iref primary="true" item="Headers" subitem="Content-Length"/>
2064 
2065 
2066<t>
2067   The entity-header field "Content-Length" indicates the size of the
2068   entity-body, in decimal number of OCTETs, sent to the recipient or,
2069   in the case of the HEAD method, the size of the entity-body that
2070   would have been sent had the request been a GET.
2071</t>
2072<figure><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/><artwork type="abnf2616"><![CDATA[
2073  Content-Length   = "Content-Length" ":" OWS 1*Content-Length-v
2074  Content-Length-v = 1*DIGIT
2075]]></artwork></figure>
2076<t>
2077   An example is
2078</t>
2079<figure><artwork type="example"><![CDATA[
2080  Content-Length: 3495
2081]]></artwork></figure>
2082<t>
2083   Applications SHOULD use this field to indicate the transfer-length of
2084   the message-body, unless this is prohibited by the rules in <xref target="message.length"/>.
2085</t>
2086<t>
2087   Any Content-Length greater than or equal to zero is a valid value.
2088   <xref target="message.length"/> describes how to determine the length of a message-body
2089   if a Content-Length is not given.
2090</t>
2091<t>
2092   Note that the meaning of this field is significantly different from
2093   the corresponding definition in MIME, where it is an optional field
2094   used within the "message/external-body" content-type. In HTTP, it
2095   SHOULD be sent whenever the message's length can be determined prior
2096   to being transferred, unless this is prohibited by the rules in
2097   <xref target="message.length"/>.
2098</t>
2099</section>
2100
2101<section title="Date" anchor="header.date">
2102  <iref primary="true" item="Date header"/>
2103  <iref primary="true" item="Headers" subitem="Date"/>
2104 
2105 
2106<t>
2107   The general-header field "Date" represents the date and time at which
2108   the message was originated, having the same semantics as orig-date in
2109   Section 3.6.1 of <xref target="RFC5322"/>. The field value is an
2110   HTTP-date, as described in <xref target="full.date"/>;
2111   it MUST be sent in rfc1123-date format.
2112</t>
2113<figure><iref primary="true" item="Grammar" subitem="Date"/><iref primary="true" item="Grammar" subitem="Date-v"/><artwork type="abnf2616"><![CDATA[
2114  Date   = "Date" ":" OWS Date-v
2115  Date-v = HTTP-date
2116]]></artwork></figure>
2117<t>
2118   An example is
2119</t>
2120<figure><artwork type="example"><![CDATA[
2121  Date: Tue, 15 Nov 1994 08:12:31 GMT
2122]]></artwork></figure>
2123<t>
2124   Origin servers MUST include a Date header field in all responses,
2125   except in these cases:
2126  <list style="numbers">
2127      <t>If the response status code is 100 (Continue) or 101 (Switching
2128         Protocols), the response MAY include a Date header field, at
2129         the server's option.</t>
2130
2131      <t>If the response status code conveys a server error, e.g. 500
2132         (Internal Server Error) or 503 (Service Unavailable), and it is
2133         inconvenient or impossible to generate a valid Date.</t>
2134
2135      <t>If the server does not have a clock that can provide a
2136         reasonable approximation of the current time, its responses
2137         MUST NOT include a Date header field. In this case, the rules
2138         in <xref target="clockless.origin.server.operation"/> MUST be followed.</t>
2139  </list>
2140</t>
2141<t>
2142   A received message that does not have a Date header field MUST be
2143   assigned one by the recipient if the message will be cached by that
2144   recipient or gatewayed via a protocol which requires a Date. An HTTP
2145   implementation without a clock MUST NOT cache responses without
2146   revalidating them on every use. An HTTP cache, especially a shared
2147   cache, SHOULD use a mechanism, such as NTP <xref target="RFC1305"/>, to synchronize its
2148   clock with a reliable external standard.
2149</t>
2150<t>
2151   Clients SHOULD only send a Date header field in messages that include
2152   an entity-body, as in the case of the PUT and POST requests, and even
2153   then it is optional. A client without a clock MUST NOT send a Date
2154   header field in a request.
2155</t>
2156<t>
2157   The HTTP-date sent in a Date header SHOULD NOT  represent a date and
2158   time subsequent to the generation of the message. It SHOULD represent
2159   the best available approximation of the date and time of message
2160   generation, unless the implementation has no means of generating a
2161   reasonably accurate date and time. In theory, the date ought to
2162   represent the moment just before the entity is generated. In
2163   practice, the date can be generated at any time during the message
2164   origination without affecting its semantic value.
2165</t>
2166
2167<section title="Clockless Origin Server Operation" anchor="clockless.origin.server.operation">
2168<t>
2169   Some origin server implementations might not have a clock available.
2170   An origin server without a clock MUST NOT assign Expires or Last-Modified
2171   values to a response, unless these values were associated
2172   with the resource by a system or user with a reliable clock. It MAY
2173   assign an Expires value that is known, at or before server
2174   configuration time, to be in the past (this allows "pre-expiration"
2175   of responses without storing separate Expires values for each
2176   resource).
2177</t>
2178</section>
2179</section>
2180
2181<section title="Host" anchor="header.host">
2182  <iref primary="true" item="Host header"/>
2183  <iref primary="true" item="Headers" subitem="Host"/>
2184 
2185 
2186<t>
2187   The request-header field "Host" specifies the Internet host and port
2188   number of the resource being requested, as obtained from the original
2189   URI given by the user or referring resource (generally an HTTP URL,
2190   as described in <xref target="http.uri"/>). The Host field value MUST represent
2191   the naming authority of the origin server or gateway given by the
2192   original URL. This allows the origin server or gateway to
2193   differentiate between internally-ambiguous URLs, such as the root "/"
2194   URL of a server for multiple host names on a single IP address.
2195</t>
2196<figure><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/><artwork type="abnf2616"><![CDATA[
2197  Host   = "Host" ":" OWS Host-v
2198  Host-v = uri-host [ ":" port ] ; Section 3.2.1
2199]]></artwork></figure>
2200<t>
2201   A "host" without any trailing port information implies the default
2202   port for the service requested (e.g., "80" for an HTTP URL). For
2203   example, a request on the origin server for
2204   &lt;http://www.example.org/pub/WWW/&gt; would properly include:
2205</t>
2206<figure><artwork type="example"><![CDATA[
2207  GET /pub/WWW/ HTTP/1.1
2208  Host: www.example.org
2209]]></artwork></figure>
2210<t>
2211   A client MUST include a Host header field in all HTTP/1.1 request
2212   messages. If the requested URI does not include an Internet host
2213   name for the service being requested, then the Host header field MUST
2214   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
2215   request message it forwards does contain an appropriate Host header
2216   field that identifies the service being requested by the proxy. All
2217   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
2218   status code to any HTTP/1.1 request message which lacks a Host header
2219   field.
2220</t>
2221<t>
2222   See Sections <xref target="the.resource.identified.by.a.request" format="counter"/>
2223   and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>
2224   for other requirements relating to Host.
2225</t>
2226</section>
2227
2228<section title="TE" anchor="header.te">
2229  <iref primary="true" item="TE header"/>
2230  <iref primary="true" item="Headers" subitem="TE"/>
2231 
2232 
2233 
2234<t>
2235   The request-header field "TE" indicates what extension transfer-codings
2236   it is willing to accept in the response and whether or not it is
2237   willing to accept trailer fields in a chunked transfer-coding. Its
2238   value may consist of the keyword "trailers" and/or a comma-separated
2239   list of extension transfer-coding names with optional accept
2240   parameters (as described in <xref target="transfer.codings"/>).
2241</t>
2242<figure><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="TE-v"/><iref primary="true" item="Grammar" subitem="t-codings"/><artwork type="abnf2616"><![CDATA[
2243  TE        = "TE" ":" OWS TE-v
2244  TE-v      = #t-codings
2245  t-codings = "trailers" / ( transfer-extension [ accept-params ] )
2246]]></artwork></figure>
2247<t>
2248   The presence of the keyword "trailers" indicates that the client is
2249   willing to accept trailer fields in a chunked transfer-coding, as
2250   defined in <xref target="chunked.transfer.encoding"/>. This keyword is reserved for use with
2251   transfer-coding values even though it does not itself represent a
2252   transfer-coding.
2253</t>
2254<t>
2255   Examples of its use are:
2256</t>
2257<figure><artwork type="example"><![CDATA[
2258  TE: deflate
2259  TE:
2260  TE: trailers, deflate;q=0.5
2261]]></artwork></figure>
2262<t>
2263   The TE header field only applies to the immediate connection.
2264   Therefore, the keyword MUST be supplied within a Connection header
2265   field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.
2266</t>
2267<t>
2268   A server tests whether a transfer-coding is acceptable, according to
2269   a TE field, using these rules:
2270  <list style="numbers">
2271    <t>The "chunked" transfer-coding is always acceptable. If the
2272         keyword "trailers" is listed, the client indicates that it is
2273         willing to accept trailer fields in the chunked response on
2274         behalf of itself and any downstream clients. The implication is
2275         that, if given, the client is stating that either all
2276         downstream clients are willing to accept trailer fields in the
2277         forwarded response, or that it will attempt to buffer the
2278         response on behalf of downstream recipients.
2279      <vspace blankLines="1"/>
2280         Note: HTTP/1.1 does not define any means to limit the size of a
2281         chunked response such that a client can be assured of buffering
2282         the entire response.</t>
2283    <t>If the transfer-coding being tested is one of the transfer-codings
2284         listed in the TE field, then it is acceptable unless it
2285         is accompanied by a qvalue of 0. (As defined in Section 3.4 of <xref target="Part3"/>, a
2286         qvalue of 0 means "not acceptable.")</t>
2287    <t>If multiple transfer-codings are acceptable, then the
2288         acceptable transfer-coding with the highest non-zero qvalue is
2289         preferred.  The "chunked" transfer-coding always has a qvalue
2290         of 1.</t>
2291  </list>
2292</t>
2293<t>
2294   If the TE field-value is empty or if no TE field is present, the only
2295   transfer-coding  is "chunked". A message with no transfer-coding is
2296   always acceptable.
2297</t>
2298</section>
2299
2300<section title="Trailer" anchor="header.trailer">
2301  <iref primary="true" item="Trailer header"/>
2302  <iref primary="true" item="Headers" subitem="Trailer"/>
2303 
2304 
2305<t>
2306   The general field "Trailer" indicates that the given set of
2307   header fields is present in the trailer of a message encoded with
2308   chunked transfer-coding.
2309</t>
2310<figure><iref primary="true" item="Grammar" subitem="Trailer"/><iref primary="true" item="Grammar" subitem="Trailer-v"/><artwork type="abnf2616"><![CDATA[
2311  Trailer   = "Trailer" ":" OWS Trailer-v
2312  Trailer-v = 1#field-name
2313]]></artwork></figure>
2314<t>
2315   An HTTP/1.1 message SHOULD include a Trailer header field in a
2316   message using chunked transfer-coding with a non-empty trailer. Doing
2317   so allows the recipient to know which header fields to expect in the
2318   trailer.
2319</t>
2320<t>
2321   If no Trailer header field is present, the trailer SHOULD NOT  include
2322   any header fields. See <xref target="chunked.transfer.encoding"/> for restrictions on the use of
2323   trailer fields in a "chunked" transfer-coding.
2324</t>
2325<t>
2326   Message header fields listed in the Trailer header field MUST NOT
2327   include the following header fields:
2328  <list style="symbols">
2329    <t>Transfer-Encoding</t>
2330    <t>Content-Length</t>
2331    <t>Trailer</t>
2332  </list>
2333</t>
2334</section>
2335
2336<section title="Transfer-Encoding" anchor="header.transfer-encoding">
2337  <iref primary="true" item="Transfer-Encoding header"/>
2338  <iref primary="true" item="Headers" subitem="Transfer-Encoding"/>
2339 
2340 
2341<t>
2342   The general-header "Transfer-Encoding" field indicates what (if any)
2343   type of transformation has been applied to the message body in order
2344   to safely transfer it between the sender and the recipient. This
2345   differs from the content-coding in that the transfer-coding is a
2346   property of the message, not of the entity.
2347</t>
2348<figure><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/><artwork type="abnf2616"><![CDATA[
2349  Transfer-Encoding   = "Transfer-Encoding" ":" OWS
2350                        Transfer-Encoding-v
2351  Transfer-Encoding-v = 1#transfer-coding
2352]]></artwork></figure>
2353<t>
2354   Transfer-codings are defined in <xref target="transfer.codings"/>. An example is:
2355</t>
2356<figure><artwork type="example"><![CDATA[
2357  Transfer-Encoding: chunked
2358]]></artwork></figure>
2359<t>
2360   If multiple encodings have been applied to an entity, the transfer-codings
2361   MUST be listed in the order in which they were applied.
2362   Additional information about the encoding parameters MAY be provided
2363   by other entity-header fields not defined by this specification.
2364</t>
2365<t>
2366   Many older HTTP/1.0 applications do not understand the Transfer-Encoding
2367   header.
2368</t>
2369</section>
2370
2371<section title="Upgrade" anchor="header.upgrade">
2372  <iref primary="true" item="Upgrade header"/>
2373  <iref primary="true" item="Headers" subitem="Upgrade"/>
2374 
2375 
2376<t>
2377   The general-header "Upgrade" allows the client to specify what
2378   additional communication protocols it supports and would like to use
2379   if the server finds it appropriate to switch protocols. The server
2380   MUST use the Upgrade header field within a 101 (Switching Protocols)
2381   response to indicate which protocol(s) are being switched.
2382</t>
2383<figure><iref primary="true" item="Grammar" subitem="Upgrade"/><iref primary="true" item="Grammar" subitem="Upgrade-v"/><artwork type="abnf2616"><![CDATA[
2384  Upgrade   = "Upgrade" ":" OWS Upgrade-v
2385  Upgrade-v = 1#product
2386]]></artwork></figure>
2387<t>
2388   For example,
2389</t>
2390<figure><artwork type="example"><![CDATA[
2391  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
2392]]></artwork></figure>
2393<t>
2394   The Upgrade header field is intended to provide a simple mechanism
2395   for transition from HTTP/1.1 to some other, incompatible protocol. It
2396   does so by allowing the client to advertise its desire to use another
2397   protocol, such as a later version of HTTP with a higher major version
2398   number, even though the current request has been made using HTTP/1.1.
2399   This eases the difficult transition between incompatible protocols by
2400   allowing the client to initiate a request in the more commonly
2401   supported protocol while indicating to the server that it would like
2402   to use a "better" protocol if available (where "better" is determined
2403   by the server, possibly according to the nature of the method and/or
2404   resource being requested).
2405</t>
2406<t>
2407   The Upgrade header field only applies to switching application-layer
2408   protocols upon the existing transport-layer connection. Upgrade
2409   cannot be used to insist on a protocol change; its acceptance and use
2410   by the server is optional. The capabilities and nature of the
2411   application-layer communication after the protocol change is entirely
2412   dependent upon the new protocol chosen, although the first action
2413   after changing the protocol MUST be a response to the initial HTTP
2414   request containing the Upgrade header field.
2415</t>
2416<t>
2417   The Upgrade header field only applies to the immediate connection.
2418   Therefore, the upgrade keyword MUST be supplied within a Connection
2419   header field (<xref target="header.connection"/>) whenever Upgrade is present in an
2420   HTTP/1.1 message.
2421</t>
2422<t>
2423   The Upgrade header field cannot be used to indicate a switch to a
2424   protocol on a different connection. For that purpose, it is more
2425   appropriate to use a 301, 302, 303, or 305 redirection response.
2426</t>
2427<t>
2428   This specification only defines the protocol name "HTTP" for use by
2429   the family of Hypertext Transfer Protocols, as defined by the HTTP
2430   version rules of <xref target="http.version"/> and future updates to this
2431   specification. Any token can be used as a protocol name; however, it
2432   will only be useful if both the client and server associate the name
2433   with the same protocol.
2434</t>
2435</section>
2436
2437<section title="Via" anchor="header.via">
2438  <iref primary="true" item="Via header"/>
2439  <iref primary="true" item="Headers" subitem="Via"/>
2440 
2441 
2442 
2443 
2444 
2445 
2446 
2447<t>
2448   The general-header field "Via" MUST be used by gateways and proxies to
2449   indicate the intermediate protocols and recipients between the user
2450   agent and the server on requests, and between the origin server and
2451   the client on responses. It is analogous to the "Received" field defined in
2452   Section 3.6.7 of <xref target="RFC5322"/> and is intended to be used for tracking message forwards,
2453   avoiding request loops, and identifying the protocol capabilities of
2454   all senders along the request/response chain.
2455</t>
2456<figure><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="Via-v"/><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[
2457  Via               = "Via" ":" OWS Via-v
2458  Via-v             = 1#( received-protocol RWS received-by
2459                          [ RWS comment ] )
2460  received-protocol = [ protocol-name "/" ] protocol-version
2461  protocol-name     = token
2462  protocol-version  = token
2463  received-by       = ( uri-host [ ":" port ] ) / pseudonym
2464  pseudonym         = token
2465]]></artwork></figure>
2466<t>
2467   The received-protocol indicates the protocol version of the message
2468   received by the server or client along each segment of the
2469   request/response chain. The received-protocol version is appended to
2470   the Via field value when the message is forwarded so that information
2471   about the protocol capabilities of upstream applications remains
2472   visible to all recipients.
2473</t>
2474<t>
2475   The protocol-name is optional if and only if it would be "HTTP". The
2476   received-by field is normally the host and optional port number of a
2477   recipient server or client that subsequently forwarded the message.
2478   However, if the real host is considered to be sensitive information,
2479   it MAY be replaced by a pseudonym. If the port is not given, it MAY
2480   be assumed to be the default port of the received-protocol.
2481</t>
2482<t>
2483   Multiple Via field values represents each proxy or gateway that has
2484   forwarded the message. Each recipient MUST append its information
2485   such that the end result is ordered according to the sequence of
2486   forwarding applications.
2487</t>
2488<t>
2489   Comments MAY be used in the Via header field to identify the software
2490   of the recipient proxy or gateway, analogous to the User-Agent and
2491   Server header fields. However, all comments in the Via field are
2492   optional and MAY be removed by any recipient prior to forwarding the
2493   message.
2494</t>
2495<t>
2496   For example, a request message could be sent from an HTTP/1.0 user
2497   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
2498   forward the request to a public proxy at p.example.net, which completes
2499   the request by forwarding it to the origin server at www.example.com.
2500   The request received by www.example.com would then have the following
2501   Via header field:
2502</t>
2503<figure><artwork type="example"><![CDATA[
2504  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
2505]]></artwork></figure>
2506<t>
2507   Proxies and gateways used as a portal through a network firewall
2508   SHOULD NOT, by default, forward the names and ports of hosts within
2509   the firewall region. This information SHOULD only be propagated if
2510   explicitly enabled. If not enabled, the received-by host of any host
2511   behind the firewall SHOULD be replaced by an appropriate pseudonym
2512   for that host.
2513</t>
2514<t>
2515   For organizations that have strong privacy requirements for hiding
2516   internal structures, a proxy MAY combine an ordered subsequence of
2517   Via header field entries with identical received-protocol values into
2518   a single such entry. For example,
2519</t>
2520<figure><artwork type="example"><![CDATA[
2521  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2522]]></artwork></figure>
2523<t>
2524        could be collapsed to
2525</t>
2526<figure><artwork type="example"><![CDATA[
2527  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2528]]></artwork></figure>
2529<t>
2530   Applications SHOULD NOT  combine multiple entries unless they are all
2531   under the same organizational control and the hosts have already been
2532   replaced by pseudonyms. Applications MUST NOT combine entries which
2533   have different received-protocol values.
2534</t>
2535</section>
2536
2537</section>
2538
2539<section title="IANA Considerations" anchor="IANA.considerations">
2540<section title="Message Header Registration" anchor="message.header.registration">
2541<t>
2542   The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
2543   with the permanent registrations below (see <xref target="RFC3864"/>):
2544</t>
2545<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
2546<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
2547   <ttcol>Header Field Name</ttcol>
2548   <ttcol>Protocol</ttcol>
2549   <ttcol>Status</ttcol>
2550   <ttcol>Reference</ttcol>
2551
2552   <c>Connection</c>
2553   <c>http</c>
2554   <c>standard</c>
2555   <c>
2556      <xref target="header.connection"/>
2557   </c>
2558   <c>Content-Length</c>
2559   <c>http</c>
2560   <c>standard</c>
2561   <c>
2562      <xref target="header.content-length"/>
2563   </c>
2564   <c>Date</c>
2565   <c>http</c>
2566   <c>standard</c>
2567   <c>
2568      <xref target="header.date"/>
2569   </c>
2570   <c>Host</c>
2571   <c>http</c>
2572   <c>standard</c>
2573   <c>
2574      <xref target="header.host"/>
2575   </c>
2576   <c>TE</c>
2577   <c>http</c>
2578   <c>standard</c>
2579   <c>
2580      <xref target="header.te"/>
2581   </c>
2582   <c>Trailer</c>
2583   <c>http</c>
2584   <c>standard</c>
2585   <c>
2586      <xref target="header.trailer"/>
2587   </c>
2588   <c>Transfer-Encoding</c>
2589   <c>http</c>
2590   <c>standard</c>
2591   <c>
2592      <xref target="header.transfer-encoding"/>
2593   </c>
2594   <c>Upgrade</c>
2595   <c>http</c>
2596   <c>standard</c>
2597   <c>
2598      <xref target="header.upgrade"/>
2599   </c>
2600   <c>Via</c>
2601   <c>http</c>
2602   <c>standard</c>
2603   <c>
2604      <xref target="header.via"/>
2605   </c>
2606</texttable>
2607<!--(END)-->
2608<t>
2609   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
2610</t>
2611</section>
2612
2613<section title="URI Scheme Registration" anchor="uri.scheme.registration">
2614<t>
2615   The entry for the "http" URI Scheme in the registry located at
2616   <eref target="http://www.iana.org/assignments/uri-schemes.html"/>
2617   should be updated to point to <xref target="http.uri"/> of this document
2618   (see <xref target="RFC4395"/>).
2619</t>
2620</section>
2621
2622<section title="Internet Media Type Registrations" anchor="internet.media.type.http">
2623<t>
2624   This document serves as the specification for the Internet media types
2625   "message/http" and "application/http". The following is to be registered with
2626   IANA (see <xref target="RFC4288"/>).
2627</t>
2628<section title="Internet Media Type message/http" anchor="internet.media.type.message.http">
2629<iref item="Media Type" subitem="message/http" primary="true"/>
2630<iref item="message/http Media Type" primary="true"/>
2631<t>
2632   The message/http type can be used to enclose a single HTTP request or
2633   response message, provided that it obeys the MIME restrictions for all
2634   "message" types regarding line length and encodings.
2635</t>
2636<t>
2637  <list style="hanging">
2638    <t hangText="Type name:">
2639      message
2640    </t>
2641    <t hangText="Subtype name:">
2642      http
2643    </t>
2644    <t hangText="Required parameters:">
2645      none
2646    </t>
2647    <t hangText="Optional parameters:">
2648      version, msgtype
2649      <list style="hanging">
2650        <t hangText="version:">
2651          The HTTP-Version number of the enclosed message
2652          (e.g., "1.1"). If not present, the version can be
2653          determined from the first line of the body.
2654        </t>
2655        <t hangText="msgtype:">
2656          The message type -- "request" or "response". If not
2657          present, the type can be determined from the first
2658          line of the body.
2659        </t>
2660      </list>
2661    </t>
2662    <t hangText="Encoding considerations:">
2663      only "7bit", "8bit", or "binary" are permitted
2664    </t>
2665    <t hangText="Security considerations:">
2666      none
2667    </t>
2668    <t hangText="Interoperability considerations:">
2669      none
2670    </t>
2671    <t hangText="Published specification:">
2672      This specification (see <xref target="internet.media.type.message.http"/>).
2673    </t>
2674    <t hangText="Applications that use this media type:">
2675    </t>
2676    <t hangText="Additional information:">
2677      <list style="hanging">
2678        <t hangText="Magic number(s):">none</t>
2679        <t hangText="File extension(s):">none</t>
2680        <t hangText="Macintosh file type code(s):">none</t>
2681      </list>
2682    </t>
2683    <t hangText="Person and email address to contact for further information:">
2684      See Authors Section.
2685    </t>
2686                <t hangText="Intended usage:">
2687                  COMMON
2688    </t>
2689                <t hangText="Restrictions on usage:">
2690                  none
2691    </t>
2692    <t hangText="Author/Change controller:">
2693      IESG
2694    </t>
2695  </list>
2696</t>
2697</section>
2698<section title="Internet Media Type application/http" anchor="internet.media.type.application.http">
2699<iref item="Media Type" subitem="application/http" primary="true"/>
2700<iref item="application/http Media Type" primary="true"/>
2701<t>
2702   The application/http type can be used to enclose a pipeline of one or more
2703   HTTP request or response messages (not intermixed).
2704</t>
2705<t>
2706  <list style="hanging">
2707    <t hangText="Type name:">
2708      application
2709    </t>
2710    <t hangText="Subtype name:">
2711      http
2712    </t>
2713    <t hangText="Required parameters:">
2714      none
2715    </t>
2716    <t hangText="Optional parameters:">
2717      version, msgtype
2718      <list style="hanging">
2719        <t hangText="version:">
2720          The HTTP-Version number of the enclosed messages
2721          (e.g., "1.1"). If not present, the version can be
2722          determined from the first line of the body.
2723        </t>
2724        <t hangText="msgtype:">
2725          The message type -- "request" or "response". If not
2726          present, the type can be determined from the first
2727          line of the body.
2728        </t>
2729      </list>
2730    </t>
2731    <t hangText="Encoding considerations:">
2732      HTTP messages enclosed by this type
2733      are in "binary" format; use of an appropriate
2734      Content-Transfer-Encoding is required when
2735      transmitted via E-mail.
2736    </t>
2737    <t hangText="Security considerations:">
2738      none
2739    </t>
2740    <t hangText="Interoperability considerations:">
2741      none
2742    </t>
2743    <t hangText="Published specification:">
2744      This specification (see <xref target="internet.media.type.application.http"/>).
2745    </t>
2746    <t hangText="Applications that use this media type:">
2747    </t>
2748    <t hangText="Additional information:">
2749      <list style="hanging">
2750        <t hangText="Magic number(s):">none</t>
2751        <t hangText="File extension(s):">none</t>
2752        <t hangText="Macintosh file type code(s):">none</t>
2753      </list>
2754    </t>
2755    <t hangText="Person and email address to contact for further information:">
2756      See Authors Section.
2757    </t>
2758                <t hangText="Intended usage:">
2759                  COMMON
2760    </t>
2761                <t hangText="Restrictions on usage:">
2762                  none
2763    </t>
2764    <t hangText="Author/Change controller:">
2765      IESG
2766    </t>
2767  </list>
2768</t>
2769</section>
2770</section>
2771
2772</section>
2773
2774<section title="Security Considerations" anchor="security.considerations">
2775<t>
2776   This section is meant to inform application developers, information
2777   providers, and users of the security limitations in HTTP/1.1 as
2778   described by this document. The discussion does not include
2779   definitive solutions to the problems revealed, though it does make
2780   some suggestions for reducing security risks.
2781</t>
2782
2783<section title="Personal Information" anchor="personal.information">
2784<t>
2785   HTTP clients are often privy to large amounts of personal information
2786   (e.g. the user's name, location, mail address, passwords, encryption
2787   keys, etc.), and SHOULD be very careful to prevent unintentional
2788   leakage of this information.
2789   We very strongly recommend that a convenient interface be provided
2790   for the user to control dissemination of such information, and that
2791   designers and implementors be particularly careful in this area.
2792   History shows that errors in this area often create serious security
2793   and/or privacy problems and generate highly adverse publicity for the
2794   implementor's company.
2795</t>
2796</section>
2797
2798<section title="Abuse of Server Log Information" anchor="abuse.of.server.log.information">
2799<t>
2800   A server is in the position to save personal data about a user's
2801   requests which might identify their reading patterns or subjects of
2802   interest. This information is clearly confidential in nature and its
2803   handling can be constrained by law in certain countries. People using
2804   HTTP to provide data are responsible for ensuring that
2805   such material is not distributed without the permission of any
2806   individuals that are identifiable by the published results.
2807</t>
2808</section>
2809
2810<section title="Attacks Based On File and Path Names" anchor="attack.pathname">
2811<t>
2812   Implementations of HTTP origin servers SHOULD be careful to restrict
2813   the documents returned by HTTP requests to be only those that were
2814   intended by the server administrators. If an HTTP server translates
2815   HTTP URIs directly into file system calls, the server MUST take
2816   special care not to serve files that were not intended to be
2817   delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
2818   other operating systems use ".." as a path component to indicate a
2819   directory level above the current one. On such a system, an HTTP
2820   server MUST disallow any such construct in the Request-URI if it
2821   would otherwise allow access to a resource outside those intended to
2822   be accessible via the HTTP server. Similarly, files intended for
2823   reference only internally to the server (such as access control
2824   files, configuration files, and script code) MUST be protected from
2825   inappropriate retrieval, since they might contain sensitive
2826   information. Experience has shown that minor bugs in such HTTP server
2827   implementations have turned into security risks.
2828</t>
2829</section>
2830
2831<section title="DNS Spoofing" anchor="dns.spoofing">
2832<t>
2833   Clients using HTTP rely heavily on the Domain Name Service, and are
2834   thus generally prone to security attacks based on the deliberate
2835   mis-association of IP addresses and DNS names. Clients need to be
2836   cautious in assuming the continuing validity of an IP number/DNS name
2837   association.
2838</t>
2839<t>
2840   In particular, HTTP clients SHOULD rely on their name resolver for
2841   confirmation of an IP number/DNS name association, rather than
2842   caching the result of previous host name lookups. Many platforms
2843   already can cache host name lookups locally when appropriate, and
2844   they SHOULD be configured to do so. It is proper for these lookups to
2845   be cached, however, only when the TTL (Time To Live) information
2846   reported by the name server makes it likely that the cached
2847   information will remain useful.
2848</t>
2849<t>
2850   If HTTP clients cache the results of host name lookups in order to
2851   achieve a performance improvement, they MUST observe the TTL
2852   information reported by DNS.
2853</t>
2854<t>
2855   If HTTP clients do not observe this rule, they could be spoofed when
2856   a previously-accessed server's IP address changes. As network
2857   renumbering is expected to become increasingly common <xref target="RFC1900"/>, the
2858   possibility of this form of attack will grow. Observing this
2859   requirement thus reduces this potential security vulnerability.
2860</t>
2861<t>
2862   This requirement also improves the load-balancing behavior of clients
2863   for replicated servers using the same DNS name and reduces the
2864   likelihood of a user's experiencing failure in accessing sites which
2865   use that strategy.
2866</t>
2867</section>
2868
2869<section title="Proxies and Caching" anchor="attack.proxies">
2870<t>
2871   By their very nature, HTTP proxies are men-in-the-middle, and
2872   represent an opportunity for man-in-the-middle attacks. Compromise of
2873   the systems on which the proxies run can result in serious security
2874   and privacy problems. Proxies have access to security-related
2875   information, personal information about individual users and
2876   organizations, and proprietary information belonging to users and
2877   content providers. A compromised proxy, or a proxy implemented or
2878   configured without regard to security and privacy considerations,
2879   might be used in the commission of a wide range of potential attacks.
2880</t>
2881<t>
2882   Proxy operators should protect the systems on which proxies run as
2883   they would protect any system that contains or transports sensitive
2884   information. In particular, log information gathered at proxies often
2885   contains highly sensitive personal information, and/or information
2886   about organizations. Log information should be carefully guarded, and
2887   appropriate guidelines for use developed and followed. (<xref target="abuse.of.server.log.information"/>).
2888</t>
2889<t>
2890   Proxy implementors should consider the privacy and security
2891   implications of their design and coding decisions, and of the
2892   configuration options they provide to proxy operators (especially the
2893   default configuration).
2894</t>
2895<t>
2896   Users of a proxy need to be aware that they are no trustworthier than
2897   the people who run the proxy; HTTP itself cannot solve this problem.
2898</t>
2899<t>
2900   The judicious use of cryptography, when appropriate, may suffice to
2901   protect against a broad range of security and privacy attacks. Such
2902   cryptography is beyond the scope of the HTTP/1.1 specification.
2903</t>
2904</section>
2905
2906<section title="Denial of Service Attacks on Proxies" anchor="attack.DoS">
2907<t>
2908   They exist. They are hard to defend against. Research continues.
2909   Beware.
2910</t>
2911</section>
2912</section>
2913
2914<section title="Acknowledgments" anchor="ack">
2915<t>
2916   HTTP has evolved considerably over the years. It has
2917   benefited from a large and active developer community--the many
2918   people who have participated on the www-talk mailing list--and it is
2919   that community which has been most responsible for the success of
2920   HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
2921   Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
2922   Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
2923   McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
2924   VanHeyningen deserve special recognition for their efforts in
2925   defining early aspects of the protocol.
2926</t>
2927<t>
2928   This document has benefited greatly from the comments of all those
2929   participating in the HTTP-WG. In addition to those already mentioned,
2930   the following individuals have contributed to this specification:
2931</t>
2932<t>
2933   Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
2934   Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra,
2935   Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Hedlund, Greg Herlihy,
2936   Koen Holtman, Alex Hopmann, Bob Jernigan, Shel Kaphan, Rohit Khare,
2937   John Klensin, Martijn Koster, Alexei Kosut, David M. Kristol,
2938   Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert Lunde,
2939   John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David Morris,
2940   Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott Powers, Owen Rees,
2941   Luigi Rizzo, David Robinson, Marc Salomon, Rich Salz,
2942   Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink,
2943   Simon E. Spero, Richard N. Taylor, Robert S. Thau,
2944   Bill (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko,
2945   Josh Cohen.
2946</t>
2947<t>
2948   Thanks to the "cave men" of Palo Alto. You know who you are.
2949</t>
2950<t>
2951   Jim Gettys (the editor of <xref target="RFC2616"/>) wishes particularly
2952   to thank Roy Fielding, the editor of <xref target="RFC2068"/>, along
2953   with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
2954   Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
2955   Larry Masinter for their help. And thanks go particularly to Jeff
2956   Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
2957</t>
2958<t>
2959   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
2960   Frystyk implemented RFC 2068 early, and we wish to thank them for the
2961   discovery of many of the problems that this document attempts to
2962   rectify.
2963</t>
2964<t>
2965   This specification makes heavy use of the augmented BNF and generic
2966   constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it
2967   reuses many of the definitions provided by Nathaniel Borenstein and
2968   Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this
2969   specification will help reduce past confusion over the relationship
2970   between HTTP and Internet mail message formats.
2971</t>
2972</section>
2973
2974</middle>
2975<back>
2976
2977<references title="Normative References">
2978
2979<reference anchor="ISO-8859-1">
2980  <front>
2981    <title>
2982     Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1
2983    </title>
2984    <author>
2985      <organization>International Organization for Standardization</organization>
2986    </author>
2987    <date year="1998"/>
2988  </front>
2989  <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
2990</reference>
2991
2992<reference anchor="Part2">
2993  <front>
2994    <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>
2995    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2996      <organization abbrev="Day Software">Day Software</organization>
2997      <address><email>fielding@gbiv.com</email></address>
2998    </author>
2999    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3000      <organization>One Laptop per Child</organization>
3001      <address><email>jg@laptop.org</email></address>
3002    </author>
3003    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3004      <organization abbrev="HP">Hewlett-Packard Company</organization>
3005      <address><email>JeffMogul@acm.org</email></address>
3006    </author>
3007    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3008      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3009      <address><email>henrikn@microsoft.com</email></address>
3010    </author>
3011    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3012      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
3013      <address><email>LMM@acm.org</email></address>
3014    </author>
3015    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3016      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3017      <address><email>paulle@microsoft.com</email></address>
3018    </author>
3019    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3020      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3021      <address><email>timbl@w3.org</email></address>
3022    </author>
3023    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3024      <organization abbrev="W3C">World Wide Web Consortium</organization>
3025      <address><email>ylafon@w3.org</email></address>
3026    </author>
3027    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3028      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3029      <address><email>julian.reschke@greenbytes.de</email></address>
3030    </author>
3031    <date month="November" year="2008"/>
3032  </front>
3033  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-05"/>
3034 
3035</reference>
3036
3037<reference anchor="Part3">
3038  <front>
3039    <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
3040    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
3041      <organization abbrev="Day Software">Day Software</organization>
3042      <address><email>fielding@gbiv.com</email></address>
3043    </author>
3044    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3045      <organization>One Laptop per Child</organization>
3046      <address><email>jg@laptop.org</email></address>
3047    </author>
3048    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3049      <organization abbrev="HP">Hewlett-Packard Company</organization>
3050      <address><email>JeffMogul@acm.org</email></address>
3051    </author>
3052    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3053      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3054      <address><email>henrikn@microsoft.com</email></address>
3055    </author>
3056    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3057      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
3058      <address><email>LMM@acm.org</email></address>
3059    </author>
3060    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3061      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3062      <address><email>paulle@microsoft.com</email></address>
3063    </author>
3064    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3065      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3066      <address><email>timbl@w3.org</email></address>
3067    </author>
3068    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3069      <organization abbrev="W3C">World Wide Web Consortium</organization>
3070      <address><email>ylafon@w3.org</email></address>
3071    </author>
3072    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3073      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3074      <address><email>julian.reschke@greenbytes.de</email></address>
3075    </author>
3076    <date month="November" year="2008"/>
3077  </front>
3078  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-05"/>
3079 
3080</reference>
3081
3082<reference anchor="Part5">
3083  <front>
3084    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
3085    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
3086      <organization abbrev="Day Software">Day Software</organization>
3087      <address><email>fielding@gbiv.com</email></address>
3088    </author>
3089    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3090      <organization>One Laptop per Child</organization>
3091      <address><email>jg@laptop.org</email></address>
3092    </author>
3093    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3094      <organization abbrev="HP">Hewlett-Packard Company</organization>
3095      <address><email>JeffMogul@acm.org</email></address>
3096    </author>
3097    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3098      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3099      <address><email>henrikn@microsoft.com</email></address>
3100    </author>
3101    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3102      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
3103      <address><email>LMM@acm.org</email></address>
3104    </author>
3105    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3106      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3107      <address><email>paulle@microsoft.com</email></address>
3108    </author>
3109    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3110      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3111      <address><email>timbl@w3.org</email></address>
3112    </author>
3113    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3114      <organization abbrev="W3C">World Wide Web Consortium</organization>
3115      <address><email>ylafon@w3.org</email></address>
3116    </author>
3117    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3118      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3119      <address><email>julian.reschke@greenbytes.de</email></address>
3120    </author>
3121    <date month="November" year="2008"/>
3122  </front>
3123  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-05"/>
3124 
3125</reference>
3126
3127<reference anchor="Part6">
3128  <front>
3129    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
3130    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
3131      <organization abbrev="Day Software">Day Software</organization>
3132      <address><email>fielding@gbiv.com</email></address>
3133    </author>
3134    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3135      <organization>One Laptop per Child</organization>
3136      <address><email>jg@laptop.org</email></address>
3137    </author>
3138    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3139      <organization abbrev="HP">Hewlett-Packard Company</organization>
3140      <address><email>JeffMogul@acm.org</email></address>
3141    </author>
3142    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3143      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3144      <address><email>henrikn@microsoft.com</email></address>
3145    </author>
3146    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3147      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
3148      <address><email>LMM@acm.org</email></address>
3149    </author>
3150    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3151      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3152      <address><email>paulle@microsoft.com</email></address>
3153    </author>
3154    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3155      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3156      <address><email>timbl@w3.org</email></address>
3157    </author>
3158    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3159      <organization abbrev="W3C">World Wide Web Consortium</organization>
3160      <address><email>ylafon@w3.org</email></address>
3161    </author>
3162    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3163      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3164      <address><email>julian.reschke@greenbytes.de</email></address>
3165    </author>
3166    <date month="November" year="2008"/>
3167  </front>
3168  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-05"/>
3169 
3170</reference>
3171
3172<reference anchor="RFC5234">
3173  <front>
3174    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
3175    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
3176      <organization>Brandenburg InternetWorking</organization>
3177      <address>
3178      <postal>
3179      <street>675 Spruce Dr.</street>
3180      <city>Sunnyvale</city>
3181      <region>CA</region>
3182      <code>94086</code>
3183      <country>US</country></postal>
3184      <phone>+1.408.246.8253</phone>
3185      <email>dcrocker@bbiw.net</email></address> 
3186    </author>
3187    <author initials="P." surname="Overell" fullname="Paul Overell">
3188      <organization>THUS plc.</organization>
3189      <address>
3190      <postal>
3191      <street>1/2 Berkeley Square</street>
3192      <street>99 Berkely Street</street>
3193      <city>Glasgow</city>
3194      <code>G3 7HR</code>
3195      <country>UK</country></postal>
3196      <email>paul.overell@thus.net</email></address>
3197    </author>
3198    <date month="January" year="2008"/>
3199  </front>
3200  <seriesInfo name="STD" value="68"/>
3201  <seriesInfo name="RFC" value="5234"/>
3202</reference>
3203
3204<reference anchor="RFC2045">
3205  <front>
3206    <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
3207    <author initials="N." surname="Freed" fullname="Ned Freed">
3208      <organization>Innosoft International, Inc.</organization>
3209      <address><email>ned@innosoft.com</email></address>
3210    </author>
3211    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
3212      <organization>First Virtual Holdings</organization>
3213      <address><email>nsb@nsb.fv.com</email></address>
3214    </author>
3215    <date month="November" year="1996"/>
3216  </front>
3217  <seriesInfo name="RFC" value="2045"/>
3218</reference>
3219
3220<reference anchor="RFC2047">
3221  <front>
3222    <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
3223    <author initials="K." surname="Moore" fullname="Keith Moore">
3224      <organization>University of Tennessee</organization>
3225      <address><email>moore@cs.utk.edu</email></address>
3226    </author>
3227    <date month="November" year="1996"/>
3228  </front>
3229  <seriesInfo name="RFC" value="2047"/>
3230</reference>
3231
3232<reference anchor="RFC2119">
3233  <front>
3234    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
3235    <author initials="S." surname="Bradner" fullname="Scott Bradner">
3236      <organization>Harvard University</organization>
3237      <address><email>sob@harvard.edu</email></address>
3238    </author>
3239    <date month="March" year="1997"/>
3240  </front>
3241  <seriesInfo name="BCP" value="14"/>
3242  <seriesInfo name="RFC" value="2119"/>
3243</reference>
3244
3245<reference anchor="RFC3986">
3246 <front>
3247  <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
3248  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3249    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3250    <address>
3251       <email>timbl@w3.org</email>
3252       <uri>http://www.w3.org/People/Berners-Lee/</uri>
3253    </address>
3254  </author>
3255  <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
3256    <organization abbrev="Day Software">Day Software</organization>
3257    <address>
3258      <email>fielding@gbiv.com</email>
3259      <uri>http://roy.gbiv.com/</uri>
3260    </address>
3261  </author>
3262  <author initials="L." surname="Masinter" fullname="Larry Masinter">
3263    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
3264    <address>
3265      <email>LMM@acm.org</email>
3266      <uri>http://larry.masinter.net/</uri>
3267    </address>
3268  </author>
3269  <date month="January" year="2005"/>
3270 </front>
3271 <seriesInfo name="RFC" value="3986"/>
3272 <seriesInfo name="STD" value="66"/>
3273</reference>
3274
3275<reference anchor="USASCII">
3276  <front>
3277    <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
3278    <author>
3279      <organization>American National Standards Institute</organization>
3280    </author>
3281    <date year="1986"/>
3282  </front>
3283  <seriesInfo name="ANSI" value="X3.4"/>
3284</reference>
3285
3286</references>
3287
3288<references title="Informative References">
3289
3290<reference anchor="Nie1997" target="http://doi.acm.org/10.1145/263105.263157">
3291  <front>
3292    <title>Network Performance Effects of HTTP/1.1, CSS1, and PNG</title>
3293    <author initials="H.F.." surname="Nielsen" fullname="H.F. Nielsen">
3294      <organization/>
3295    </author>
3296    <author initials="J." surname="Gettys" fullname="J. Gettys">
3297      <organization/>
3298    </author>
3299    <author initials="E." surname="Prud'hommeaux" fullname="E. Prud'hommeaux">
3300      <organization/>
3301    </author>
3302    <author initials="H." surname="Lie" fullname="H. Lie">
3303      <organization/>
3304    </author>
3305    <author initials="C." surname="Lilley" fullname="C. Lilley">
3306      <organization/>
3307    </author>
3308    <date year="1997" month="September"/>
3309  </front>
3310  <seriesInfo name="ACM" value="Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication SIGCOMM '97"/>
3311</reference>
3312
3313<reference anchor="Pad1995" target="http://portal.acm.org/citation.cfm?id=219094">
3314  <front>
3315    <title>Improving HTTP Latency</title>
3316    <author initials="V.N." surname="Padmanabhan" fullname="Venkata N. Padmanabhan">
3317      <organization/>
3318    </author>
3319    <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
3320      <organization/>
3321    </author>
3322    <date year="1995" month="December"/>
3323  </front>
3324  <seriesInfo name="Computer Networks and ISDN Systems" value="v. 28, pp. 25-35"/>
3325</reference>
3326
3327<reference anchor="RFC822">
3328  <front>
3329    <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
3330    <author initials="D.H." surname="Crocker" fullname="David H. Crocker">
3331      <organization>University of Delaware, Dept. of Electrical Engineering</organization>
3332      <address><email>DCrocker@UDel-Relay</email></address>
3333    </author>
3334    <date month="August" day="13" year="1982"/>
3335  </front>
3336  <seriesInfo name="STD" value="11"/>
3337  <seriesInfo name="RFC" value="822"/>
3338</reference>
3339
3340<reference anchor="RFC959">
3341  <front>
3342    <title abbrev="File Transfer Protocol">File Transfer Protocol</title>
3343    <author initials="J." surname="Postel" fullname="J. Postel">
3344      <organization>Information Sciences Institute (ISI)</organization>
3345    </author>
3346    <author initials="J." surname="Reynolds" fullname="J. Reynolds">
3347      <organization/>
3348    </author>
3349    <date month="October" year="1985"/>
3350  </front>
3351  <seriesInfo name="STD" value="9"/>
3352  <seriesInfo name="RFC" value="959"/>
3353</reference>
3354
3355<reference anchor="RFC1123">
3356  <front>
3357    <title>Requirements for Internet Hosts - Application and Support</title>
3358    <author initials="R." surname="Braden" fullname="Robert Braden">
3359      <organization>University of Southern California (USC), Information Sciences Institute</organization>
3360      <address><email>Braden@ISI.EDU</email></address>
3361    </author>
3362    <date month="October" year="1989"/>
3363  </front>
3364  <seriesInfo name="STD" value="3"/>
3365  <seriesInfo name="RFC" value="1123"/>
3366</reference>
3367
3368<reference anchor="RFC1305">
3369  <front>
3370    <title>Network Time Protocol (Version 3) Specification, Implementation</title>
3371    <author initials="D." surname="Mills" fullname="David L. Mills">
3372      <organization>University of Delaware, Electrical Engineering Department</organization>
3373      <address><email>mills@udel.edu</email></address>
3374    </author>
3375    <date month="March" year="1992"/>
3376  </front>
3377  <seriesInfo name="RFC" value="1305"/>
3378</reference>
3379
3380<reference anchor="RFC1436">
3381  <front>
3382    <title abbrev="Gopher">The Internet Gopher Protocol (a distributed document search and retrieval protocol)</title>
3383    <author initials="F." surname="Anklesaria" fullname="Farhad Anklesaria">
3384      <organization>University of Minnesota, Computer and Information Services</organization>
3385      <address><email>fxa@boombox.micro.umn.edu</email></address>
3386    </author>
3387    <author initials="M." surname="McCahill" fullname="Mark McCahill">
3388      <organization>University of Minnesota, Computer and Information Services</organization>
3389      <address><email>mpm@boombox.micro.umn.edu</email></address>
3390    </author>
3391    <author initials="P." surname="Lindner" fullname="Paul Lindner">
3392      <organization>University of Minnesota, Computer and Information Services</organization>
3393      <address><email>lindner@boombox.micro.umn.edu</email></address>
3394    </author>
3395    <author initials="D." surname="Johnson" fullname="David Johnson">
3396      <organization>University of Minnesota, Computer and Information Services</organization>
3397      <address><email>dmj@boombox.micro.umn.edu</email></address>
3398    </author>
3399    <author initials="D." surname="Torrey" fullname="Daniel Torrey">
3400      <organization>University of Minnesota, Computer and Information Services</organization>
3401      <address><email>daniel@boombox.micro.umn.edu</email></address>
3402    </author>
3403    <author initials="B." surname="Alberti" fullname="Bob Alberti">
3404      <organization>University of Minnesota, Computer and Information Services</organization>
3405      <address><email>alberti@boombox.micro.umn.edu</email></address>
3406    </author>
3407    <date month="March" year="1993"/>
3408  </front>
3409  <seriesInfo name="RFC" value="1436"/>
3410</reference>
3411
3412<reference anchor="RFC1900">
3413  <front>
3414    <title>Renumbering Needs Work</title>
3415    <author initials="B." surname="Carpenter" fullname="Brian E. Carpenter">
3416      <organization>CERN, Computing and Networks Division</organization>
3417      <address><email>brian@dxcoms.cern.ch</email></address>
3418    </author>
3419    <author initials="Y." surname="Rekhter" fullname="Yakov Rekhter">
3420      <organization>cisco Systems</organization>
3421      <address><email>yakov@cisco.com</email></address>
3422    </author>
3423    <date month="February" year="1996"/>
3424  </front>
3425  <seriesInfo name="RFC" value="1900"/>
3426</reference>
3427
3428<reference anchor="RFC1945">
3429  <front>
3430    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
3431    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3432      <organization>MIT, Laboratory for Computer Science</organization>
3433      <address><email>timbl@w3.org</email></address>
3434    </author>
3435    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
3436      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
3437      <address><email>fielding@ics.uci.edu</email></address>
3438    </author>
3439    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
3440      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
3441      <address><email>frystyk@w3.org</email></address>
3442    </author>
3443    <date month="May" year="1996"/>
3444  </front>
3445  <seriesInfo name="RFC" value="1945"/>
3446</reference>
3447
3448<reference anchor="RFC2068">
3449  <front>
3450    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
3451    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
3452      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
3453      <address><email>fielding@ics.uci.edu</email></address>
3454    </author>
3455    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3456      <organization>MIT Laboratory for Computer Science</organization>
3457      <address><email>jg@w3.org</email></address>
3458    </author>
3459    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3460      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
3461      <address><email>mogul@wrl.dec.com</email></address>
3462    </author>
3463    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
3464      <organization>MIT Laboratory for Computer Science</organization>
3465      <address><email>frystyk@w3.org</email></address>
3466    </author>
3467    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3468      <organization>MIT Laboratory for Computer Science</organization>
3469      <address><email>timbl@w3.org</email></address>
3470    </author>
3471    <date month="January" year="1997"/>
3472  </front>
3473  <seriesInfo name="RFC" value="2068"/>
3474</reference>
3475
3476<reference anchor="RFC2109">
3477  <front>
3478    <title>HTTP State Management Mechanism</title>
3479    <author initials="D.M." surname="Kristol" fullname="David M. Kristol">
3480      <organization>Bell Laboratories, Lucent Technologies</organization>
3481      <address><email>dmk@bell-labs.com</email></address>
3482    </author>
3483    <author initials="L." surname="Montulli" fullname="Lou Montulli">
3484      <organization>Netscape Communications Corp.</organization>
3485      <address><email>montulli@netscape.com</email></address>
3486    </author>
3487    <date year="1997" month="February"/>
3488  </front>
3489  <seriesInfo name="RFC" value="2109"/>
3490</reference>
3491
3492<reference anchor="RFC2145">
3493  <front>
3494    <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
3495    <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
3496      <organization>Western Research Laboratory</organization>
3497      <address><email>mogul@wrl.dec.com</email></address>
3498    </author>
3499    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
3500      <organization>Department of Information and Computer Science</organization>
3501      <address><email>fielding@ics.uci.edu</email></address>
3502    </author>
3503    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3504      <organization>MIT Laboratory for Computer Science</organization>
3505      <address><email>jg@w3.org</email></address>
3506    </author>
3507    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
3508      <organization>W3 Consortium</organization>
3509      <address><email>frystyk@w3.org</email></address>
3510    </author>
3511    <date month="May" year="1997"/>
3512  </front>
3513  <seriesInfo name="RFC" value="2145"/>
3514</reference>
3515
3516<reference anchor="RFC2616">
3517  <front>
3518    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
3519    <author initials="R." surname="Fielding" fullname="R. Fielding">
3520      <organization>University of California, Irvine</organization>
3521      <address><email>fielding@ics.uci.edu</email></address>
3522    </author>
3523    <author initials="J." surname="Gettys" fullname="J. Gettys">
3524      <organization>W3C</organization>
3525      <address><email>jg@w3.org</email></address>
3526    </author>
3527    <author initials="J." surname="Mogul" fullname="J. Mogul">
3528      <organization>Compaq Computer Corporation</organization>
3529      <address><email>mogul@wrl.dec.com</email></address>
3530    </author>
3531    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
3532      <organization>MIT Laboratory for Computer Science</organization>
3533      <address><email>frystyk@w3.org</email></address>
3534    </author>
3535    <author initials="L." surname="Masinter" fullname="L. Masinter">
3536      <organization>Xerox Corporation</organization>
3537      <address><email>masinter@parc.xerox.com</email></address>
3538    </author>
3539    <author initials="P." surname="Leach" fullname="P. Leach">
3540      <organization>Microsoft Corporation</organization>
3541      <address><email>paulle@microsoft.com</email></address>
3542    </author>
3543    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
3544      <organization>W3C</organization>
3545      <address><email>timbl@w3.org</email></address>
3546    </author>
3547    <date month="June" year="1999"/>
3548  </front>
3549  <seriesInfo name="RFC" value="2616"/>
3550</reference>
3551
3552<reference anchor="RFC2818">
3553  <front>
3554    <title>HTTP Over TLS</title>
3555    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
3556      <organization>RTFM, Inc.</organization>
3557      <address><email>ekr@rtfm.com</email></address>
3558    </author>
3559    <date year="2000" month="May"/>
3560  </front>
3561  <seriesInfo name="RFC" value="2818"/>
3562</reference>
3563
3564<reference anchor="RFC2965">
3565  <front>
3566    <title>HTTP State Management Mechanism</title>
3567    <author initials="D. M." surname="Kristol" fullname="David M. Kristol">
3568      <organization>Bell Laboratories, Lucent Technologies</organization>
3569      <address><email>dmk@bell-labs.com</email></address>
3570    </author>
3571    <author initials="L." surname="Montulli" fullname="Lou Montulli">
3572      <organization>Epinions.com, Inc.</organization>
3573      <address><email>lou@montulli.org</email></address>
3574    </author>
3575    <date year="2000" month="October"/>
3576  </front>
3577  <seriesInfo name="RFC" value="2965"/>
3578</reference>
3579
3580<reference anchor="RFC3864">
3581  <front>
3582    <title>Registration Procedures for Message Header Fields</title>
3583    <author initials="G." surname="Klyne" fullname="G. Klyne">
3584      <organization>Nine by Nine</organization>
3585      <address><email>GK-IETF@ninebynine.org</email></address>
3586    </author>
3587    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
3588      <organization>BEA Systems</organization>
3589      <address><email>mnot@pobox.com</email></address>
3590    </author>
3591    <author initials="J." surname="Mogul" fullname="J. Mogul">
3592      <organization>HP Labs</organization>
3593      <address><email>JeffMogul@acm.org</email></address>
3594    </author>
3595    <date year="2004" month="September"/>
3596  </front>
3597  <seriesInfo name="BCP" value="90"/>
3598  <seriesInfo name="RFC" value="3864"/>
3599</reference>
3600
3601<reference anchor="RFC3977">
3602  <front>
3603    <title>Network News Transfer Protocol (NNTP)</title>
3604    <author initials="C." surname="Feather" fullname="C. Feather">
3605      <organization>THUS plc</organization>
3606      <address><email>clive@demon.net</email></address>
3607    </author>
3608    <date year="2006" month="October"/>
3609  </front>
3610  <seriesInfo name="RFC" value="3977"/>
3611</reference>
3612
3613<reference anchor="RFC4288">
3614  <front>
3615    <title>Media Type Specifications and Registration Procedures</title>
3616    <author initials="N." surname="Freed" fullname="N. Freed">
3617      <organization>Sun Microsystems</organization>
3618      <address>
3619        <email>ned.freed@mrochek.com</email>
3620      </address>
3621    </author>
3622    <author initials="J." surname="Klensin" fullname="J. Klensin">
3623      <organization/>
3624      <address>
3625        <email>klensin+ietf@jck.com</email>
3626      </address>
3627    </author>
3628    <date year="2005" month="December"/>
3629  </front>
3630  <seriesInfo name="BCP" value="13"/>
3631  <seriesInfo name="RFC" value="4288"/>
3632</reference>
3633
3634<reference anchor="RFC4395">
3635  <front>
3636    <title>Guidelines and Registration Procedures for New URI Schemes</title>
3637    <author initials="T." surname="Hansen" fullname="T. Hansen">
3638      <organization>AT&amp;T Laboratories</organization>
3639      <address>
3640        <email>tony+urireg@maillennium.att.com</email>
3641      </address>
3642    </author>
3643    <author initials="T." surname="Hardie" fullname="T. Hardie">
3644      <organization>Qualcomm, Inc.</organization>
3645      <address>
3646        <email>hardie@qualcomm.com</email>
3647      </address>
3648    </author>
3649    <author initials="L." surname="Masinter" fullname="L. Masinter">
3650      <organization>Adobe Systems</organization>
3651      <address>
3652        <email>LMM@acm.org</email>
3653      </address>
3654    </author>
3655    <date year="2006" month="February"/>
3656  </front>
3657  <seriesInfo name="BCP" value="115"/>
3658  <seriesInfo name="RFC" value="4395"/>
3659</reference>
3660
3661<reference anchor="RFC5322">
3662  <front>
3663    <title>Internet Message Format</title>
3664    <author initials="P." surname="Resnick" fullname="P. Resnick">
3665      <organization>Qualcomm Incorporated</organization>
3666    </author>
3667    <date year="2008" month="October"/>
3668  </front> 
3669  <seriesInfo name="RFC" value="5322"/>
3670</reference>
3671
3672<reference anchor="Kri2001" target="http://arxiv.org/abs/cs.SE/0105018">
3673  <front>
3674    <title>HTTP Cookies: Standards, Privacy, and Politics</title>
3675    <author initials="D." surname="Kristol" fullname="David M. Kristol">
3676      <organization/>
3677    </author>
3678    <date year="2001" month="November"/>
3679  </front>
3680  <seriesInfo name="ACM Transactions on Internet Technology" value="Vol. 1, #2"/>
3681</reference>
3682
3683<reference anchor="Spe" target="http://sunsite.unc.edu/mdma-release/http-prob.html">
3684  <front>
3685  <title>Analysis of HTTP Performance Problems</title>
3686  <author initials="S." surname="Spero" fullname="Simon E. Spero">
3687    <organization/>
3688  </author>
3689  <date/>
3690  </front>
3691</reference>
3692
3693<reference anchor="Tou1998" target="http://www.isi.edu/touch/pubs/http-perf96/">
3694  <front>
3695  <title>Analysis of HTTP Performance</title>
3696  <author initials="J." surname="Touch" fullname="Joe Touch">
3697    <organization>USC/Information Sciences Institute</organization>
3698    <address><email>touch@isi.edu</email></address>
3699  </author>
3700  <author initials="J." surname="Heidemann" fullname="John Heidemann">
3701    <organization>USC/Information Sciences Institute</organization>
3702    <address><email>johnh@isi.edu</email></address>
3703  </author>
3704  <author initials="K." surname="Obraczka" fullname="Katia Obraczka">
3705    <organization>USC/Information Sciences Institute</organization>
3706    <address><email>katia@isi.edu</email></address>
3707  </author>
3708  <date year="1998" month="Aug"/>
3709  </front>
3710  <seriesInfo name="ISI Research Report" value="ISI/RR-98-463"/>
3711  <annotation>(original report dated Aug. 1996)</annotation>
3712</reference>
3713
3714<reference anchor="WAIS">
3715  <front>
3716    <title>WAIS Interface Protocol Prototype Functional Specification (v1.5)</title>
3717    <author initials="F." surname="Davis" fullname="F. Davis">
3718      <organization>Thinking Machines Corporation</organization>
3719    </author>
3720    <author initials="B." surname="Kahle" fullname="B. Kahle">
3721      <organization>Thinking Machines Corporation</organization>
3722    </author>
3723    <author initials="H." surname="Morris" fullname="H. Morris">
3724      <organization>Thinking Machines Corporation</organization>
3725    </author>
3726    <author initials="J." surname="Salem" fullname="J. Salem">
3727      <organization>Thinking Machines Corporation</organization>
3728    </author>
3729    <author initials="T." surname="Shen" fullname="T. Shen">
3730      <organization>Thinking Machines Corporation</organization>
3731    </author>
3732    <author initials="R." surname="Wang" fullname="R. Wang">
3733      <organization>Thinking Machines Corporation</organization>
3734    </author>
3735    <author initials="J." surname="Sui" fullname="J. Sui">
3736      <organization>Thinking Machines Corporation</organization>
3737    </author>
3738    <author initials="M." surname="Grinbaum" fullname="M. Grinbaum">
3739      <organization>Thinking Machines Corporation</organization>
3740    </author>
3741    <date month="April" year="1990"/>
3742  </front>
3743  <seriesInfo name="Thinking Machines Corporation" value=""/>
3744</reference>
3745
3746</references>
3747
3748
3749<section title="Tolerant Applications" anchor="tolerant.applications">
3750<t>
3751   Although this document specifies the requirements for the generation
3752   of HTTP/1.1 messages, not all applications will be correct in their
3753   implementation. We therefore recommend that operational applications
3754   be tolerant of deviations whenever those deviations can be
3755   interpreted unambiguously.
3756</t>
3757<t>
3758   Clients SHOULD be tolerant in parsing the Status-Line and servers
3759   tolerant when parsing the Request-Line. In particular, they SHOULD
3760   accept any amount of SP or HTAB characters between fields, even though
3761   only a single SP is required.
3762</t>
3763<t>
3764   The line terminator for message-header fields is the sequence CRLF.
3765   However, we recommend that applications, when parsing such headers,
3766   recognize a single LF as a line terminator and ignore the leading CR.
3767</t>
3768<t>
3769   The character set of an entity-body SHOULD be labeled as the lowest
3770   common denominator of the character codes used within that body, with
3771   the exception that not labeling the entity is preferred over labeling
3772   the entity with the labels US-ASCII or ISO-8859-1. See <xref target="Part3"/>.
3773</t>
3774<t>
3775   Additional rules for requirements on parsing and encoding of dates
3776   and other potential problems with date encodings include:
3777</t>
3778<t>
3779  <list style="symbols">
3780     <t>HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
3781        which appears to be more than 50 years in the future is in fact
3782        in the past (this helps solve the "year 2000" problem).</t>
3783
3784     <t>An HTTP/1.1 implementation MAY internally represent a parsed
3785        Expires date as earlier than the proper value, but MUST NOT
3786        internally represent a parsed Expires date as later than the
3787        proper value.</t>
3788
3789     <t>All expiration-related calculations MUST be done in GMT. The
3790        local time zone MUST NOT influence the calculation or comparison
3791        of an age or expiration time.</t>
3792
3793     <t>If an HTTP header incorrectly carries a date value with a time
3794        zone other than GMT, it MUST be converted into GMT using the
3795        most conservative possible conversion.</t>
3796  </list>
3797</t>
3798</section>
3799
3800<section title="Conversion of Date Formats" anchor="conversion.of.date.formats">
3801<t>
3802   HTTP/1.1 uses a restricted set of date formats (<xref target="full.date"/>) to
3803   simplify the process of date comparison. Proxies and gateways from
3804   other protocols SHOULD ensure that any Date header field present in a
3805   message conforms to one of the HTTP/1.1 formats and rewrite the date
3806   if necessary.
3807</t>
3808</section>
3809
3810<section title="Compatibility with Previous Versions" anchor="compatibility">
3811<t>
3812   HTTP has been in use by the World-Wide Web global information initiative
3813   since 1990. The first version of HTTP, later referred to as HTTP/0.9,
3814   was a simple protocol for hypertext data transfer across the Internet
3815   with only a single method and no metadata.
3816   HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request
3817   methods and MIME-like messaging that could include metadata about the data
3818   transferred and modifiers on the request/response semantics. However,
3819   HTTP/1.0 did not sufficiently take into consideration the effects of
3820   hierarchical proxies, caching, the need for persistent connections, or
3821   name-based virtual hosts. The proliferation of incompletely-implemented
3822   applications calling themselves "HTTP/1.0" further necessitated a
3823   protocol version change in order for two communicating applications
3824   to determine each other's true capabilities.
3825</t>
3826<t>
3827   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
3828   requirements that enable reliable implementations, adding only
3829   those new features that will either be safely ignored by an HTTP/1.0
3830   recipient or only sent when communicating with a party advertising
3831   compliance with HTTP/1.1.
3832</t>
3833<t>
3834   It is beyond the scope of a protocol specification to mandate
3835   compliance with previous versions. HTTP/1.1 was deliberately
3836   designed, however, to make supporting previous versions easy. It is
3837   worth noting that, at the time of composing this specification
3838   (1996), we would expect commercial HTTP/1.1 servers to:
3839  <list style="symbols">
3840     <t>recognize the format of the Request-Line for HTTP/0.9, 1.0, and
3841        1.1 requests;</t>
3842
3843     <t>understand any valid request in the format of HTTP/0.9, 1.0, or
3844        1.1;</t>
3845
3846     <t>respond appropriately with a message in the same major version
3847        used by the client.</t>
3848  </list>
3849</t>
3850<t>
3851   And we would expect HTTP/1.1 clients to:
3852  <list style="symbols">
3853     <t>recognize the format of the Status-Line for HTTP/1.0 and 1.1
3854        responses;</t>
3855
3856     <t>understand any valid response in the format of HTTP/0.9, 1.0, or
3857        1.1.</t>
3858  </list>
3859</t>
3860<t>
3861   For most implementations of HTTP/1.0, each connection is established
3862   by the client prior to the request and closed by the server after
3863   sending the response. Some implementations implement the Keep-Alive
3864   version of persistent connections described in Section 19.7.1 of <xref target="RFC2068"/>.
3865</t>
3866
3867<section title="Changes from HTTP/1.0" anchor="changes.from.1.0">
3868<t>
3869   This section summarizes major differences between versions HTTP/1.0
3870   and HTTP/1.1.
3871</t>
3872
3873<section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
3874<t>
3875   The requirements that clients and servers support the Host request-header,
3876   report an error if the Host request-header (<xref target="header.host"/>) is
3877   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-uri"/>)
3878   are among the most important changes defined by this
3879   specification.
3880</t>
3881<t>
3882   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
3883   addresses and servers; there was no other established mechanism for
3884   distinguishing the intended server of a request than the IP address
3885   to which that request was directed. The changes outlined above will
3886   allow the Internet, once older HTTP clients are no longer common, to
3887   support multiple Web sites from a single IP address, greatly
3888   simplifying large operational Web servers, where allocation of many
3889   IP addresses to a single host has created serious problems. The
3890   Internet will also be able to recover the IP addresses that have been
3891   allocated for the sole purpose of allowing special-purpose domain
3892   names to be used in root-level HTTP URLs. Given the rate of growth of
3893   the Web, and the number of servers already deployed, it is extremely
3894   important that all implementations of HTTP (including updates to
3895   existing HTTP/1.0 applications) correctly implement these
3896   requirements:
3897  <list style="symbols">
3898     <t>Both clients and servers MUST support the Host request-header.</t>
3899
3900     <t>A client that sends an HTTP/1.1 request MUST send a Host header.</t>
3901
3902     <t>Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
3903        request does not include a Host request-header.</t>
3904
3905     <t>Servers MUST accept absolute URIs.</t>
3906  </list>
3907</t>
3908</section>
3909</section>
3910
3911<section title="Compatibility with HTTP/1.0 Persistent Connections" anchor="compatibility.with.http.1.0.persistent.connections">
3912<t>
3913   Some clients and servers might wish to be compatible with some
3914   previous implementations of persistent connections in HTTP/1.0
3915   clients and servers. Persistent connections in HTTP/1.0 are
3916   explicitly negotiated as they are not the default behavior. HTTP/1.0
3917   experimental implementations of persistent connections are faulty,
3918   and the new facilities in HTTP/1.1 are designed to rectify these
3919   problems. The problem was that some existing 1.0 clients may be
3920   sending Keep-Alive to a proxy server that doesn't understand
3921   Connection, which would then erroneously forward it to the next
3922   inbound server, which would establish the Keep-Alive connection and
3923   result in a hung HTTP/1.0 proxy waiting for the close on the
3924   response. The result is that HTTP/1.0 clients must be prevented from
3925   using Keep-Alive when talking to proxies.
3926</t>
3927<t>
3928   However, talking to proxies is the most important use of persistent
3929   connections, so that prohibition is clearly unacceptable. Therefore,
3930   we need some other mechanism for indicating a persistent connection
3931   is desired, which is safe to use even when talking to an old proxy
3932   that ignores Connection. Persistent connections are the default for
3933   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
3934   declaring non-persistence. See <xref target="header.connection"/>.
3935</t>
3936<t>
3937   The original HTTP/1.0 form of persistent connections (the Connection:
3938   Keep-Alive and Keep-Alive header) is documented in <xref target="RFC2068"/>.
3939</t>
3940</section>
3941
3942<section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
3943<t>
3944   This specification has been carefully audited to correct and
3945   disambiguate key word usage; RFC 2068 had many problems in respect to
3946   the conventions laid out in <xref target="RFC2119"/>.
3947</t>
3948<t>
3949   Transfer-coding and message lengths all interact in ways that
3950   required fixing exactly when chunked encoding is used (to allow for
3951   transfer encoding that may not be self delimiting); it was important
3952   to straighten out exactly how message lengths are computed. (Sections
3953   <xref target="transfer.codings" format="counter"/>, <xref target="message.length" format="counter"/>,
3954   <xref target="header.content-length" format="counter"/>,
3955   see also <xref target="Part3"/>, <xref target="Part5"/> and <xref target="Part6"/>)
3956</t>
3957<t>
3958   The use and interpretation of HTTP version numbers has been clarified
3959   by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol
3960   version they support to deal with problems discovered in HTTP/1.0
3961   implementations (<xref target="http.version"/>)
3962</t>
3963<t>
3964   Transfer-coding had significant problems, particularly with
3965   interactions with chunked encoding. The solution is that transfer-codings
3966   become as full fledged as content-codings. This involves
3967   adding an IANA registry for transfer-codings (separate from content
3968   codings), a new header field (TE) and enabling trailer headers in the
3969   future. Transfer encoding is a major performance benefit, so it was
3970   worth fixing <xref target="Nie1997"/>. TE also solves another, obscure, downward
3971   interoperability problem that could have occurred due to interactions
3972   between authentication trailers, chunked encoding and HTTP/1.0
3973   clients.(Section <xref target="transfer.codings" format="counter"/>, <xref target="chunked.transfer.encoding" format="counter"/>,
3974   and <xref target="header.te" format="counter"/>)
3975</t>
3976</section>
3977
3978<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
3979<t>
3980  Rules about implicit linear white space between certain grammar productions
3981  have been removed; now it's only allowed when specifically pointed out
3982  in the ABNF.
3983  The CHAR rule does not allow the NUL character anymore (this affects
3984  the comment and quoted-string rules).  Furthermore, the quoted-pair
3985  rule does not allow escaping NUL, CR or LF anymore.
3986  (<xref target="basic.rules"/>)
3987</t>
3988<t>
3989  Clarify that HTTP-Version is case sensitive.
3990  (<xref target="http.version"/>)
3991</t>
3992<t>
3993  Remove reference to non-existant identity transfer-coding value tokens.
3994  (Sections <xref format="counter" target="transfer.codings"/> and
3995  <xref format="counter" target="message.length"/>)
3996</t>
3997<t>
3998  Clarification that the chunk length does not include
3999  the count of the octets in the chunk header and trailer.
4000  (<xref target="chunked.transfer.encoding"/>)
4001</t>
4002<t>
4003  Update use of abs_path production from RFC1808 to the path-absolute + query
4004  components of RFC3986.
4005  (<xref target="request-uri"/>)
4006</t>
4007<t>
4008  Clarify exactly when close connection options must be sent.
4009  (<xref target="header.connection"/>)
4010</t>
4011</section>
4012</section>
4013
4014<section title="Terminology" anchor="terminology">
4015<t>
4016   This specification uses a number of terms to refer to the roles
4017   played by participants in, and objects of, the HTTP communication.
4018</t>
4019<t>
4020  <iref item="connection"/>
4021  connection
4022  <list>
4023    <t>
4024      A transport layer virtual circuit established between two programs
4025      for the purpose of communication.
4026    </t>
4027  </list>
4028</t>
4029<t>
4030  <iref item="message"/>
4031  message
4032  <list>
4033    <t>
4034      The basic unit of HTTP communication, consisting of a structured
4035      sequence of octets matching the syntax defined in <xref target="http.message"/> and
4036      transmitted via the connection.
4037    </t>
4038  </list>
4039</t>
4040<t>
4041  <iref item="request"/>
4042  request
4043  <list>
4044    <t>
4045      An HTTP request message, as defined in <xref target="request"/>.
4046    </t>
4047  </list>
4048</t>
4049<t>
4050  <iref item="response"/>
4051  response
4052  <list>
4053    <t>
4054      An HTTP response message, as defined in <xref target="response"/>.
4055    </t>
4056  </list>
4057</t>
4058<t>
4059  <iref item="resource"/>
4060  resource
4061  <list>
4062    <t>
4063      A network data object or service that can be identified by a URI,
4064      as defined in <xref target="uri"/>. Resources may be available in multiple
4065      representations (e.g. multiple languages, data formats, size, and
4066      resolutions) or vary in other ways.
4067    </t>
4068  </list>
4069</t>
4070<t>
4071  <iref item="entity"/>
4072  entity
4073  <list>
4074    <t>
4075      The information transferred as the payload of a request or
4076      response. An entity consists of metainformation in the form of
4077      entity-header fields and content in the form of an entity-body, as
4078      described in Section 4 of <xref target="Part3"/>.
4079    </t>
4080  </list>
4081</t>
4082<t>
4083  <iref item="representation"/>
4084  representation
4085  <list>
4086    <t>
4087      An entity included with a response that is subject to content
4088      negotiation, as described in Section 5 of <xref target="Part3"/>. There may exist multiple
4089      representations associated with a particular response status.
4090    </t>
4091  </list>
4092</t>
4093<t>
4094  <iref item="content negotiation"/>
4095  content negotiation
4096  <list>
4097    <t>
4098      The mechanism for selecting the appropriate representation when
4099      servicing a request, as described in Section 5 of <xref target="Part3"/>. The
4100      representation of entities in any response can be negotiated
4101      (including error responses).
4102    </t>
4103  </list>
4104</t>
4105<t>
4106  <iref item="variant"/>
4107  variant
4108  <list>
4109    <t>
4110      A resource may have one, or more than one, representation(s)
4111      associated with it at any given instant. Each of these
4112      representations is termed a `variant'.  Use of the term `variant'
4113      does not necessarily imply that the resource is subject to content
4114      negotiation.
4115    </t>
4116  </list>
4117</t>
4118<t>
4119  <iref item="client"/>
4120  client
4121  <list>
4122    <t>
4123      A program that establishes connections for the purpose of sending
4124      requests.
4125    </t>
4126  </list>
4127</t>
4128<t>
4129  <iref item="user agent"/>
4130  user agent
4131  <list>
4132    <t>
4133      The client which initiates a request. These are often browsers,
4134      editors, spiders (web-traversing robots), or other end user tools.
4135    </t>
4136  </list>
4137</t>
4138<t>
4139  <iref item="server"/>
4140  server
4141  <list>
4142    <t>
4143      An application program that accepts connections in order to
4144      service requests by sending back responses. Any given program may
4145      be capable of being both a client and a server; our use of these
4146      terms refers only to the role being performed by the program for a
4147      particular connection, rather than to the program's capabilities
4148      in general. Likewise, any server may act as an origin server,
4149      proxy, gateway, or tunnel, switching behavior based on the nature
4150      of each request.
4151    </t>
4152  </list>
4153</t>
4154<t>
4155  <iref item="origin server"/>
4156  origin server
4157  <list>
4158    <t>
4159      The server on which a given resource resides or is to be created.
4160    </t>
4161  </list>
4162</t>
4163<t>
4164  <iref item="proxy"/>
4165  proxy
4166  <list>
4167    <t>
4168      An intermediary program which acts as both a server and a client
4169      for the purpose of making requests on behalf of other clients.
4170      Requests are serviced internally or by passing them on, with
4171      possible translation, to other servers. A proxy MUST implement
4172      both the client and server requirements of this specification. A
4173      "transparent proxy" is a proxy that does not modify the request or
4174      response beyond what is required for proxy authentication and
4175      identification. A "non-transparent proxy" is a proxy that modifies
4176      the request or response in order to provide some added service to
4177      the user agent, such as group annotation services, media type
4178      transformation, protocol reduction, or anonymity filtering. Except
4179      where either transparent or non-transparent behavior is explicitly
4180      stated, the HTTP proxy requirements apply to both types of
4181      proxies.
4182    </t>
4183  </list>
4184</t>
4185<t>
4186  <iref item="gateway"/>
4187  gateway
4188  <list>
4189    <t>
4190      A server which acts as an intermediary for some other server.
4191      Unlike a proxy, a gateway receives requests as if it were the
4192      origin server for the requested resource; the requesting client
4193      may not be aware that it is communicating with a gateway.
4194    </t>
4195  </list>
4196</t>
4197<t>
4198  <iref item="tunnel"/>
4199  tunnel
4200  <list>
4201    <t>
4202      An intermediary program which is acting as a blind relay between
4203      two connections. Once active, a tunnel is not considered a party
4204      to the HTTP communication, though the tunnel may have been
4205      initiated by an HTTP request. The tunnel ceases to exist when both
4206      ends of the relayed connections are closed.
4207    </t>
4208  </list>
4209</t>
4210<t>
4211  <iref item="cache"/>
4212  cache
4213  <list>
4214    <t>
4215      A program's local store of response messages and the subsystem
4216      that controls its message storage, retrieval, and deletion. A
4217      cache stores cacheable responses in order to reduce the response
4218      time and network bandwidth consumption on future, equivalent
4219      requests. Any client or server may include a cache, though a cache
4220      cannot be used by a server that is acting as a tunnel.
4221    </t>
4222  </list>
4223</t>
4224<t>
4225  <iref item="cacheable"/>
4226  cacheable
4227  <list>
4228    <t>
4229      A response is cacheable if a cache is allowed to store a copy of
4230      the response message for use in answering subsequent requests. The
4231      rules for determining the cacheability of HTTP responses are
4232      defined in Section 1 of <xref target="Part6"/>. Even if a resource is cacheable, there may
4233      be additional constraints on whether a cache can use the cached
4234      copy for a particular request.
4235    </t>
4236  </list>
4237</t>
4238<t>
4239  <iref item="upstream"/>
4240  <iref item="downstream"/>
4241  upstream/downstream
4242  <list>
4243    <t>
4244      Upstream and downstream describe the flow of a message: all
4245      messages flow from upstream to downstream.
4246    </t>
4247  </list>
4248</t>
4249<t>
4250  <iref item="inbound"/>
4251  <iref item="outbound"/>
4252  inbound/outbound
4253  <list>
4254    <t>
4255      Inbound and outbound refer to the request and response paths for
4256      messages: "inbound" means "traveling toward the origin server",
4257      and "outbound" means "traveling toward the user agent"
4258    </t>
4259  </list>
4260</t>
4261</section>
4262
4263<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
4264
4265<section title="Since RFC2616">
4266<t>
4267  Extracted relevant partitions from <xref target="RFC2616"/>.
4268</t>
4269</section>
4270
4271<section title="Since draft-ietf-httpbis-p1-messaging-00">
4272<t>
4273  Closed issues:
4274  <list style="symbols"> 
4275    <t>
4276      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/1"/>:
4277      "HTTP Version should be case sensitive"
4278      (<eref target="http://purl.org/NET/http-errata#verscase"/>)
4279    </t>
4280    <t>
4281      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/2"/>:
4282      "'unsafe' characters"
4283      (<eref target="http://purl.org/NET/http-errata#unsafe-uri"/>)
4284    </t>
4285    <t>
4286      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/3"/>:
4287      "Chunk Size Definition"
4288      (<eref target="http://purl.org/NET/http-errata#chunk-size"/>)
4289    </t>
4290    <t>
4291      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/4"/>:
4292      "Message Length"
4293      (<eref target="http://purl.org/NET/http-errata#msg-len-chars"/>)
4294    </t>
4295    <t>
4296      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/8"/>:
4297      "Media Type Registrations"
4298      (<eref target="http://purl.org/NET/http-errata#media-reg"/>)
4299    </t>
4300    <t>
4301      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/11"/>:
4302      "URI includes query"
4303      (<eref target="http://purl.org/NET/http-errata#uriquery"/>)
4304    </t>
4305    <t>
4306      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/15"/>:
4307      "No close on 1xx responses"
4308      (<eref target="http://purl.org/NET/http-errata#noclose1xx"/>)
4309    </t>
4310    <t>
4311      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/16"/>:
4312      "Remove 'identity' token references"
4313      (<eref target="http://purl.org/NET/http-errata#identity"/>)
4314    </t>
4315    <t>
4316      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/26"/>:
4317      "Import query BNF"
4318    </t>
4319    <t>
4320      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/31"/>:
4321      "qdtext BNF"
4322    </t>
4323    <t>
4324      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
4325      "Normative and Informative references"
4326    </t>
4327    <t>
4328      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/42"/>:
4329      "RFC2606 Compliance"
4330    </t>
4331    <t>
4332      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/45"/>:
4333      "RFC977 reference"
4334    </t>
4335    <t>
4336      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/46"/>:
4337      "RFC1700 references"
4338    </t>
4339    <t>
4340      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/47"/>:
4341      "inconsistency in date format explanation"
4342    </t>
4343    <t>
4344      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/48"/>:
4345      "Date reference typo"
4346    </t>
4347    <t>
4348      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>:
4349      "Informative references"
4350    </t>
4351    <t>
4352      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/66"/>:
4353      "ISO-8859-1 Reference"
4354    </t>
4355    <t>
4356      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86"/>:
4357      "Normative up-to-date references"
4358    </t>
4359  </list>
4360</t>
4361<t>
4362  Other changes:
4363  <list style="symbols"> 
4364    <t>
4365      Update media type registrations to use RFC4288 template.
4366    </t>
4367    <t>
4368      Use names of RFC4234 core rules DQUOTE and HTAB,
4369      fix broken ABNF for chunk-data
4370      (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>)
4371    </t>
4372  </list>
4373</t>
4374</section>
4375
4376<section title="Since draft-ietf-httpbis-p1-messaging-01">
4377<t>
4378  Closed issues:
4379  <list style="symbols"> 
4380    <t>
4381      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/19"/>:
4382      "Bodies on GET (and other) requests"
4383    </t>
4384    <t>
4385      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/55"/>:
4386      "Updating to RFC4288"
4387    </t>
4388    <t>
4389      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/57"/>:
4390      "Status Code and Reason Phrase"
4391    </t>
4392    <t>
4393      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/82"/>:
4394      "rel_path not used"
4395    </t>
4396  </list>
4397</t>
4398<t>
4399  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
4400  <list style="symbols"> 
4401    <t>
4402      Get rid of duplicate BNF rule names ("host" -&gt; "uri-host", "trailer" -&gt;
4403      "trailer-part").
4404    </t>
4405    <t>
4406      Avoid underscore character in rule names ("http_URL" -&gt;
4407      "http-URL", "abs_path" -&gt; "path-absolute").
4408    </t>
4409    <t>
4410      Add rules for terms imported from URI spec ("absoluteURI", "authority",
4411      "path-absolute", "port", "query", "relativeURI", "host) -- these will
4412      have to be updated when switching over to RFC3986.
4413    </t>
4414    <t>
4415      Synchronize core rules with RFC5234 (this includes a change to CHAR
4416      which now excludes NUL).
4417    </t>
4418    <t>
4419      Get rid of prose rules that span multiple lines.
4420    </t>
4421    <t>
4422      Get rid of unused rules LOALPHA and UPALPHA.
4423    </t>
4424    <t>
4425      Move "Product Tokens" section (back) into Part 1, as "token" is used
4426      in the definition of the Upgrade header.
4427    </t>
4428    <t>
4429      Add explicit references to BNF syntax and rules imported from other parts of the specification.
4430    </t>
4431    <t>
4432      Rewrite prose rule "token" in terms of "tchar", rewrite prose rule "TEXT".
4433    </t>
4434  </list>
4435</t>
4436</section>
4437
4438<section title="Since draft-ietf-httpbis-p1-messaging-02" anchor="changes.since.02">
4439<t>
4440  Closed issues:
4441  <list style="symbols"> 
4442    <t>
4443      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/51"/>:
4444      "HTTP-date vs. rfc1123-date"
4445    </t>
4446    <t>
4447      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/64"/>:
4448      "WS in quoted-pair"
4449    </t>
4450  </list>
4451</t>
4452<t>
4453  Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
4454  <list style="symbols"> 
4455    <t>
4456      Reference RFC 3984, and update header registrations for headers defined
4457      in this document.
4458    </t>
4459  </list>
4460</t>
4461<t>
4462  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
4463  <list style="symbols"> 
4464    <t>
4465      Replace string literals when the string really is case-sensitive (HTTP-Version).
4466    </t>
4467  </list>
4468</t>
4469</section>
4470
4471<section title="Since draft-ietf-httpbis-p1-messaging-03" anchor="changes.since.03">
4472<t>
4473  Closed issues:
4474  <list style="symbols"> 
4475    <t>
4476      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/28"/>:
4477      "Connection closing"
4478    </t>
4479    <t>
4480      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/97"/>:
4481      "Move registrations and registry information to IANA Considerations"
4482    </t>
4483    <t>
4484      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/120"/>:
4485      "need new URL for PAD1995 reference"
4486    </t>
4487    <t>
4488      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/127"/>:
4489      "IANA Considerations: update HTTP URI scheme registration"
4490    </t>
4491    <t>
4492      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/128"/>:
4493      "Cite HTTPS URI scheme definition"
4494    </t>
4495    <t>
4496      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/129"/>:
4497      "List-type headers vs Set-Cookie"
4498    </t>
4499  </list>
4500</t>
4501<t>
4502  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
4503  <list style="symbols"> 
4504    <t>
4505      Replace string literals when the string really is case-sensitive (HTTP-Date).
4506    </t>
4507    <t>
4508      Replace HEX by HEXDIG for future consistence with RFC 5234's core rules.
4509    </t>
4510  </list>
4511</t>
4512</section>
4513
4514<section title="Since draft-ietf-httpbis-p1-messaging-04" anchor="changes.since.04">
4515<t>
4516  Closed issues:
4517  <list style="symbols"> 
4518    <t>
4519      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/34"/>:
4520      "Out-of-date reference for URIs"
4521    </t>
4522    <t>
4523      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>:
4524      "RFC 2822 is updated by RFC 5322"
4525    </t>
4526  </list>
4527</t>
4528<t>
4529  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
4530  <list style="symbols"> 
4531    <t>
4532      Use "/" instead of "|" for alternatives.
4533    </t>
4534    <t>
4535      Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
4536    </t>
4537    <t>
4538      Only reference RFC 5234's core rules.
4539    </t>
4540    <t>
4541      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
4542      whitespace ("OWS") and required whitespace ("RWS").
4543    </t>
4544    <t>
4545      Rewrite ABNFs to spell out whitespace rules, factor out
4546      header value format definitions.
4547    </t>
4548  </list>
4549</t>
4550</section>
4551
4552</section>
4553
4554</back>
4555</rfc>
Note: See TracBrowser for help on using the repository browser.