source: draft-ietf-httpbis/07/draft-ietf-httpbis-p1-messaging-07.xml @ 653

Last change on this file since 653 was 609, checked in by julian.reschke@…, 10 years ago

HTAB cleanup (not even editorial)

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