source: draft-ietf-httpbis/15/draft-ietf-httpbis-p1-messaging-15.xml @ 1391

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

Prepare publication of -15 on 2011-07-11

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