source: draft-ietf-httpbis/latest/p1-messaging.xml @ 1471

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

Add a note about non-final responses to Client/Server? Messaging introduction (see #300)

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