source: draft-ietf-httpbis/latest/p3-payload.xml @ 1465

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

indentation (no spec change)

  • Property svn:eol-style set to native
File size: 124.9 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
3<!DOCTYPE rfc [
4  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
5  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
6  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
7  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
8  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
9  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
10  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
11  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
12  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
13  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
14  <!ENTITY ID-VERSION "latest">
15  <!ENTITY ID-MONTH "October">
16  <!ENTITY ID-YEAR "2011">
17  <!ENTITY mdash "&#8212;">
18  <!ENTITY architecture             "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
19  <!ENTITY notation                 "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
20  <!ENTITY notation-abnf            "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
21  <!ENTITY acks                     "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
22  <!ENTITY basic-rules              "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
23  <!ENTITY field-rules              "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
24  <!ENTITY caching-neg-resp         "<xref target='Part6' x:rel='#caching.negotiated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
25  <!ENTITY header-transfer-encoding "<xref target='Part1' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
26  <!ENTITY header-content-length    "<xref target='Part1' x:rel='#header.content-length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
27  <!ENTITY header-content-range     "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
28  <!ENTITY header-expires           "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
29  <!ENTITY header-last-modified     "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
30  <!ENTITY header-user-agent        "<xref target='Part2' x:rel='#header.user-agent' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
31  <!ENTITY header-vary              "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
32  <!ENTITY message-body             "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
33  <!ENTITY multipart-byteranges     "<xref target='Part5' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
34  <!ENTITY http-date                "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
35  <!ENTITY qvalue                   "<xref target='Part1' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
36  <!ENTITY uri                      "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
37  <!ENTITY effective-request-uri    "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
38  <!ENTITY compression-codings      "<xref target='Part1' x:rel='#compression.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
39  <!ENTITY transfer-codings         "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
40  <!ENTITY compress-coding          "<xref target='Part1' x:rel='#compress.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
41  <!ENTITY deflate-coding           "<xref target='Part1' x:rel='#deflate.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
42  <!ENTITY gzip-coding              "<xref target='Part1' x:rel='#gzip.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
43  <!ENTITY response-representation  "<xref target='Part2' x:rel='#identifying.response.associated.with.representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
44]>
45<?rfc toc="yes" ?>
46<?rfc symrefs="yes" ?>
47<?rfc sortrefs="yes" ?>
48<?rfc compact="yes"?>
49<?rfc subcompact="no" ?>
50<?rfc linkmailto="no" ?>
51<?rfc editing="no" ?>
52<?rfc comments="yes"?>
53<?rfc inline="yes"?>
54<?rfc rfcedstyle="yes"?>
55<?rfc-ext allow-markup-in-artwork="yes" ?>
56<?rfc-ext include-references-in-index="yes" ?>
57<rfc obsoletes="2616" category="std" x:maturity-level="draft"
58     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p3-payload-&ID-VERSION;"
59     xmlns:x='http://purl.org/net/xml2rfc/ext'>
60<front>
61
62  <title abbrev="HTTP/1.1, Part 3">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
63
64  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
65    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
66    <address>
67      <postal>
68        <street>345 Park Ave</street>
69        <city>San Jose</city>
70        <region>CA</region>
71        <code>95110</code>
72        <country>USA</country>
73      </postal>
74      <email>fielding@gbiv.com</email>
75      <uri>http://roy.gbiv.com/</uri>
76    </address>
77  </author>
78
79  <author initials="J." surname="Gettys" fullname="Jim Gettys">
80    <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
81    <address>
82      <postal>
83        <street>21 Oak Knoll Road</street>
84        <city>Carlisle</city>
85        <region>MA</region>
86        <code>01741</code>
87        <country>USA</country>
88      </postal>
89      <email>jg@freedesktop.org</email>
90      <uri>http://gettys.wordpress.com/</uri>
91    </address>
92  </author>
93 
94  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
95    <organization abbrev="HP">Hewlett-Packard Company</organization>
96    <address>
97      <postal>
98        <street>HP Labs, Large Scale Systems Group</street>
99        <street>1501 Page Mill Road, MS 1177</street>
100        <city>Palo Alto</city>
101        <region>CA</region>
102        <code>94304</code>
103        <country>USA</country>
104      </postal>
105      <email>JeffMogul@acm.org</email>
106    </address>
107  </author>
108
109  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
110    <organization abbrev="Microsoft">Microsoft Corporation</organization>
111    <address>
112      <postal>
113        <street>1 Microsoft Way</street>
114        <city>Redmond</city>
115        <region>WA</region>
116        <code>98052</code>
117        <country>USA</country>
118      </postal>
119      <email>henrikn@microsoft.com</email>
120    </address>
121  </author>
122
123  <author initials="L." surname="Masinter" fullname="Larry Masinter">
124    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
125    <address>
126      <postal>
127        <street>345 Park Ave</street>
128        <city>San Jose</city>
129        <region>CA</region>
130        <code>95110</code>
131        <country>USA</country>
132      </postal>
133      <email>LMM@acm.org</email>
134      <uri>http://larry.masinter.net/</uri>
135    </address>
136  </author>
137 
138  <author initials="P." surname="Leach" fullname="Paul J. Leach">
139    <organization abbrev="Microsoft">Microsoft Corporation</organization>
140    <address>
141      <postal>
142        <street>1 Microsoft Way</street>
143        <city>Redmond</city>
144        <region>WA</region>
145        <code>98052</code>
146      </postal>
147      <email>paulle@microsoft.com</email>
148    </address>
149  </author>
150   
151  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
152    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
153    <address>
154      <postal>
155        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
156        <street>The Stata Center, Building 32</street>
157        <street>32 Vassar Street</street>
158        <city>Cambridge</city>
159        <region>MA</region>
160        <code>02139</code>
161        <country>USA</country>
162      </postal>
163      <email>timbl@w3.org</email>
164      <uri>http://www.w3.org/People/Berners-Lee/</uri>
165    </address>
166  </author>
167
168  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
169    <organization abbrev="W3C">World Wide Web Consortium</organization>
170    <address>
171      <postal>
172        <street>W3C / ERCIM</street>
173        <street>2004, rte des Lucioles</street>
174        <city>Sophia-Antipolis</city>
175        <region>AM</region>
176        <code>06902</code>
177        <country>France</country>
178      </postal>
179      <email>ylafon@w3.org</email>
180      <uri>http://www.raubacapeu.net/people/yves/</uri>
181    </address>
182  </author>
183
184  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
185    <organization abbrev="greenbytes">greenbytes GmbH</organization>
186    <address>
187      <postal>
188        <street>Hafenweg 16</street>
189        <city>Muenster</city><region>NW</region><code>48155</code>
190        <country>Germany</country>
191      </postal>
192      <phone>+49 251 2807760</phone>
193      <facsimile>+49 251 2807761</facsimile>
194      <email>julian.reschke@greenbytes.de</email>
195      <uri>http://greenbytes.de/tech/webdav/</uri>
196    </address>
197  </author>
198
199  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
200  <workgroup>HTTPbis Working Group</workgroup>
201
202<abstract>
203<t>
204   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
205   distributed, collaborative, hypertext information systems. HTTP has been in
206   use by the World Wide Web global information initiative since 1990. This
207   document is Part 3 of the seven-part specification that defines the protocol
208   referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
209</t>
210<t>
211   Part 3 defines HTTP message content, metadata, and content negotiation.
212</t>
213</abstract>
214
215<note title="Editorial Note (To be removed by RFC Editor)">
216  <t>
217    Discussion of this draft should take place on the HTTPBIS working group
218    mailing list (ietf-http-wg@w3.org), which is archived at
219    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
220  </t>
221  <t>
222    The current issues list is at
223    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
224    documents (including fancy diffs) can be found at
225    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
226  </t>
227  <t>
228    The changes in this draft are summarized in <xref target="changes.since.16"/>.
229  </t>
230</note>
231</front>
232<middle>
233<section title="Introduction" anchor="introduction">
234<t>
235   This document defines HTTP/1.1 message payloads (a.k.a., content), the
236   associated metadata header fields that define how the payload is intended
237   to be interpreted by a recipient, the request header fields that
238   might influence content selection, and the various selection algorithms
239   that are collectively referred to as HTTP content negotiation.
240</t>
241<t>
242   This document is currently disorganized in order to minimize the changes
243   between drafts and enable reviewers to see the smaller errata changes.
244   A future draft will reorganize the sections to better reflect the content.
245   In particular, the sections on entities will be renamed payload and moved
246   to the first half of the document, while the sections on content negotiation
247   and associated request header fields will be moved to the second half.  The
248   current mess reflects how widely dispersed these topics and associated
249   requirements had become in <xref target="RFC2616"/>.
250</t>
251
252<section title="Terminology" anchor="terminology">
253<t>
254   This specification uses a number of terms to refer to the roles
255   played by participants in, and objects of, the HTTP communication.
256</t>
257<t>
258  <iref item="content negotiation"/>
259  <x:dfn>content negotiation</x:dfn>
260  <list>
261    <t>
262      The mechanism for selecting the appropriate representation when
263      servicing a request. The representation in any response
264      can be negotiated (including error responses).
265    </t>
266  </list>
267</t>
268</section>
269
270<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
271<t>
272   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
273   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
274   document are to be interpreted as described in <xref target="RFC2119"/>.
275</t>
276<t>
277   This document defines conformance criteria for several roles in HTTP
278   communication, including Senders, Recipients, Clients, Servers, User-Agents,
279   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
280   for definitions of these terms.
281</t>
282<t>
283   An implementation is considered conformant if it complies with all of the
284   requirements associated with its role(s). Note that SHOULD-level requirements
285   are relevant here, unless one of the documented exceptions is applicable.
286</t>
287<t>
288   This document also uses ABNF to define valid protocol elements
289   (<xref target="notation"/>). In addition to the prose requirements placed
290   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
291</t>
292<t>
293   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
294   protocol element from an invalid construct. However, HTTP does not define
295   specific error handling mechanisms, except in cases where it has direct
296   impact on security. This is because different uses of the protocol require
297   different error handling strategies; for example, a Web browser may wish to
298   transparently recover from a response where the Location header field
299   doesn't parse according to the ABNF, whereby in a systems control protocol
300   using HTTP, this type of error recovery could lead to dangerous consequences.
301</t>
302</section>
303
304<section title="Syntax Notation" anchor="notation">
305  <x:anchor-alias value="ALPHA"/>
306  <x:anchor-alias value="CR"/>
307  <x:anchor-alias value="DIGIT"/>
308  <x:anchor-alias value="LF"/>
309  <x:anchor-alias value="OCTET"/>
310  <x:anchor-alias value="VCHAR"/>
311<t>
312  This specification uses the ABNF syntax defined in &notation; (which
313  extends the syntax defined in <xref target="RFC5234"/> with a list rule).
314  <xref target="collected.abnf"/> shows the collected ABNF, with the list
315  rule expanded.
316</t>
317<t>
318  The following core rules are included by
319  reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
320  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
321  DIGIT (decimal 0-9), DQUOTE (double quote),
322  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
323  OCTET (any 8-bit sequence of data), SP (space), and
324  VCHAR (any visible US-ASCII character).
325</t>
326
327<section title="Core Rules" anchor="core.rules">
328  <x:anchor-alias value="token"/>
329  <x:anchor-alias value="word"/>
330  <x:anchor-alias value="OWS"/>
331<t>
332  The core rules below are defined in <xref target="Part1"/>:
333</t>
334<figure><artwork type="abnf2616">
335  <x:ref>OWS</x:ref>            = &lt;OWS, defined in &basic-rules;&gt;
336  <x:ref>token</x:ref>          = &lt;token, defined in &field-rules;&gt;
337  <x:ref>word</x:ref>           = &lt;word, defined in &field-rules;&gt;
338</artwork></figure>
339</section>
340
341<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
342  <x:anchor-alias value="absolute-URI"/>
343  <x:anchor-alias value="partial-URI"/>
344  <x:anchor-alias value="qvalue"/>
345<t>
346  The ABNF rules below are defined in other parts:
347</t>
348<figure><!--Part1--><artwork type="abnf2616">
349  <x:ref>absolute-URI</x:ref>   = &lt;absolute-URI, defined in &uri;&gt;
350  <x:ref>partial-URI</x:ref>    = &lt;partial-URI, defined in &uri;&gt;
351  <x:ref>qvalue</x:ref>         = &lt;qvalue, defined in &qvalue;&gt;
352</artwork></figure>
353</section>
354
355</section>
356
357</section>
358
359<section title="Protocol Parameters" anchor="protocol.parameters">
360
361<section title="Character Encodings (charset)" anchor="character.sets">
362<t>
363   HTTP uses charset names to indicate the character encoding of a
364   textual representation.
365</t>
366<t anchor="rule.charset">
367  <x:anchor-alias value="charset"/>
368   A character encoding is identified by a case-insensitive token. The
369   complete set of tokens is defined by the IANA Character Set registry
370   (<eref target="http://www.iana.org/assignments/character-sets"/>).
371</t>
372<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
373  <x:ref>charset</x:ref> = <x:ref>token</x:ref>
374</artwork></figure>
375<t>
376   Although HTTP allows an arbitrary token to be used as a charset
377   value, any token that has a predefined value within the IANA
378   Character Set registry &MUST; represent the character encoding defined
379   by that registry. Applications &SHOULD; limit their use of character
380   encodings to those defined within the IANA registry.
381</t>
382<t>
383   HTTP uses charset in two contexts: within an Accept-Charset request
384   header field (in which the charset value is an unquoted token) and as the
385   value of a parameter in a Content-Type header field (within a request or
386   response), in which case the parameter value of the charset parameter
387   can be quoted.
388</t>
389<t>
390   Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/>
391   <xref target="RFC2277"/>.
392</t>
393</section>
394
395<section title="Content Codings" anchor="content.codings">
396  <x:anchor-alias value="content-coding"/>
397<t>
398   Content coding values indicate an encoding transformation that has
399   been or can be applied to a representation. Content codings are primarily
400   used to allow a representation to be compressed or otherwise usefully
401   transformed without losing the identity of its underlying media type
402   and without loss of information. Frequently, the representation is stored in
403   coded form, transmitted directly, and only decoded by the recipient.
404</t>
405<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
406  <x:ref>content-coding</x:ref>   = <x:ref>token</x:ref>
407</artwork></figure>
408<t>
409   All content-coding values are case-insensitive. HTTP/1.1 uses
410   content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
411   Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
412   describes the content-coding, what is more important is that it
413   indicates what decoding mechanism will be required to remove the
414   encoding.
415</t>
416<t>
417   compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/>
418  <list>
419    <t>
420      See &compress-coding;.
421    </t>
422  </list>
423</t>
424<t>
425   deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/>
426  <list>
427    <t>
428      See &deflate-coding;.
429    </t>
430  </list>
431</t>
432<t>
433   gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/>
434  <list>
435    <t>
436      See &gzip-coding;.
437    </t>
438  </list>
439</t>
440
441<section title="Content Coding Registry" anchor="content.coding.registry">
442<t>
443   The HTTP Content Coding Registry defines the name space for the content
444   coding names.
445</t>
446<t>
447   Registrations &MUST; include the following fields:
448   <list style="symbols">
449     <t>Name</t>
450     <t>Description</t>
451     <t>Pointer to specification text</t>
452   </list>
453</t>
454<t>
455   Names of content codings &MUST-NOT; overlap with names of transfer codings
456   (&transfer-codings;), unless the encoding transformation is identical (as it
457   is the case for the compression codings defined in
458   &compression-codings;).
459</t>
460<t>
461   Values to be added to this name space require a specification
462   (see "Specification Required" in
463   <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
464   conform to the purpose of content coding defined in this section.
465</t>
466<t>
467   The registry itself is maintained at
468   <eref target="http://www.iana.org/assignments/http-parameters"/>.
469</t>
470</section>
471
472</section>
473
474<section title="Media Types" anchor="media.types">
475  <x:anchor-alias value="media-type"/>
476  <x:anchor-alias value="type"/>
477  <x:anchor-alias value="subtype"/>
478<t>
479   HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>)
480   and Accept (<xref target="header.accept"/>) header fields in order to provide
481   open and extensible data typing and type negotiation.
482</t>
483<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
484  <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
485  <x:ref>type</x:ref>       = <x:ref>token</x:ref>
486  <x:ref>subtype</x:ref>    = <x:ref>token</x:ref>
487</artwork></figure>
488<t anchor="rule.parameter">
489  <x:anchor-alias value="attribute"/>
490  <x:anchor-alias value="parameter"/>
491  <x:anchor-alias value="value"/>
492   The type/subtype &MAY; be followed by parameters in the form of
493   attribute/value pairs.
494</t>
495<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>
496  <x:ref>parameter</x:ref>      = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref>
497  <x:ref>attribute</x:ref>      = <x:ref>token</x:ref>
498  <x:ref>value</x:ref>          = <x:ref>word</x:ref>
499</artwork></figure>
500<t>
501   The type, subtype, and parameter attribute names are case-insensitive.
502   Parameter values might or might not be case-sensitive, depending on the
503   semantics of the parameter name.  The presence or absence of a parameter might
504   be significant to the processing of a media-type, depending on its
505   definition within the media type registry.
506</t>
507<t>
508   A parameter value that matches the <x:ref>token</x:ref> production can be
509   transmitted as either a token or within a quoted-string. The quoted and
510   unquoted values are equivalent.
511</t>
512<t>
513   Note that some older HTTP applications do not recognize media type
514   parameters. When sending data to older HTTP applications,
515   implementations &SHOULD; only use media type parameters when they are
516   required by that type/subtype definition.
517</t>
518<t>
519   Media-type values are registered with the Internet Assigned Number
520   Authority (IANA). The media type registration process is
521   outlined in <xref target="RFC4288"/>. Use of non-registered media types is
522   discouraged.
523</t>
524
525<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
526<t>
527   Internet media types are registered with a canonical form. A
528   representation transferred via HTTP messages &MUST; be in the
529   appropriate canonical form prior to its transmission except for
530   "text" types, as defined in the next paragraph.
531</t>
532<t>
533   When in canonical form, media subtypes of the "text" type use CRLF as
534   the text line break. HTTP relaxes this requirement and allows the
535   transport of text media with plain CR or LF alone representing a line
536   break when it is done consistently for an entire representation. HTTP
537   applications &MUST; accept CRLF, bare CR, and bare LF as indicating
538   a line break in text media received via HTTP. In
539   addition, if the text is in a character encoding that does not
540   use octets 13 and 10 for CR and LF respectively, as is the case for
541   some multi-byte character encodings, HTTP allows the use of whatever octet
542   sequences are defined by that character encoding to represent the
543   equivalent of CR and LF for line breaks. This flexibility regarding
544   line breaks applies only to text media in the payload body; a bare CR
545   or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control
546   structures (such as header fields and multipart boundaries).
547</t>
548<t>
549   If a representation is encoded with a content-coding, the underlying
550   data &MUST; be in a form defined above prior to being encoded.
551</t>
552</section>
553
554<section title="Multipart Types" anchor="multipart.types">
555<t>
556   MIME provides for a number of "multipart" types &mdash; encapsulations of
557   one or more representations within a single message-body. All multipart
558   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
559   and &MUST; include a boundary parameter as part of the media type
560   value. The message body is itself a protocol element and &MUST;
561   therefore use only CRLF to represent line breaks between body-parts.
562</t>
563<t>
564   In general, HTTP treats a multipart message-body no differently than
565   any other media type: strictly as payload.  HTTP does not use the
566   multipart boundary as an indicator of message-body length.
567   <!-- jre: re-insert removed text pointing to caching? -->
568   In all other respects, an HTTP user agent &SHOULD; follow the same or similar
569   behavior as a MIME user agent would upon receipt of a multipart type.
570   The MIME header fields within each body-part of a multipart message-body
571   do not have any significance to HTTP beyond that defined by
572   their MIME semantics.
573</t>
574<t>
575   If an application receives an unrecognized multipart subtype, the
576   application &MUST; treat it as being equivalent to "multipart/mixed".
577</t>
578<x:note>
579  <t>
580    <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
581    for carrying form data suitable for processing via the POST
582    request method, as described in <xref target="RFC2388"/>.
583  </t>
584</x:note>
585</section>
586</section>
587
588<section title="Language Tags" anchor="language.tags">
589  <x:anchor-alias value="language-tag"/>
590<t>
591   A language tag, as defined in <xref target="RFC5646"/>, identifies a
592   natural language spoken, written, or otherwise conveyed by human beings for
593   communication of information to other human beings. Computer languages are
594   explicitly excluded. HTTP uses language tags within the Accept-Language and
595   Content-Language fields.
596</t>
597<t>
598   In summary, a language tag is composed of one or more parts: A primary
599   language subtag followed by a possibly empty series of subtags:
600</t>
601<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/>
602  <x:ref>language-tag</x:ref> = &lt;Language-Tag, defined in <xref target="RFC5646" x:sec="2.1"/>&gt;
603</artwork></figure>
604<t>
605   White space is not allowed within the tag and all tags are case-insensitive.
606   The name space of language subtags is administered by the IANA (see
607   <eref target="http://www.iana.org/assignments/language-subtag-registry"/>).
608</t>
609<figure>
610  <preamble>Example tags include:</preamble>
611<artwork type="example">
612  en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
613</artwork>
614</figure>
615<t>
616   See <xref target="RFC5646"/> for further information.
617</t>
618</section>
619</section>
620
621<section title="Payload" anchor="payload">
622<t>
623   HTTP messages &MAY; transfer a payload if not otherwise restricted by
624   the request method or response status code.  The payload consists of
625   metadata, in the form of header fields, and data, in the form of the
626   sequence of octets in the message-body after any transfer-coding has
627   been decoded.
628</t>
629<iref item="payload"/>
630<t>   
631   A "<x:dfn>payload</x:dfn>" in HTTP is always a partial or complete
632   representation of some resource.  We use separate terms for payload
633   and representation because some messages contain only the associated
634   representation's header fields (e.g., responses to HEAD) or only some
635   part(s) of the representation (e.g., the 206 status code).
636</t>
637<section title="Payload Header Fields" anchor="payload.header.fields">
638  <x:anchor-alias value="payload-header"/>
639<t>
640   HTTP header fields that specifically define the payload, rather than the
641   associated representation, are referred to as "payload header fields".
642   The following payload header fields are defined by HTTP/1.1:
643</t>
644<texttable align="left">
645  <ttcol>Header Field Name</ttcol>
646  <ttcol>Defined in...</ttcol>
647
648  <c>Content-Length</c> <c>&header-content-length;</c>
649  <c>Content-Range</c> <c>&header-content-range;</c>
650</texttable>
651</section>
652
653<section title="Payload Body" anchor="payload.body">
654  <x:anchor-alias value="payload-body"/>
655<t>
656   A payload body is only present in a message when a message-body is
657   present, as described in &message-body;. The payload body is obtained
658   from the message-body by decoding any Transfer-Encoding that might
659   have been applied to ensure safe and proper transfer of the message.
660</t>
661</section>
662</section>
663
664<section title="Representation" anchor="representation">
665<iref item="representation"/>
666<t>
667   A "<x:dfn>representation</x:dfn>" is information in a format that can be readily
668   communicated from one party to another.  A resource representation
669   is information that reflects the state of that resource, as observed
670   at some point in the past (e.g., in a response to GET) or to be
671   desired at some point in the future (e.g., in a PUT request).
672</t>
673<t>
674   Most, but not all, representations transferred via HTTP are intended
675   to be a representation of the target resource (the resource identified
676   by the effective request URI).  The precise semantics of a representation
677   are determined by the type of message (request or response), the request
678   method, the response status code, and the representation metadata.
679   For example, the above semantic is true for the representation in any
680   200 (OK) response to GET and for the representation in any PUT request.
681   A 200 response to PUT, in contrast, contains either a representation
682   that describes the successful action or a representation of the target
683   resource, with the latter indicated by a Content-Location header field
684   with the same value as the effective request URI.  Likewise, response
685   messages with an error status code usually contain a representation that
686   describes the error and what next steps are suggested for resolving it.
687</t>
688
689<section title="Representation Header Fields" anchor="representation.header.fields">
690  <x:anchor-alias value="representation-header"/>
691<t>
692   Representation header fields define metadata about the representation data
693   enclosed in the message-body or, if no message-body is present, about
694   the representation that would have been transferred in a 200 response
695   to a simultaneous GET request with the same effective request URI.
696</t>
697<t>
698   The following header fields are defined as representation metadata:
699</t>
700<texttable align="left">
701  <ttcol>Header Field Name</ttcol>
702  <ttcol>Defined in...</ttcol>
703
704  <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
705  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
706  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
707  <c>Content-Type</c> <c><xref target="header.content-type"/></c>
708  <c>Expires</c> <c>&header-expires;</c>
709  <c>Last-Modified</c> <c>&header-last-modified;</c>
710</texttable>
711</section>
712
713<section title="Representation Data" anchor="representation.data">
714  <x:anchor-alias value="representation-data"/>
715<t>
716   The representation body associated with an HTTP message is
717   either provided as the payload body of the message or
718   referred to by the message semantics and the effective request
719   URI.  The representation data is in a format and encoding defined by
720   the representation metadata header fields.
721</t>
722<t>
723   The data type of the representation data
724   is determined via the header fields Content-Type and Content-Encoding.
725   These define a two-layer, ordered encoding model:
726</t>
727<figure><artwork type="example">
728  representation-data := Content-Encoding( Content-Type( bits ) )
729</artwork></figure>
730<t>
731   Content-Type specifies the media type of the underlying data, which
732   defines both the data format and how that data &SHOULD; be processed
733   by the recipient (within the scope of the request method semantics).
734   Any HTTP/1.1 message containing a payload body &SHOULD; include a
735   Content-Type header field defining the media type of the associated
736   representation unless that metadata is unknown to the sender.
737   If the Content-Type header field is not present, it indicates that
738   the sender does not know the media type of the representation;
739   recipients &MAY; either assume that the media type is
740   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
741   or examine the content to determine its type.
742</t>
743<t>
744   In practice, resource owners do not always properly configure their origin
745   server to provide the correct Content-Type for a given representation,
746   with the result that some clients will examine a response body's content
747   and override the specified type.
748   Clients that do so risk drawing incorrect conclusions, which might expose
749   additional security risks (e.g., "privilege escalation").  Furthermore,
750   it is impossible to determine the sender's intent by examining the data
751   format: many data formats match multiple media types that differ only in
752   processing semantics.  Implementers are encouraged to provide a means of
753   disabling such "content sniffing" when it is used.
754</t>
755<t>
756   Content-Encoding is used to indicate any additional content
757   codings applied to the data, usually for the purpose of data
758   compression, that are a property of the representation.  If
759   Content-Encoding is not present, then there is no additional
760   encoding beyond that defined by the Content-Type.
761</t>
762</section>
763</section>
764
765<section title="Content Negotiation" anchor="content.negotiation">
766<t>
767   HTTP responses include a representation which contains information for
768   interpretation, whether by a human user or for further processing.
769   Often, the server has different ways of representing the
770   same information; for example, in different formats, languages,
771   or using different character encodings.
772</t>
773<t>
774   HTTP clients and their users might have different or variable
775   capabilities, characteristics or preferences which would influence
776   which representation, among those available from the server,
777   would be best for the server to deliver. For this reason, HTTP
778   provides mechanisms for "content negotiation" &mdash; a process of
779   allowing selection of a representation of a given resource,
780   when more than one is available.
781</t>
782<t>
783   This specification defines two patterns of content negotiation;
784   "server-driven", where the server selects the representation based
785   upon the client's stated preferences, and "agent-driven" negotiation,
786   where the server provides a list of representations for the client to
787   choose from, based upon their metadata. In addition,  there are
788   other patterns: some applications use an "active content" pattern,
789   where the server returns active content which runs on the client
790   and, based on client available parameters, selects additional
791   resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>)
792   has also been proposed.
793</t>
794<t>
795   These patterns are all widely used, and have trade-offs in applicability
796   and practicality. In particular, when the number of preferences or
797   capabilities to be expressed by a client are large (such as when many
798   different formats are supported by a user-agent), server-driven
799   negotiation becomes unwieldy, and might not be appropriate. Conversely,
800   when the number of representations to choose from is very large,
801   agent-driven negotiation might not be appropriate.
802</t>
803<t>
804   Note that in all cases, the supplier of representations has the
805   responsibility for determining which representations might be
806   considered to be the "same information".
807</t>
808
809<section title="Server-driven Negotiation" anchor="server-driven.negotiation">
810<t>
811   If the selection of the best representation for a response is made by
812   an algorithm located at the server, it is called server-driven
813   negotiation. Selection is based on the available representations of
814   the response (the dimensions over which it can vary; e.g., language,
815   content-coding, etc.) and the contents of particular header fields in
816   the request message or on other information pertaining to the request
817   (such as the network address of the client).
818</t>
819<t>
820   Server-driven negotiation is advantageous when the algorithm for
821   selecting from among the available representations is difficult to
822   describe to the user agent, or when the server desires to send its
823   "best guess" to the client along with the first response (hoping to
824   avoid the round-trip delay of a subsequent request if the "best
825   guess" is good enough for the user). In order to improve the server's
826   guess, the user agent &MAY; include request header fields (Accept,
827   Accept-Language, Accept-Encoding, etc.) which describe its
828   preferences for such a response.
829</t>
830<t>
831   Server-driven negotiation has disadvantages:
832  <list style="numbers">
833    <t>
834         It is impossible for the server to accurately determine what
835         might be "best" for any given user, since that would require
836         complete knowledge of both the capabilities of the user agent
837         and the intended use for the response (e.g., does the user want
838         to view it on screen or print it on paper?).
839    </t>
840    <t>
841         Having the user agent describe its capabilities in every
842         request can be both very inefficient (given that only a small
843         percentage of responses have multiple representations) and a
844         potential violation of the user's privacy.
845    </t>
846    <t>
847         It complicates the implementation of an origin server and the
848         algorithms for generating responses to a request.
849    </t>
850    <t>
851         It might limit a public cache's ability to use the same response
852         for multiple user's requests.
853    </t>
854  </list>
855</t>
856<t>
857   Server-driven negotiation allows the user agent to specify its preferences,
858   but it cannot expect responses to always honour them. For example, the origin
859   server might not implement server-driven negotiation, or it might decide that
860   sending a response that doesn't conform to them is better than sending a 406
861   (Not Acceptable) response.
862</t>
863<t>
864   Many of the mechanisms for expressing preferences use quality values to
865   declare relative preference. See &qvalue; for more information.
866</t>
867<t>
868   HTTP/1.1 includes the following header fields for enabling
869   server-driven negotiation through description of user agent
870   capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
871   (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language
872   (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;).
873   However, an origin server is not limited to these dimensions and &MAY; vary
874   the response based on any aspect of the request, including aspects
875   of the connection (e.g., IP address) or information within extension
876   header fields not defined by this specification.
877</t>
878<x:note>
879  <t>
880    <x:h>Note:</x:h> In practice, User-Agent based negotiation is fragile,
881    because new clients might not be recognized.
882  </t>
883</x:note>
884<t>
885   The Vary header field (&header-vary;) can be used to express the parameters the
886   server uses to select a representation that is subject to server-driven
887   negotiation.
888</t>
889</section>
890
891<section title="Agent-driven Negotiation" anchor="agent-driven.negotiation">
892<t>
893   With agent-driven negotiation, selection of the best representation
894   for a response is performed by the user agent after receiving an
895   initial response from the origin server. Selection is based on a list
896   of the available representations of the response included within the
897   header fields or body of the initial response, with each
898   representation identified by its own URI. Selection from among the
899   representations can be performed automatically (if the user agent is
900   capable of doing so) or manually by the user selecting from a
901   generated (possibly hypertext) menu.
902</t>
903<t>
904   Agent-driven negotiation is advantageous when the response would vary
905   over commonly-used dimensions (such as type, language, or encoding),
906   when the origin server is unable to determine a user agent's
907   capabilities from examining the request, and generally when public
908   caches are used to distribute server load and reduce network usage.
909</t>
910<t>
911   Agent-driven negotiation suffers from the disadvantage of needing a
912   second request to obtain the best alternate representation. This
913   second request is only efficient when caching is used. In addition,
914   this specification does not define any mechanism for supporting
915   automatic selection, though it also does not prevent any such
916   mechanism from being developed as an extension and used within
917   HTTP/1.1.
918</t>
919<t>
920   This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable)
921   status codes for enabling agent-driven negotiation when the server is
922   unwilling or unable to provide a varying response using server-driven
923   negotiation.
924</t>
925</section>
926</section>
927
928<section title="Header Field Definitions" anchor="header.field.definitions">
929<t>
930   This section defines the syntax and semantics of HTTP/1.1 header fields
931   related to the payload of messages.
932</t>
933
934<section title="Accept" anchor="header.accept">
935  <iref primary="true" item="Accept header field" x:for-anchor=""/>
936  <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/>
937  <x:anchor-alias value="Accept"/>
938  <x:anchor-alias value="accept-ext"/>
939  <x:anchor-alias value="accept-params"/>
940  <x:anchor-alias value="media-range"/>
941<t>
942   The "Accept" header field can be used by user agents to specify
943   response media types that are acceptable. Accept header fields can be used to
944   indicate that the request is specifically limited to a small set of desired
945   types, as in the case of a request for an in-line image.
946</t>
947<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
948  <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )
949 
950  <x:ref>media-range</x:ref>    = ( "*/*"
951                   / ( <x:ref>type</x:ref> "/" "*" )
952                   / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )
953                   ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
954  <x:ref>accept-params</x:ref>  = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>accept-ext</x:ref> )
955  <x:ref>accept-ext</x:ref>     = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]
956</artwork></figure>
957<t>
958   The asterisk "*" character is used to group media types into ranges,
959   with "*/*" indicating all media types and "type/*" indicating all
960   subtypes of that type. The media-range &MAY; include media type
961   parameters that are applicable to that range.
962</t>
963<t>
964   Each media-range &MAY; be followed by one or more accept-params,
965   beginning with the "q" parameter for indicating a relative quality
966   factor. The first "q" parameter (if any) separates the media-range
967   parameter(s) from the accept-params. Quality factors allow the user
968   or user agent to indicate the relative degree of preference for that
969   media-range, using the qvalue scale from 0 to 1 (&qvalue;). The
970   default value is q=1.
971</t>
972<x:note>
973  <t>
974    <x:h>Note:</x:h> Use of the "q" parameter name to separate media type
975    parameters from Accept extension parameters is due to historical
976    practice. Although this prevents any media type parameter named
977    "q" from being used with a media range, such an event is believed
978    to be unlikely given the lack of any "q" parameters in the IANA
979    media type registry and the rare usage of any media type
980    parameters in Accept. Future media types are discouraged from
981    registering any parameter named "q".
982  </t>
983</x:note>
984<t>
985   The example
986</t>
987<figure><artwork type="example">
988  Accept: audio/*; q=0.2, audio/basic
989</artwork></figure>
990<t>
991   &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio
992   type if it is the best available after an 80% mark-down in quality".
993</t>
994<t>
995   A request without any Accept header field implies that the user agent
996   will accept any media type in response.
997   If an Accept header field is present in a request and none of the
998   available representations for the response have a media type that is
999   listed as acceptable, the origin server &MAY; either
1000   honor the Accept header field by sending a 406 (Not Acceptable) response
1001   or disregard the Accept header field by treating the response as if
1002   it is not subject to content negotiation.
1003</t>
1004<t>
1005   A more elaborate example is
1006</t>
1007<figure><artwork type="example">
1008  Accept: text/plain; q=0.5, text/html,
1009          text/x-dvi; q=0.8, text/x-c
1010</artwork></figure>
1011<t>
1012   Verbally, this would be interpreted as "text/html and text/x-c are
1013   the preferred media types, but if they do not exist, then send the
1014   text/x-dvi representation, and if that does not exist, send the text/plain
1015   representation".
1016</t>
1017<t>
1018   Media ranges can be overridden by more specific media ranges or
1019   specific media types. If more than one media range applies to a given
1020   type, the most specific reference has precedence. For example,
1021</t>
1022<figure><artwork type="example">
1023  Accept: text/*, text/plain, text/plain;format=flowed, */*
1024</artwork></figure>
1025<t>
1026   have the following precedence:
1027   <list style="numbers">
1028    <t>text/plain;format=flowed</t>
1029    <t>text/plain</t>
1030    <t>text/*</t>
1031    <t>*/*</t>
1032   </list>
1033</t>
1034<t>
1035   The media type quality factor associated with a given type is
1036   determined by finding the media range with the highest precedence
1037   which matches that type. For example,
1038</t>
1039<figure><artwork type="example">
1040  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
1041          text/html;level=2;q=0.4, */*;q=0.5
1042</artwork></figure>
1043<t>
1044   would cause the following values to be associated:
1045</t>
1046<texttable align="left">
1047  <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>
1048  <c>text/html;level=1</c>    <c>1</c>
1049  <c>text/html</c>            <c>0.7</c>
1050  <c>text/plain</c>           <c>0.3</c>
1051  <c>image/jpeg</c>           <c>0.5</c>
1052  <c>text/html;level=2</c>    <c>0.4</c>
1053  <c>text/html;level=3</c>    <c>0.7</c>
1054</texttable>
1055<t>
1056      <x:h>Note:</x:h> A user agent might be provided with a default set of quality
1057      values for certain media ranges. However, unless the user agent is
1058      a closed system which cannot interact with other rendering agents,
1059      this default set ought to be configurable by the user.
1060</t>
1061</section>
1062
1063<section title="Accept-Charset" anchor="header.accept-charset">
1064  <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>
1065  <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/>
1066  <x:anchor-alias value="Accept-Charset"/>
1067<t>
1068   The "Accept-Charset" header field can be used by user agents to
1069   indicate what character encodings are acceptable in a response
1070   payload. This field allows
1071   clients capable of understanding more comprehensive or special-purpose
1072   character encodings to signal that capability to a server which is capable of
1073   representing documents in those character encodings.
1074</t>
1075<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
1076  <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" )
1077                         [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
1078</artwork></figure>
1079<t>
1080   Character encoding values (a.k.a., charsets) are described in
1081   <xref target="character.sets"/>. Each charset &MAY; be given an
1082   associated quality value which represents the user's preference
1083   for that charset. The default value is q=1. An example is
1084</t>
1085<figure><artwork type="example">
1086  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
1087</artwork></figure>
1088<t>
1089   The special value "*", if present in the Accept-Charset field,
1090   matches every character encoding which is not mentioned elsewhere in the
1091   Accept-Charset field. If no "*" is present in an Accept-Charset field, then
1092   all character encodings not explicitly mentioned get a quality value of 0.
1093</t>
1094<t>
1095   A request without any Accept-Charset header field implies that the user
1096   agent will accept any character encoding in response.
1097   If an Accept-Charset header field is present in a request and none of the
1098   available representations for the response have a character encoding that
1099   is listed as acceptable, the origin server &MAY; either honor the
1100   Accept-Charset header field by sending a 406 (Not Acceptable) response or
1101   disregard the Accept-Charset header field by treating the response as if
1102   it is not subject to content negotiation.
1103</t>
1104</section>
1105
1106<section title="Accept-Encoding" anchor="header.accept-encoding">
1107  <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>
1108  <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/>
1109  <x:anchor-alias value="Accept-Encoding"/>
1110  <x:anchor-alias value="codings"/>
1111<t>
1112   The "Accept-Encoding" header field can be used by user agents to
1113   indicate what response content-codings (<xref target="content.codings"/>)
1114   are acceptable in the response.  An "identity" token is used as a synonym
1115   for "no encoding" in order to communicate when no encoding is preferred.
1116</t>
1117<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>
1118  <x:ref>Accept-Encoding</x:ref>  = #( <x:ref>codings</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
1119  <x:ref>codings</x:ref>          = <x:ref>content-coding</x:ref> / "identity" / "*"
1120</artwork></figure>
1121<t>
1122   Each codings value &MAY; be given an associated quality value which
1123   represents the preference for that encoding. The default value is q=1.
1124</t>
1125<t>
1126   For example,
1127</t>
1128<figure><artwork type="example">
1129  Accept-Encoding: compress, gzip
1130  Accept-Encoding:
1131  Accept-Encoding: *
1132  Accept-Encoding: compress;q=0.5, gzip;q=1.0
1133  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
1134</artwork></figure>
1135<t>
1136   A server tests whether a content-coding for a given representation is
1137   acceptable, according to an Accept-Encoding field, using these rules:
1138  <list style="numbers">
1139      <t>The special "*" symbol in an Accept-Encoding field matches any
1140         available content-coding not explicitly listed in the header
1141         field.</t>
1142
1143      <t>If the representation has no content-coding, then it is acceptable
1144         by default unless specifically excluded by the Accept-Encoding field
1145         stating either "identity;q=0" or "*;q=0" without a more specific
1146         entry for "identity".</t>
1147
1148      <t>If the representation's content-coding is one of the content-codings
1149         listed in the Accept-Encoding field, then it is acceptable unless
1150         it is accompanied by a qvalue of 0. (As defined in &qvalue;, a
1151         qvalue of 0 means "not acceptable".)</t>
1152
1153      <t>If multiple content-codings are acceptable, then the acceptable
1154         content-coding with the highest non-zero qvalue is preferred.</t>
1155  </list>
1156</t>
1157<t>
1158   An Accept-Encoding header field with a combined field-value that is empty
1159   implies that the user agent does not want any content-coding in response.
1160   If an Accept-Encoding header field is present in a request and none of the
1161   available representations for the response have a content-coding that
1162   is listed as acceptable, the origin server &SHOULD; send a response
1163   without any content-coding.
1164</t>
1165<t>
1166   A request without an Accept-Encoding header field implies that the user
1167   agent will accept any content-coding in response, but a representation
1168   without content-coding is preferred for compatibility with the widest
1169   variety of user agents.
1170</t>
1171<x:note>
1172  <t>
1173    <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues
1174    associated with content-codings. This means that qvalues will not
1175    work and are not permitted with x-gzip or x-compress.
1176  </t>
1177</x:note>
1178</section>
1179
1180<section title="Accept-Language" anchor="header.accept-language">
1181  <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>
1182  <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/>
1183  <x:anchor-alias value="Accept-Language"/>
1184  <x:anchor-alias value="language-range"/>
1185<t>
1186   The "Accept-Language" header field can be used by user agents to
1187   indicate the set of natural languages that are preferred in the response.
1188   Language tags are defined in <xref target="language.tags"/>.
1189</t>
1190<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>
1191  <x:ref>Accept-Language</x:ref> =
1192                    1#( <x:ref>language-range</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
1193  <x:ref>language-range</x:ref>  =
1194            &lt;language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>&gt;
1195</artwork></figure>
1196<t>
1197   Each language-range can be given an associated quality value which
1198   represents an estimate of the user's preference for the languages
1199   specified by that range. The quality value defaults to "q=1". For
1200   example,
1201</t>
1202<figure><artwork type="example">
1203  Accept-Language: da, en-gb;q=0.8, en;q=0.7
1204</artwork></figure>
1205<t>
1206   would mean: "I prefer Danish, but will accept British English and
1207   other types of English".
1208   (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
1209</t>
1210<t>
1211   For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines
1212   several matching schemes. Implementations can offer the most appropriate
1213   matching scheme for their requirements.
1214</t>
1215<x:note>
1216  <t>
1217    <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647"
1218    x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was
1219    previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
1220  </t>
1221</x:note>
1222<t>
1223   It might be contrary to the privacy expectations of the user to send
1224   an Accept-Language header field with the complete linguistic preferences of
1225   the user in every request. For a discussion of this issue, see
1226   <xref target="privacy.issues.connected.to.accept.header.fields"/>.
1227</t>
1228<t>
1229   As intelligibility is highly dependent on the individual user, it is
1230   recommended that client applications make the choice of linguistic
1231   preference available to the user. If the choice is not made
1232   available, then the Accept-Language header field &MUST-NOT; be given in
1233   the request.
1234</t>
1235<x:note>
1236  <t>
1237    <x:h>Note:</x:h> When making the choice of linguistic preference available to
1238    the user, we remind implementors of  the fact that users are not
1239    familiar with the details of language matching as described above,
1240    and ought to be provided appropriate guidance. As an example, users
1241    might assume that on selecting "en-gb", they will be served any
1242    kind of English document if British English is not available. A
1243    user agent might suggest in such a case to add "en" to get the
1244    best matching behavior.
1245  </t>
1246</x:note>
1247</section>
1248
1249<section title="Content-Encoding" anchor="header.content-encoding">
1250  <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
1251  <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/>
1252  <x:anchor-alias value="Content-Encoding"/>
1253<t>
1254   The "Content-Encoding" header field indicates what content-codings
1255   have been applied to the representation beyond those inherent in the media
1256   type, and thus what decoding mechanisms must be applied in order to obtain
1257   the media-type referenced by the Content-Type header field.
1258   Content-Encoding is primarily used to allow a representation to be
1259   compressed without losing the identity of its underlying media type.
1260</t>
1261<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
1262  <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
1263</artwork></figure>
1264<t>
1265   Content codings are defined in <xref target="content.codings"/>. An example of its use is
1266</t>
1267<figure><artwork type="example">
1268  Content-Encoding: gzip
1269</artwork></figure>
1270<t>
1271   The content-coding is a characteristic of the representation.
1272   Typically, the representation body is stored with this
1273   encoding and is only decoded before rendering or analogous usage.
1274   However, a transforming proxy &MAY; modify the content-coding if the
1275   new coding is known to be acceptable to the recipient, unless the
1276   "no-transform" cache-control directive is present in the message.
1277</t>
1278<t>
1279   If the media type includes an inherent encoding, such as a data format
1280   that is always compressed, then that encoding would not be restated as
1281   a Content-Encoding even if it happens to be the same algorithm as one
1282   of the content-codings.  Such a content-coding would only be listed if,
1283   for some bizarre reason, it is applied a second time to form the
1284   representation.  Likewise, an origin server might choose to publish the
1285   same payload data as multiple representations that differ only in whether
1286   the coding is defined as part of Content-Type or Content-Encoding, since
1287   some user agents will behave differently in their handling of each
1288   response (e.g., open a "Save as ..." dialog instead of automatic
1289   decompression and rendering of content).
1290</t>
1291<t>
1292   A representation that has a content-coding applied to it &MUST; include
1293   a Content-Encoding header field (<xref target="header.content-encoding"/>)
1294   that lists the content-coding(s) applied.
1295</t>
1296<t>
1297   If multiple encodings have been applied to a representation, the content
1298   codings &MUST; be listed in the order in which they were applied.
1299   Additional information about the encoding parameters &MAY; be provided
1300   by other header fields not defined by this specification.
1301</t>
1302<t>
1303   If the content-coding of a representation in a request message is not
1304   acceptable to the origin server, the server &SHOULD; respond with a
1305   status code of 415 (Unsupported Media Type).
1306</t>
1307</section>
1308
1309<section title="Content-Language" anchor="header.content-language">
1310  <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
1311  <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/>
1312  <x:anchor-alias value="Content-Language"/>
1313<t>
1314   The "Content-Language" header field describes the natural
1315   language(s) of the intended audience for the representation. Note that this might
1316   not be equivalent to all the languages used within the representation.
1317</t>
1318<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
1319  <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
1320</artwork></figure>
1321<t>
1322   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
1323   Content-Language is to allow a user to identify and differentiate
1324   representations according to the user's own preferred language. Thus, if the
1325   body content is intended only for a Danish-literate audience, the
1326   appropriate field is
1327</t>
1328<figure><artwork type="example">
1329  Content-Language: da
1330</artwork></figure>
1331<t>
1332   If no Content-Language is specified, the default is that the content
1333   is intended for all language audiences. This might mean that the
1334   sender does not consider it to be specific to any natural language,
1335   or that the sender does not know for which language it is intended.
1336</t>
1337<t>
1338   Multiple languages &MAY; be listed for content that is intended for
1339   multiple audiences. For example, a rendition of the "Treaty of
1340   Waitangi", presented simultaneously in the original Maori and English
1341   versions, would call for
1342</t>
1343<figure><artwork type="example">
1344  Content-Language: mi, en
1345</artwork></figure>
1346<t>
1347   However, just because multiple languages are present within a representation
1348   does not mean that it is intended for multiple linguistic audiences.
1349   An example would be a beginner's language primer, such as "A First
1350   Lesson in Latin", which is clearly intended to be used by an
1351   English-literate audience. In this case, the Content-Language would
1352   properly only include "en".
1353</t>
1354<t>
1355   Content-Language &MAY; be applied to any media type &mdash; it is not
1356   limited to textual documents.
1357</t>
1358</section>
1359
1360<section title="Content-Location" anchor="header.content-location">
1361  <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
1362  <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/>
1363  <x:anchor-alias value="Content-Location"/>
1364<t>
1365   The "Content-Location" header field supplies a URI that can be used
1366   as a specific identifier for the representation in this message.
1367   In other words, if one were to perform a GET on this URI at the time
1368   of this message's generation, then a 200 response would contain the
1369   same representation that is enclosed as payload in this message.
1370</t>
1371<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
1372  <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
1373</artwork></figure>
1374<t>
1375   The Content-Location value is not a replacement for the effective
1376   Request URI (&effective-request-uri;).  It is representation metadata.
1377   It has the same syntax and semantics as the header field of the same name
1378   defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
1379   However, its appearance in an HTTP message has some special implications
1380   for HTTP recipients.
1381</t>
1382<t>
1383   If Content-Location is included in a response message and its value
1384   is the same as the effective request URI, then the response payload
1385   &SHOULD; be considered the current representation of that resource.
1386   For a GET or HEAD request, this is the same as the default semantics
1387   when no Content-Location is provided by the server.  For a state-changing
1388   request like PUT or POST, it implies that the server's response contains
1389   the new representation of that resource, thereby distinguishing it from
1390   representations that might only report about the action (e.g., "It worked!").
1391   This allows authoring applications to update their local copies without
1392   the need for a subsequent GET request.
1393</t>
1394<t>
1395   If Content-Location is included in a response message and its value
1396   differs from the effective request URI, then the origin server is
1397   informing recipients that this representation has its own, presumably
1398   more specific, identifier.  For a GET or HEAD request, this is an
1399   indication that the effective request URI identifies a resource that
1400   is subject to content negotiation and the representation selected for
1401   this response can also be found at the identified URI.  For other
1402   methods, such a Content-Location indicates that this representation
1403   contains a report on the action's status and the same report is
1404   available (for future access with GET) at the given URI.  For
1405   example, a purchase transaction made via a POST request might
1406   include a receipt document as the payload of the 200 response;
1407   the Content-Location value provides an identifier for retrieving
1408   a copy of that same receipt in the future.
1409</t>
1410<t>
1411   If Content-Location is included in a request message, then it &MAY;
1412   be interpreted by the origin server as an indication of where the
1413   user agent originally obtained the content of the enclosed
1414   representation (prior to any subsequent modification of the content
1415   by that user agent).  In other words, the user agent is providing
1416   the same representation metadata that it received with the original
1417   representation.  However, such interpretation &MUST-NOT; be used to
1418   alter the semantics of the method requested by the client.  For
1419   example, if a client makes a PUT request on a negotiated resource
1420   and the origin server accepts that PUT (without redirection), then the
1421   new set of values for that resource is expected to be consistent with
1422   the one representation supplied in that PUT; the Content-Location
1423   cannot be used as a form of reverse content selection that
1424   identifies only one of the negotiated representations to be updated.
1425   If the user agent had wanted the latter semantics, it would have applied
1426   the PUT directly to the Content-Location URI.
1427</t>
1428<t>
1429   A Content-Location field received in a request message is transitory
1430   information that &SHOULD-NOT; be saved with other representation
1431   metadata for use in later responses.  The Content-Location's value
1432   might be saved for use in other contexts, such as within source links
1433   or other metadata.
1434</t>
1435<t>
1436   A cache cannot assume that a representation with a Content-Location
1437   different from the URI used to retrieve it can be used to respond to
1438   later requests on that Content-Location URI.
1439</t>
1440<t>
1441   If the Content-Location value is a partial URI, the partial URI is
1442   interpreted relative to the effective request URI.
1443</t>
1444</section>
1445
1446<section title="Content-Type" anchor="header.content-type">
1447  <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
1448  <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>
1449  <x:anchor-alias value="Content-Type"/>
1450<t>
1451   The "Content-Type" header field indicates the media type of the
1452   representation. In the case of responses to the HEAD method, the media type is
1453   that which would have been sent had the request been a GET.
1454</t>
1455<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
1456  <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
1457</artwork></figure>
1458<t>
1459   Media types are defined in <xref target="media.types"/>. An example of the field is
1460</t>
1461<figure><artwork type="example">
1462  Content-Type: text/html; charset=ISO-8859-4
1463</artwork></figure>
1464<t>
1465   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
1466</t>
1467</section>
1468
1469</section>
1470
1471<section title="IANA Considerations" anchor="IANA.considerations">
1472<section title="Header Field Registration" anchor="header.field.registration">
1473<t>
1474   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
1475   with the permanent registrations below (see <xref target="RFC3864"/>):
1476</t>
1477<?BEGININC p3-payload.iana-headers ?>
1478<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
1479<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
1480   <ttcol>Header Field Name</ttcol>
1481   <ttcol>Protocol</ttcol>
1482   <ttcol>Status</ttcol>
1483   <ttcol>Reference</ttcol>
1484
1485   <c>Accept</c>
1486   <c>http</c>
1487   <c>standard</c>
1488   <c>
1489      <xref target="header.accept"/>
1490   </c>
1491   <c>Accept-Charset</c>
1492   <c>http</c>
1493   <c>standard</c>
1494   <c>
1495      <xref target="header.accept-charset"/>
1496   </c>
1497   <c>Accept-Encoding</c>
1498   <c>http</c>
1499   <c>standard</c>
1500   <c>
1501      <xref target="header.accept-encoding"/>
1502   </c>
1503   <c>Accept-Language</c>
1504   <c>http</c>
1505   <c>standard</c>
1506   <c>
1507      <xref target="header.accept-language"/>
1508   </c>
1509   <c>Content-Encoding</c>
1510   <c>http</c>
1511   <c>standard</c>
1512   <c>
1513      <xref target="header.content-encoding"/>
1514   </c>
1515   <c>Content-Language</c>
1516   <c>http</c>
1517   <c>standard</c>
1518   <c>
1519      <xref target="header.content-language"/>
1520   </c>
1521   <c>Content-Location</c>
1522   <c>http</c>
1523   <c>standard</c>
1524   <c>
1525      <xref target="header.content-location"/>
1526   </c>
1527   <c>Content-Type</c>
1528   <c>http</c>
1529   <c>standard</c>
1530   <c>
1531      <xref target="header.content-type"/>
1532   </c>
1533   <c>MIME-Version</c>
1534   <c>http</c>
1535   <c>standard</c>
1536   <c>
1537      <xref target="mime-version"/>
1538   </c>
1539</texttable>
1540<!--(END)-->
1541<?ENDINC p3-payload.iana-headers ?>
1542<t>
1543   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
1544</t>
1545</section>
1546
1547<section title="Content Coding Registry" anchor="content.coding.registration">
1548<t>
1549   The registration procedure for HTTP Content Codings is now defined
1550   by <xref target="content.coding.registry"/> of this document.
1551</t>
1552<t>
1553   The HTTP Content Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
1554   shall be updated with the registration below:
1555</t>
1556<texttable align="left" suppress-title="true" anchor="iana.content.coding.registration.table">
1557   <ttcol>Name</ttcol>
1558   <ttcol>Description</ttcol>
1559   <ttcol>Reference</ttcol>
1560   <c>compress</c>
1561   <c>UNIX "compress" program method</c>
1562   <c>
1563      &compress-coding;
1564   </c>
1565   <c>deflate</c>
1566   <c>"deflate" compression mechanism (<xref target="RFC1951"/>) used inside
1567   the "zlib" data format (<xref target="RFC1950"/>)
1568   </c>
1569   <c>
1570      &deflate-coding;
1571   </c>
1572   <c>gzip</c>
1573   <c>Same as GNU zip <xref target="RFC1952"/></c>
1574   <c>
1575      &gzip-coding;
1576   </c>
1577   <c>identity</c>
1578   <c>reserved (synonym for "no encoding" in Accept-Encoding header field)</c>
1579   <c>
1580      <xref target="header.accept-encoding"/>
1581   </c>
1582</texttable>
1583</section>
1584
1585</section>
1586
1587<section title="Security Considerations" anchor="security.considerations">
1588<t>
1589   This section is meant to inform application developers, information
1590   providers, and users of the security limitations in HTTP/1.1 as
1591   described by this document. The discussion does not include
1592   definitive solutions to the problems revealed, though it does make
1593   some suggestions for reducing security risks.
1594</t>
1595
1596<section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
1597<t>
1598   Accept headers fields can reveal information about the user to all
1599   servers which are accessed. The Accept-Language header field in particular
1600   can reveal information the user would consider to be of a private
1601   nature, because the understanding of particular languages is often
1602   strongly correlated to the membership of a particular ethnic group.
1603   User agents which offer the option to configure the contents of an
1604   Accept-Language header field to be sent in every request are strongly
1605   encouraged to let the configuration process include a message which
1606   makes the user aware of the loss of privacy involved.
1607</t>
1608<t>
1609   An approach that limits the loss of privacy would be for a user agent
1610   to omit the sending of Accept-Language header fields by default, and to ask
1611   the user whether or not to start sending Accept-Language header fields to a
1612   server if it detects, by looking for any Vary header fields
1613   generated by the server, that such sending could improve the quality
1614   of service.
1615</t>
1616<t>
1617   Elaborate user-customized accept header fields sent in every request,
1618   in particular if these include quality values, can be used by servers
1619   as relatively reliable and long-lived user identifiers. Such user
1620   identifiers would allow content providers to do click-trail tracking,
1621   and would allow collaborating content providers to match cross-server
1622   click-trails or form submissions of individual users. Note that for
1623   many users not behind a proxy, the network address of the host
1624   running the user agent will also serve as a long-lived user
1625   identifier. In environments where proxies are used to enhance
1626   privacy, user agents ought to be conservative in offering accept
1627   header configuration options to end users. As an extreme privacy
1628   measure, proxies could filter the accept header fields in relayed requests.
1629   General purpose user agents which provide a high degree of header
1630   configurability &SHOULD; warn users about the loss of privacy which can
1631   be involved.
1632</t>
1633</section>
1634
1635</section>
1636
1637<section title="Acknowledgments" anchor="acks">
1638<t>
1639  See &acks;.
1640</t>
1641</section>
1642</middle>
1643<back>
1644
1645<references title="Normative References">
1646
1647<reference anchor="Part1">
1648  <front>
1649    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
1650    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1651      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1652      <address><email>fielding@gbiv.com</email></address>
1653    </author>
1654    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1655      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1656      <address><email>jg@freedesktop.org</email></address>
1657    </author>
1658    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1659      <organization abbrev="HP">Hewlett-Packard Company</organization>
1660      <address><email>JeffMogul@acm.org</email></address>
1661    </author>
1662    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1663      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1664      <address><email>henrikn@microsoft.com</email></address>
1665    </author>
1666    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1667      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1668      <address><email>LMM@acm.org</email></address>
1669    </author>
1670    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1671      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1672      <address><email>paulle@microsoft.com</email></address>
1673    </author>
1674    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1675      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1676      <address><email>timbl@w3.org</email></address>
1677    </author>
1678    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1679      <organization abbrev="W3C">World Wide Web Consortium</organization>
1680      <address><email>ylafon@w3.org</email></address>
1681    </author>
1682    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1683      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1684      <address><email>julian.reschke@greenbytes.de</email></address>
1685    </author>
1686    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1687  </front>
1688  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
1689  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
1690</reference>
1691
1692<reference anchor="Part2">
1693  <front>
1694    <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>
1695    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1696      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1697      <address><email>fielding@gbiv.com</email></address>
1698    </author>
1699    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1700      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1701      <address><email>jg@freedesktop.org</email></address>
1702    </author>
1703    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1704      <organization abbrev="HP">Hewlett-Packard Company</organization>
1705      <address><email>JeffMogul@acm.org</email></address>
1706    </author>
1707    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1708      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1709      <address><email>henrikn@microsoft.com</email></address>
1710    </author>
1711    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1712      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1713      <address><email>LMM@acm.org</email></address>
1714    </author>
1715    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1716      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1717      <address><email>paulle@microsoft.com</email></address>
1718    </author>
1719    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1720      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1721      <address><email>timbl@w3.org</email></address>
1722    </author>
1723    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1724      <organization abbrev="W3C">World Wide Web Consortium</organization>
1725      <address><email>ylafon@w3.org</email></address>
1726    </author>
1727    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1728      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1729      <address><email>julian.reschke@greenbytes.de</email></address>
1730    </author>
1731    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1732  </front>
1733  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
1734  <x:source href="p2-semantics.xml" basename="p2-semantics"/>
1735</reference>
1736
1737<reference anchor="Part4">
1738  <front>
1739    <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title>
1740    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1741      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1742      <address><email>fielding@gbiv.com</email></address>
1743    </author>
1744    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1745      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1746      <address><email>jg@freedesktop.org</email></address>
1747    </author>
1748    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1749      <organization abbrev="HP">Hewlett-Packard Company</organization>
1750      <address><email>JeffMogul@acm.org</email></address>
1751    </author>
1752    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1753      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1754      <address><email>henrikn@microsoft.com</email></address>
1755    </author>
1756    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1757      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1758      <address><email>LMM@acm.org</email></address>
1759    </author>
1760    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1761      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1762      <address><email>paulle@microsoft.com</email></address>
1763    </author>
1764    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1765      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1766      <address><email>timbl@w3.org</email></address>
1767    </author>
1768    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1769      <organization abbrev="W3C">World Wide Web Consortium</organization>
1770      <address><email>ylafon@w3.org</email></address>
1771    </author>
1772    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1773      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1774      <address><email>julian.reschke@greenbytes.de</email></address>
1775    </author>
1776    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1777  </front>
1778  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/>
1779  <x:source href="p4-conditional.xml" basename="p4-conditional"/>
1780</reference>
1781
1782<reference anchor="Part5">
1783  <front>
1784    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
1785    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1786      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1787      <address><email>fielding@gbiv.com</email></address>
1788    </author>
1789    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1790      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1791      <address><email>jg@freedesktop.org</email></address>
1792    </author>
1793    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1794      <organization abbrev="HP">Hewlett-Packard Company</organization>
1795      <address><email>JeffMogul@acm.org</email></address>
1796    </author>
1797    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1798      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1799      <address><email>henrikn@microsoft.com</email></address>
1800    </author>
1801    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1802      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1803      <address><email>LMM@acm.org</email></address>
1804    </author>
1805    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1806      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1807      <address><email>paulle@microsoft.com</email></address>
1808    </author>
1809    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1810      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1811      <address><email>timbl@w3.org</email></address>
1812    </author>
1813    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1814      <organization abbrev="W3C">World Wide Web Consortium</organization>
1815      <address><email>ylafon@w3.org</email></address>
1816    </author>
1817    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1818      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1819      <address><email>julian.reschke@greenbytes.de</email></address>
1820    </author>
1821    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1822  </front>
1823  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>
1824  <x:source href="p5-range.xml" basename="p5-range"/>
1825</reference>
1826
1827<reference anchor="Part6">
1828  <front>
1829    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
1830    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1831      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1832      <address><email>fielding@gbiv.com</email></address>
1833    </author>
1834    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1835      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1836      <address><email>jg@freedesktop.org</email></address>
1837    </author>
1838    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1839      <organization abbrev="HP">Hewlett-Packard Company</organization>
1840      <address><email>JeffMogul@acm.org</email></address>
1841    </author>
1842    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1843      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1844      <address><email>henrikn@microsoft.com</email></address>
1845    </author>
1846    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1847      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1848      <address><email>LMM@acm.org</email></address>
1849    </author>
1850    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1851      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1852      <address><email>paulle@microsoft.com</email></address>
1853    </author>
1854    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1855      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1856      <address><email>timbl@w3.org</email></address>
1857    </author>
1858    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1859      <organization abbrev="W3C">World Wide Web Consortium</organization>
1860      <address><email>ylafon@w3.org</email></address>
1861    </author>
1862    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
1863      <organization>Rackspace</organization>
1864      <address><email>mnot@mnot.net</email></address>
1865    </author>
1866    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1867      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1868      <address><email>julian.reschke@greenbytes.de</email></address>
1869    </author>
1870    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1871  </front>
1872  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
1873  <x:source href="p6-cache.xml" basename="p6-cache"/>
1874</reference>
1875
1876<reference anchor="RFC1950">
1877  <front>
1878    <title>ZLIB Compressed Data Format Specification version 3.3</title>
1879    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
1880      <organization>Aladdin Enterprises</organization>
1881      <address><email>ghost@aladdin.com</email></address>
1882    </author>
1883    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"/>
1884    <date month="May" year="1996"/>
1885  </front>
1886  <seriesInfo name="RFC" value="1950"/>
1887  <annotation>
1888    RFC 1950 is an Informational RFC, thus it might be less stable than
1889    this specification. On the other hand, this downward reference was
1890    present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,
1891    therefore it is unlikely to cause problems in practice. See also
1892    <xref target="BCP97"/>.
1893  </annotation>
1894</reference>
1895
1896<reference anchor="RFC1951">
1897  <front>
1898    <title>DEFLATE Compressed Data Format Specification version 1.3</title>
1899    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
1900      <organization>Aladdin Enterprises</organization>
1901      <address><email>ghost@aladdin.com</email></address>
1902    </author>
1903    <date month="May" year="1996"/>
1904  </front>
1905  <seriesInfo name="RFC" value="1951"/>
1906  <annotation>
1907    RFC 1951 is an Informational RFC, thus it might be less stable than
1908    this specification. On the other hand, this downward reference was
1909    present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,
1910    therefore it is unlikely to cause problems in practice. See also
1911    <xref target="BCP97"/>.
1912  </annotation>
1913</reference>
1914
1915<reference anchor="RFC1952">
1916  <front>
1917    <title>GZIP file format specification version 4.3</title>
1918    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
1919      <organization>Aladdin Enterprises</organization>
1920      <address><email>ghost@aladdin.com</email></address>
1921    </author>
1922    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">
1923      <address><email>gzip@prep.ai.mit.edu</email></address>
1924    </author>
1925    <author initials="M." surname="Adler" fullname="Mark Adler">
1926      <address><email>madler@alumni.caltech.edu</email></address>
1927    </author>
1928    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
1929      <address><email>ghost@aladdin.com</email></address>
1930    </author>
1931    <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson">
1932      <address><email>randeg@alumni.rpi.edu</email></address>
1933    </author>
1934    <date month="May" year="1996"/>
1935  </front>
1936  <seriesInfo name="RFC" value="1952"/>
1937  <annotation>
1938    RFC 1952 is an Informational RFC, thus it might be less stable than
1939    this specification. On the other hand, this downward reference was
1940    present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,
1941    therefore it is unlikely to cause problems in practice. See also
1942    <xref target="BCP97"/>.
1943  </annotation>
1944</reference>
1945
1946<reference anchor="RFC2045">
1947  <front>
1948    <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
1949    <author initials="N." surname="Freed" fullname="Ned Freed">
1950      <organization>Innosoft International, Inc.</organization>
1951      <address><email>ned@innosoft.com</email></address>
1952    </author>
1953    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
1954      <organization>First Virtual Holdings</organization>
1955      <address><email>nsb@nsb.fv.com</email></address>
1956    </author>
1957    <date month="November" year="1996"/>
1958  </front>
1959  <seriesInfo name="RFC" value="2045"/>
1960</reference>
1961
1962<reference anchor="RFC2046">
1963  <front>
1964    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
1965    <author initials="N." surname="Freed" fullname="Ned Freed">
1966      <organization>Innosoft International, Inc.</organization>
1967      <address><email>ned@innosoft.com</email></address>
1968    </author>
1969    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
1970      <organization>First Virtual Holdings</organization>
1971      <address><email>nsb@nsb.fv.com</email></address>
1972    </author>
1973    <date month="November" year="1996"/>
1974  </front>
1975  <seriesInfo name="RFC" value="2046"/>
1976</reference>
1977
1978<reference anchor="RFC2119">
1979  <front>
1980    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1981    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1982      <organization>Harvard University</organization>
1983      <address><email>sob@harvard.edu</email></address>
1984    </author>
1985    <date month="March" year="1997"/>
1986  </front>
1987  <seriesInfo name="BCP" value="14"/>
1988  <seriesInfo name="RFC" value="2119"/>
1989</reference>
1990
1991<reference anchor='RFC4647'>
1992  <front>
1993    <title>Matching of Language Tags</title>
1994    <author initials='A.' surname='Phillips' fullname='Addison Phillips' role="editor">
1995      <organization>Yahoo! Inc.</organization>
1996      <address><email>addison@inter-locale.com</email></address>
1997    </author>
1998    <author initials='M.' surname='Davis' fullname='Mark Davis' role="editor">
1999      <organization>Google</organization>
2000      <address><email>mark.davis@macchiato.com</email></address>
2001    </author>
2002    <date year='2006' month='September' />
2003  </front>
2004  <seriesInfo name='BCP' value='47' />
2005  <seriesInfo name='RFC' value='4647' />
2006</reference>
2007
2008<reference anchor="RFC5234">
2009  <front>
2010    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
2011    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
2012      <organization>Brandenburg InternetWorking</organization>
2013      <address>
2014        <email>dcrocker@bbiw.net</email>
2015      </address> 
2016    </author>
2017    <author initials="P." surname="Overell" fullname="Paul Overell">
2018      <organization>THUS plc.</organization>
2019      <address>
2020        <email>paul.overell@thus.net</email>
2021      </address>
2022    </author>
2023    <date month="January" year="2008"/>
2024  </front>
2025  <seriesInfo name="STD" value="68"/>
2026  <seriesInfo name="RFC" value="5234"/>
2027</reference>
2028
2029<reference anchor='RFC5646'>
2030  <front>
2031    <title>Tags for Identifying Languages</title>
2032    <author initials='A.' surname='Phillips' fullname='Addison Phillips' role='editor'>
2033      <organization>Lab126</organization>
2034      <address><email>addison@inter-locale.com</email></address>
2035    </author>
2036    <author initials='M.' surname='Davis' fullname='Mark Davis' role='editor'>
2037      <organization>Google</organization>
2038      <address><email>mark.davis@google.com</email></address>
2039    </author>
2040    <date month='September' year='2009' />
2041  </front>
2042  <seriesInfo name='BCP' value='47' />
2043  <seriesInfo name='RFC' value='5646' />
2044</reference>
2045
2046</references>
2047
2048<references title="Informative References">
2049
2050<reference anchor="RFC1945">
2051  <front>
2052    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
2053    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2054      <organization>MIT, Laboratory for Computer Science</organization>
2055      <address><email>timbl@w3.org</email></address>
2056    </author>
2057    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
2058      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
2059      <address><email>fielding@ics.uci.edu</email></address>
2060    </author>
2061    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
2062      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
2063      <address><email>frystyk@w3.org</email></address>
2064    </author>
2065    <date month="May" year="1996"/>
2066  </front>
2067  <seriesInfo name="RFC" value="1945"/>
2068</reference>
2069
2070<reference anchor="RFC2049">
2071  <front>
2072    <title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title>
2073    <author initials="N." surname="Freed" fullname="Ned Freed">
2074      <organization>Innosoft International, Inc.</organization>
2075      <address><email>ned@innosoft.com</email></address>
2076    </author>
2077    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
2078      <organization>First Virtual Holdings</organization>
2079      <address><email>nsb@nsb.fv.com</email></address>
2080    </author>
2081    <date month="November" year="1996"/>
2082  </front>
2083  <seriesInfo name="RFC" value="2049"/>
2084</reference>
2085
2086<reference anchor="RFC2068">
2087  <front>
2088    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
2089    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
2090      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
2091      <address><email>fielding@ics.uci.edu</email></address>
2092    </author>
2093    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2094      <organization>MIT Laboratory for Computer Science</organization>
2095      <address><email>jg@w3.org</email></address>
2096    </author>
2097    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2098      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
2099      <address><email>mogul@wrl.dec.com</email></address>
2100    </author>
2101    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
2102      <organization>MIT Laboratory for Computer Science</organization>
2103      <address><email>frystyk@w3.org</email></address>
2104    </author>
2105    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2106      <organization>MIT Laboratory for Computer Science</organization>
2107      <address><email>timbl@w3.org</email></address>
2108    </author>
2109    <date month="January" year="1997"/>
2110  </front>
2111  <seriesInfo name="RFC" value="2068"/>
2112</reference>
2113
2114<reference anchor="RFC2076">
2115  <front>
2116    <title abbrev="Internet Message Headers">Common Internet Message Headers</title>
2117    <author initials="J." surname="Palme" fullname="Jacob Palme">
2118      <organization>Stockholm University/KTH</organization>
2119      <address><email>jpalme@dsv.su.se</email></address>
2120    </author>
2121    <date month="February" year="1997"/>
2122  </front>
2123  <seriesInfo name="RFC" value="2076"/>
2124</reference>
2125
2126<reference anchor="RFC2277">
2127  <front>
2128    <title abbrev="Charset Policy">IETF Policy on Character Sets and Languages</title>
2129    <author initials="H.T." surname="Alvestrand" fullname="Harald Tveit Alvestrand">
2130      <organization>UNINETT</organization>
2131      <address><email>Harald.T.Alvestrand@uninett.no</email></address>
2132    </author>
2133    <date month="January" year="1998"/>
2134  </front>
2135  <seriesInfo name="BCP" value="18"/>
2136  <seriesInfo name="RFC" value="2277"/>
2137</reference>
2138
2139<reference anchor='RFC2295'>
2140  <front>
2141    <title abbrev='HTTP Content Negotiation'>Transparent Content Negotiation in HTTP</title>
2142    <author initials='K.' surname='Holtman' fullname='Koen Holtman'>
2143      <organization>Technische Universiteit Eindhoven</organization>
2144      <address>
2145        <email>koen@win.tue.nl</email>
2146      </address>
2147    </author>
2148    <author initials='A.H.' surname='Mutz' fullname='Andrew H. Mutz'>
2149      <organization>Hewlett-Packard Company</organization>
2150      <address>
2151        <email>mutz@hpl.hp.com</email>
2152      </address>
2153    </author>
2154    <date year='1998' month='March'/>
2155  </front>
2156  <seriesInfo name='RFC' value='2295'/>
2157</reference>
2158
2159<reference anchor="RFC2388">
2160  <front>
2161    <title abbrev="multipart/form-data">Returning Values from Forms:  multipart/form-data</title>
2162    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2163      <organization>Xerox Palo Alto Research Center</organization>
2164      <address><email>masinter@parc.xerox.com</email></address>
2165    </author>
2166    <date year="1998" month="August"/>
2167  </front>
2168  <seriesInfo name="RFC" value="2388"/>
2169</reference>
2170
2171<reference anchor="RFC2557">
2172  <front>
2173    <title abbrev="MIME Encapsulation of Aggregate Documents">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</title>
2174    <author initials="F." surname="Palme" fullname="Jacob Palme">
2175      <organization>Stockholm University and KTH</organization>
2176      <address><email>jpalme@dsv.su.se</email></address>
2177    </author>
2178    <author initials="A." surname="Hopmann" fullname="Alex Hopmann">
2179      <organization>Microsoft Corporation</organization>
2180      <address><email>alexhop@microsoft.com</email></address>
2181    </author>
2182    <author initials="N." surname="Shelness" fullname="Nick Shelness">
2183      <organization>Lotus Development Corporation</organization>
2184      <address><email>Shelness@lotus.com</email></address>
2185    </author>
2186    <author initials="E." surname="Stefferud" fullname="Einar Stefferud">
2187      <address><email>stef@nma.com</email></address>
2188    </author>
2189    <date year="1999" month="March"/>
2190  </front>
2191  <seriesInfo name="RFC" value="2557"/>
2192</reference>
2193
2194<reference anchor="RFC2616">
2195  <front>
2196    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
2197    <author initials="R." surname="Fielding" fullname="R. Fielding">
2198      <organization>University of California, Irvine</organization>
2199      <address><email>fielding@ics.uci.edu</email></address>
2200    </author>
2201    <author initials="J." surname="Gettys" fullname="J. Gettys">
2202      <organization>W3C</organization>
2203      <address><email>jg@w3.org</email></address>
2204    </author>
2205    <author initials="J." surname="Mogul" fullname="J. Mogul">
2206      <organization>Compaq Computer Corporation</organization>
2207      <address><email>mogul@wrl.dec.com</email></address>
2208    </author>
2209    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
2210      <organization>MIT Laboratory for Computer Science</organization>
2211      <address><email>frystyk@w3.org</email></address>
2212    </author>
2213    <author initials="L." surname="Masinter" fullname="L. Masinter">
2214      <organization>Xerox Corporation</organization>
2215      <address><email>masinter@parc.xerox.com</email></address>
2216    </author>
2217    <author initials="P." surname="Leach" fullname="P. Leach">
2218      <organization>Microsoft Corporation</organization>
2219      <address><email>paulle@microsoft.com</email></address>
2220    </author>
2221    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
2222      <organization>W3C</organization>
2223      <address><email>timbl@w3.org</email></address>
2224    </author>
2225    <date month="June" year="1999"/>
2226  </front>
2227  <seriesInfo name="RFC" value="2616"/>
2228</reference>
2229
2230<reference anchor="RFC3629">
2231  <front>
2232    <title>UTF-8, a transformation format of ISO 10646</title>
2233    <author initials="F." surname="Yergeau" fullname="F. Yergeau">
2234      <organization>Alis Technologies</organization>
2235      <address><email>fyergeau@alis.com</email></address>
2236    </author>
2237    <date month="November" year="2003"/>
2238  </front>
2239  <seriesInfo name="STD" value="63"/>
2240  <seriesInfo name="RFC" value="3629"/>
2241</reference>
2242
2243<reference anchor='RFC3864'>
2244  <front>
2245    <title>Registration Procedures for Message Header Fields</title>
2246    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
2247      <organization>Nine by Nine</organization>
2248      <address><email>GK-IETF@ninebynine.org</email></address>
2249    </author>
2250    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
2251      <organization>BEA Systems</organization>
2252      <address><email>mnot@pobox.com</email></address>
2253    </author>
2254    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
2255      <organization>HP Labs</organization>
2256      <address><email>JeffMogul@acm.org</email></address>
2257    </author>
2258    <date year='2004' month='September' />
2259  </front>
2260  <seriesInfo name='BCP' value='90' />
2261  <seriesInfo name='RFC' value='3864' />
2262</reference>
2263
2264<reference anchor="RFC4288">
2265  <front>
2266    <title>Media Type Specifications and Registration Procedures</title>
2267    <author initials="N." surname="Freed" fullname="N. Freed">
2268      <organization>Sun Microsystems</organization>
2269      <address>
2270        <email>ned.freed@mrochek.com</email>
2271      </address>
2272    </author>
2273    <author initials="J." surname="Klensin" fullname="J. Klensin">
2274      <address>
2275        <email>klensin+ietf@jck.com</email>
2276      </address>
2277    </author>
2278    <date year="2005" month="December"/>
2279  </front>
2280  <seriesInfo name="BCP" value="13"/>
2281  <seriesInfo name="RFC" value="4288"/>
2282</reference>
2283
2284<reference anchor='RFC5226'>
2285  <front>
2286    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
2287    <author initials='T.' surname='Narten' fullname='T. Narten'>
2288      <organization>IBM</organization>
2289      <address><email>narten@us.ibm.com</email></address>
2290    </author>
2291    <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
2292      <organization>Google</organization>
2293      <address><email>Harald@Alvestrand.no</email></address>
2294    </author>
2295    <date year='2008' month='May' />
2296  </front>
2297  <seriesInfo name='BCP' value='26' />
2298  <seriesInfo name='RFC' value='5226' />
2299</reference>
2300
2301<reference anchor="RFC5322">
2302  <front>
2303    <title>Internet Message Format</title>
2304    <author initials="P." surname="Resnick" fullname="P. Resnick">
2305      <organization>Qualcomm Incorporated</organization>
2306    </author>
2307    <date year="2008" month="October"/>
2308  </front> 
2309  <seriesInfo name="RFC" value="5322"/>
2310</reference>
2311
2312<reference anchor="RFC6151">
2313  <front>
2314    <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
2315    <author initials="S." surname="Turner" fullname="S. Turner"/>
2316    <author initials="L." surname="Chen" fullname="L. Chen"/>
2317    <date year="2011" month="March" />
2318  </front>
2319  <seriesInfo name="RFC" value="6151" />
2320</reference>
2321
2322<reference anchor='BCP97'>
2323  <front>
2324    <title>Handling Normative References to Standards-Track Documents</title>
2325    <author initials='J.' surname='Klensin' fullname='J. Klensin'>
2326      <address>
2327        <email>klensin+ietf@jck.com</email>
2328      </address>
2329    </author>
2330    <author initials='S.' surname='Hartman' fullname='S. Hartman'>
2331      <organization>MIT</organization>
2332      <address>
2333        <email>hartmans-ietf@mit.edu</email>
2334      </address>
2335    </author>
2336    <date year='2007' month='June' />
2337  </front>
2338  <seriesInfo name='BCP' value='97' />
2339  <seriesInfo name='RFC' value='4897' />
2340</reference>
2341
2342<reference anchor="RFC6266">
2343  <front>
2344    <title abbrev="Content-Disposition in HTTP">Use of the Content-Disposition Header Field
2345    in the Hypertext Transfer Protocol (HTTP)</title>
2346    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
2347      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2348      <address>
2349        <email>julian.reschke@greenbytes.de</email>
2350      </address>
2351    </author>
2352    <date month="June" year="2011"/>
2353  </front>
2354  <seriesInfo name='RFC' value='6266' />
2355</reference>
2356
2357</references>
2358
2359<section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime">
2360<t>
2361   HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
2362   allow a message-body to be transmitted in an open variety of
2363   representations and with extensible mechanisms. However, RFC 2045
2364   discusses mail, and HTTP has a few features that are different from
2365   those described in MIME. These differences were carefully chosen
2366   to optimize performance over binary connections, to allow greater
2367   freedom in the use of new media types, to make date comparisons
2368   easier, and to acknowledge the practice of some early HTTP servers
2369   and clients.
2370</t>
2371<t>
2372   This appendix describes specific areas where HTTP differs from MIME.
2373   Proxies and gateways to strict MIME environments &SHOULD; be
2374   aware of these differences and provide the appropriate conversions
2375   where necessary. Proxies and gateways from MIME environments to HTTP
2376   also need to be aware of the differences because some conversions
2377   might be required.
2378</t>
2379
2380<section title="MIME-Version" anchor="mime-version">
2381  <iref primary="true" item="MIME-Version header field" x:for-anchor=""/>
2382  <iref primary="true" item="Header Fields" subitem="MIME-Version" x:for-anchor=""/>
2383  <x:anchor-alias value="MIME-Version"/>
2384<t>
2385   HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY;
2386   include a single MIME-Version header field to indicate what
2387   version of the MIME protocol was used to construct the message. Use
2388   of the MIME-Version header field indicates that the message is in
2389   full compliance with the MIME protocol (as defined in <xref target="RFC2045"/>).
2390   Proxies/gateways are responsible for ensuring full compliance (where
2391   possible) when exporting HTTP messages to strict MIME environments.
2392</t>
2393<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="MIME-Version"/>
2394  <x:ref>MIME-Version</x:ref> = 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
2395</artwork></figure>
2396<t>
2397   MIME version "1.0" is the default for use in HTTP/1.1. However,
2398   HTTP/1.1 message parsing and semantics are defined by this document
2399   and not the MIME specification.
2400</t>
2401</section>
2402
2403<section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
2404<t>
2405   MIME requires that an Internet mail body-part be converted to
2406   canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>.
2407   <xref target="canonicalization.and.text.defaults"/> of this document describes the forms
2408   allowed for subtypes of the "text" media type when transmitted over
2409   HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent
2410   line breaks as CRLF and forbids the use of CR or LF outside of line
2411   break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
2412   line break within text content when a message is transmitted over
2413   HTTP.
2414</t>
2415<t>
2416   Where it is possible, a proxy or gateway from HTTP to a strict MIME
2417   environment &SHOULD; translate all line breaks within the text media
2418   types described in <xref target="canonicalization.and.text.defaults"/>
2419   of this document to the RFC 2049
2420   canonical form of CRLF. Note, however, that this might be complicated
2421   by the presence of a Content-Encoding and by the fact that HTTP
2422   allows the use of some character encodings which do not use octets 13 and
2423   10 to represent CR and LF, respectively, as is the case for some multi-byte
2424   character encodings.
2425</t>
2426<t>
2427   Conversion will break any cryptographic
2428   checksums applied to the original content unless the original content
2429   is already in canonical form. Therefore, the canonical form is
2430   recommended for any content that uses such checksums in HTTP.
2431</t>
2432</section>
2433
2434
2435<section title="Conversion of Date Formats" anchor="conversion.of.date.formats">
2436<t>
2437   HTTP/1.1 uses a restricted set of date formats (&http-date;) to
2438   simplify the process of date comparison. Proxies and gateways from
2439   other protocols &SHOULD; ensure that any Date header field present in a
2440   message conforms to one of the HTTP/1.1 formats and rewrite the date
2441   if necessary.
2442</t>
2443</section>
2444
2445<section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding">
2446<t>
2447   MIME does not include any concept equivalent to HTTP/1.1's
2448   Content-Encoding header field. Since this acts as a modifier on the
2449   media type, proxies and gateways from HTTP to MIME-compliant
2450   protocols &MUST; either change the value of the Content-Type header
2451   field or decode the representation before forwarding the message. (Some
2452   experimental applications of Content-Type for Internet mail have used
2453   a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
2454   a function equivalent to Content-Encoding. However, this parameter is
2455   not part of the MIME standards).
2456</t>
2457</section>
2458
2459<section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding">
2460<t>
2461   HTTP does not use the Content-Transfer-Encoding field of MIME.
2462   Proxies and gateways from MIME-compliant protocols to HTTP &MUST;
2463   remove any Content-Transfer-Encoding
2464   prior to delivering the response message to an HTTP client.
2465</t>
2466<t>
2467   Proxies and gateways from HTTP to MIME-compliant protocols are
2468   responsible for ensuring that the message is in the correct format
2469   and encoding for safe transport on that protocol, where "safe
2470   transport" is defined by the limitations of the protocol being used.
2471   Such a proxy or gateway &SHOULD; label the data with an appropriate
2472   Content-Transfer-Encoding if doing so will improve the likelihood of
2473   safe transport over the destination protocol.
2474</t>
2475</section>
2476
2477<section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding">
2478<t>
2479   HTTP/1.1 introduces the Transfer-Encoding header field (&header-transfer-encoding;).
2480   Proxies/gateways &MUST; remove any transfer-coding prior to
2481   forwarding a message via a MIME-compliant protocol.
2482</t>
2483</section>
2484
2485<section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
2486<t>
2487   HTTP implementations which share code with MHTML <xref target="RFC2557"/> implementations
2488   need to be aware of MIME line length limitations. Since HTTP does not
2489   have this limitation, HTTP does not fold long lines. MHTML messages
2490   being transported by HTTP follow all conventions of MHTML, including
2491   line length limitations and folding, canonicalization, etc., since
2492   HTTP transports all message-bodies as payload (see <xref target="multipart.types"/>) and
2493   does not interpret the content or any MIME header lines that might be
2494   contained therein.
2495</t>
2496</section>
2497</section>
2498
2499<section title="Additional Features" anchor="additional.features">
2500<t>
2501   <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some
2502   existing HTTP implementations, but not consistently and correctly
2503   across most HTTP/1.1 applications. Implementors are advised to be
2504   aware of these features, but cannot rely upon their presence in, or
2505   interoperability with, other HTTP/1.1 applications. Some of these
2506   describe proposed experimental features, and some describe features
2507   that experimental deployment found lacking that are now addressed in
2508   the base HTTP/1.1 specification.
2509</t>
2510<t>
2511   A number of other header fields, such as Content-Disposition and Title,
2512   from SMTP and MIME are also often implemented (see <xref target="RFC6266"/>
2513   and <xref target="RFC2076"/>).
2514</t>
2515</section>
2516
2517<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
2518<t>
2519  Clarify contexts that charset is used in.
2520  (<xref target="character.sets"/>)
2521</t>
2522<t>
2523  Remove the default character encoding for text media types; the default
2524  now is whatever the media type definition says.
2525  (<xref target="canonicalization.and.text.defaults"/>)
2526</t>
2527<t>
2528  Change ABNF productions for header fields to only define the field value.
2529  (<xref target="header.field.definitions"/>)
2530</t>
2531<t>
2532  Remove definition of Content-MD5 header field because it was inconsistently
2533  implemented with respect to partial responses, and also because of known
2534  deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for details).
2535  (<xref target="header.field.definitions"/>)
2536</t>
2537<t>
2538  Remove ISO-8859-1 special-casing in Accept-Charset.
2539  (<xref target="header.accept-charset"/>)
2540</t>
2541<t>
2542  Remove base URI setting semantics for Content-Location due to poor
2543  implementation support, which was caused by too many broken servers emitting
2544  bogus Content-Location header fields, and also the potentially undesirable effect
2545  of potentially breaking relative links in content-negotiated resources.
2546  (<xref target="header.content-location"/>)
2547</t>
2548<t>
2549  Remove discussion of Content-Disposition header field, it is now defined
2550  by <xref target="RFC6266"/>.
2551  (<xref target="additional.features"/>)
2552</t>
2553<t>
2554  Remove reference to non-existant identity transfer-coding value tokens.
2555  (<xref target="no.content-transfer-encoding"/>)
2556</t>
2557</section>
2558
2559<?BEGININC p3-payload.abnf-appendix ?>
2560<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
2561<figure>
2562<artwork type="abnf" name="p3-payload.parsed-abnf">
2563<x:ref>Accept</x:ref> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2564 OWS media-range [ accept-params ] ] ) ]
2565<x:ref>Accept-Charset</x:ref> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
2566 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
2567 qvalue ] ] )
2568<x:ref>Accept-Encoding</x:ref> = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )
2569 *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
2570<x:ref>Accept-Language</x:ref> = *( "," OWS ) language-range [ OWS ";" OWS "q="
2571 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
2572 ] )
2573
2574<x:ref>Content-Encoding</x:ref> = *( "," OWS ) content-coding *( OWS "," [ OWS
2575 content-coding ] )
2576<x:ref>Content-Language</x:ref> = *( "," OWS ) language-tag *( OWS "," [ OWS
2577 language-tag ] )
2578<x:ref>Content-Location</x:ref> = absolute-URI / partial-URI
2579<x:ref>Content-Type</x:ref> = media-type
2580
2581<x:ref>MIME-Version</x:ref> = 1*DIGIT "." 1*DIGIT
2582
2583<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 1.2.2&gt;
2584
2585<x:ref>absolute-URI</x:ref> = &lt;absolute-URI, defined in [Part1], Section 2.7&gt;
2586<x:ref>accept-ext</x:ref> = OWS ";" OWS token [ "=" word ]
2587<x:ref>accept-params</x:ref> = OWS ";" OWS "q=" qvalue *accept-ext
2588<x:ref>attribute</x:ref> = token
2589
2590<x:ref>charset</x:ref> = token
2591<x:ref>codings</x:ref> = content-coding / "identity" / "*"
2592<x:ref>content-coding</x:ref> = token
2593
2594<x:ref>language-range</x:ref> = &lt;language-range, defined in [RFC4647], Section 2.1&gt;
2595<x:ref>language-tag</x:ref> = &lt;Language-Tag, defined in [RFC5646], Section 2.1&gt;
2596
2597<x:ref>media-range</x:ref> = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
2598 ";" OWS parameter )
2599<x:ref>media-type</x:ref> = type "/" subtype *( OWS ";" OWS parameter )
2600
2601<x:ref>parameter</x:ref> = attribute "=" value
2602<x:ref>partial-URI</x:ref> = &lt;partial-URI, defined in [Part1], Section 2.7&gt;
2603
2604<x:ref>qvalue</x:ref> = &lt;qvalue, defined in [Part1], Section 5.3&gt;
2605
2606<x:ref>subtype</x:ref> = token
2607
2608<x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 3.2.3&gt;
2609<x:ref>type</x:ref> = token
2610
2611<x:ref>value</x:ref> = word
2612
2613<x:ref>word</x:ref> = &lt;word, defined in [Part1], Section 3.2.3&gt;
2614</artwork>
2615</figure>
2616<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline">
2617; Accept defined but not used
2618; Accept-Charset defined but not used
2619; Accept-Encoding defined but not used
2620; Accept-Language defined but not used
2621; Content-Encoding defined but not used
2622; Content-Language defined but not used
2623; Content-Location defined but not used
2624; Content-Type defined but not used
2625; MIME-Version defined but not used
2626</artwork></figure></section>
2627<?ENDINC p3-payload.abnf-appendix ?>
2628
2629<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
2630
2631<section title="Since RFC 2616">
2632<t>
2633  Extracted relevant partitions from <xref target="RFC2616"/>.
2634</t>
2635</section>
2636
2637<section title="Since draft-ietf-httpbis-p3-payload-00">
2638<t>
2639  Closed issues:
2640  <list style="symbols"> 
2641    <t>
2642      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/8"/>:
2643      "Media Type Registrations"
2644      (<eref target="http://purl.org/NET/http-errata#media-reg"/>)
2645    </t>
2646    <t>
2647      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/14"/>:
2648      "Clarification regarding quoting of charset values"
2649      (<eref target="http://purl.org/NET/http-errata#charactersets"/>)
2650    </t>
2651    <t>
2652      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/16"/>:
2653      "Remove 'identity' token references"
2654      (<eref target="http://purl.org/NET/http-errata#identity"/>)
2655    </t>
2656    <t>
2657      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/25"/>:
2658      "Accept-Encoding BNF"
2659    </t>
2660    <t>
2661      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
2662      "Normative and Informative references"
2663    </t>
2664    <t>
2665      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/46"/>:
2666      "RFC1700 references"
2667    </t>
2668    <t>
2669      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/55"/>:
2670      "Updating to RFC4288"
2671    </t>
2672    <t>
2673      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>:
2674      "Informative references"
2675    </t>
2676    <t>
2677      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/66"/>:
2678      "ISO-8859-1 Reference"
2679    </t>
2680    <t>
2681      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/68"/>:
2682      "Encoding References Normative"
2683    </t>
2684    <t>
2685      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86"/>:
2686      "Normative up-to-date references"
2687    </t>
2688  </list>
2689</t>
2690</section>
2691
2692<section title="Since draft-ietf-httpbis-p3-payload-01">
2693<t>
2694  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
2695  <list style="symbols"> 
2696    <t>
2697      Add explicit references to BNF syntax and rules imported from other parts of the specification.
2698    </t>
2699  </list>
2700</t>
2701</section>
2702
2703<section title="Since draft-ietf-httpbis-p3-payload-02" anchor="changes.since.02">
2704<t>
2705  Closed issues:
2706  <list style="symbols"> 
2707    <t>
2708      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/67"/>:
2709      "Quoting Charsets"
2710    </t>
2711    <t>
2712      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>:
2713      "Classification for Allow header"
2714    </t>
2715    <t>
2716      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/115"/>:
2717      "missing default for qvalue in description of Accept-Encoding"
2718    </t>
2719  </list>
2720</t>
2721<t>
2722  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
2723  <list style="symbols"> 
2724    <t>
2725      Reference RFC 3984, and update header field registrations for headers defined
2726      in this document.
2727    </t>
2728  </list>
2729</t>
2730</section>
2731
2732<section title="Since draft-ietf-httpbis-p3-payload-03" anchor="changes.since.03">
2733<t>
2734  Closed issues:
2735  <list style="symbols"> 
2736    <t>
2737      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/67"/>:
2738      "Quoting Charsets"
2739    </t>
2740    <t>
2741      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/113"/>:
2742      "language tag matching (Accept-Language) vs RFC4647"
2743    </t>
2744    <t>
2745      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/121"/>:
2746      "RFC 1806 has been replaced by RFC2183"
2747    </t>
2748  </list>
2749</t>
2750<t>
2751  Other changes:
2752  <list style="symbols"> 
2753    <t>
2754      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/68"/>:
2755      "Encoding References Normative" &mdash; rephrase the annotation and reference
2756      <xref target="BCP97"/>.
2757    </t>
2758  </list>
2759</t>
2760 </section>
2761
2762<section title="Since draft-ietf-httpbis-p3-payload-04" anchor="changes.since.04">
2763<t>
2764  Closed issues:
2765  <list style="symbols"> 
2766    <t>
2767      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>:
2768      "RFC 2822 is updated by RFC 5322"
2769    </t>
2770  </list>
2771</t>
2772<t>
2773  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
2774  <list style="symbols"> 
2775    <t>
2776      Use "/" instead of "|" for alternatives.
2777    </t>
2778    <t>
2779      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2780      whitespace ("OWS") and required whitespace ("RWS").
2781    </t>
2782    <t>
2783      Rewrite ABNFs to spell out whitespace rules, factor out
2784      header field value format definitions.
2785    </t>
2786  </list>
2787</t>
2788</section>
2789
2790<section title="Since draft-ietf-httpbis-p3-payload-05" anchor="changes.since.05">
2791<t>
2792  Closed issues:
2793  <list style="symbols"> 
2794    <t>
2795      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/118"/>:
2796      "Join "Differences Between HTTP Entities and RFC 2045 Entities"?"
2797    </t>
2798  </list>
2799</t>
2800<t>
2801  Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
2802  <list style="symbols"> 
2803    <t>
2804      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
2805    </t>
2806  </list>
2807</t>
2808<t>
2809  Other changes:
2810  <list style="symbols"> 
2811    <t>
2812      Move definition of quality values into Part 1.
2813    </t>
2814  </list>
2815</t>
2816</section>
2817
2818<section title="Since draft-ietf-httpbis-p3-payload-06" anchor="changes.since.06">
2819<t>
2820  Closed issues:
2821  <list style="symbols"> 
2822    <t>
2823      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/80"/>:
2824      "Content-Location isn't special"
2825    </t>
2826    <t>
2827      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>:
2828      "Content Sniffing"
2829    </t>
2830  </list>
2831</t>
2832</section>
2833
2834<section title="Since draft-ietf-httpbis-p3-payload-07" anchor="changes.since.07">
2835<t>
2836  Closed issues:
2837  <list style="symbols"> 
2838    <t>
2839      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/13"/>:
2840      "Updated reference for language tags"
2841    </t>
2842    <t>
2843      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>:
2844      "Clarify rules for determining what entities a response carries"
2845    </t>
2846    <t>
2847      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/154"/>:
2848      "Content-Location base-setting problems"
2849    </t>
2850    <t>
2851      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>:
2852      "Content Sniffing"
2853    </t>
2854    <t>
2855      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/188"/>:
2856      "pick IANA policy (RFC5226) for Transfer Coding / Content Coding"
2857    </t>
2858    <t>
2859      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/189"/>:
2860      "move definitions of gzip/deflate/compress to part 1"
2861    </t>
2862  </list>
2863</t>
2864<t>
2865  Partly resolved issues:
2866  <list style="symbols"> 
2867    <t>
2868      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/148"/>:
2869      "update IANA requirements wrt Transfer-Coding values" (add the
2870      IANA Considerations subsection)
2871    </t>
2872    <t>
2873      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/149"/>:
2874      "update IANA requirements wrt Content-Coding values" (add the
2875      IANA Considerations subsection)
2876    </t>
2877  </list>
2878</t>
2879</section>
2880
2881<section title="Since draft-ietf-httpbis-p3-payload-08" anchor="changes.since.08">
2882<t>
2883  Closed issues:
2884  <list style="symbols"> 
2885    <t>
2886      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/81"/>:
2887      "Content Negotiation for media types"
2888    </t>
2889    <t>
2890      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/181"/>:
2891      "Accept-Language: which RFC4647 filtering?"
2892    </t>
2893  </list>
2894</t>
2895</section>
2896
2897<section title="Since draft-ietf-httpbis-p3-payload-09" anchor="changes.since.09">
2898<t>
2899  Closed issues:
2900  <list style="symbols"> 
2901    <t>
2902      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/122"/>:
2903      "MIME-Version not listed in P1, general header fields"
2904    </t>
2905    <t>
2906      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/143"/>:
2907      "IANA registry for content/transfer encodings"
2908    </t>
2909    <t>
2910      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>:
2911      "Content Sniffing"
2912    </t>
2913    <t>
2914      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
2915      "use of term "word" when talking about header structure"
2916    </t>
2917  </list>
2918</t>
2919<t>
2920  Partly resolved issues:
2921  <list style="symbols"> 
2922    <t>
2923      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
2924      "Term for the requested resource's URI"
2925    </t>
2926  </list>
2927</t>
2928</section>
2929
2930<section title="Since draft-ietf-httpbis-p3-payload-10" anchor="changes.since.10">
2931<t>
2932  Closed issues:
2933  <list style="symbols"> 
2934    <t>
2935      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/69"/>:
2936      "Clarify 'Requested Variant'"
2937    </t>
2938    <t>
2939      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/80"/>:
2940      "Content-Location isn't special"
2941    </t>
2942    <t>
2943      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/90"/>:
2944      "Delimiting messages with multipart/byteranges"
2945    </t>
2946    <t>
2947      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
2948      "Clarify entity / representation / variant terminology"
2949    </t>
2950    <t>
2951      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/136"/>:
2952      "confusing req. language for Content-Location"
2953    </t>
2954    <t>
2955      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/167"/>:
2956      "Content-Location on 304 responses"
2957    </t>
2958    <t>
2959      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/183"/>:
2960      "'requested resource' in content-encoding definition"
2961    </t>
2962    <t>
2963      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
2964      "consider removing the 'changes from 2068' sections"
2965    </t>
2966  </list>
2967</t>
2968<t>
2969  Partly resolved issues:
2970  <list style="symbols"> 
2971    <t>
2972      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/178"/>:
2973      "Content-MD5 and partial responses"
2974    </t>
2975  </list>
2976</t>
2977</section>
2978
2979<section title="Since draft-ietf-httpbis-p3-payload-11" anchor="changes.since.11">
2980<t>
2981  Closed issues:
2982  <list style="symbols"> 
2983    <t>
2984      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/123"/>:
2985      "Factor out Content-Disposition"
2986    </t>
2987  </list>
2988</t>
2989</section>
2990
2991<section title="Since draft-ietf-httpbis-p3-payload-12" anchor="changes.since.12">
2992<t>
2993  Closed issues:
2994  <list style="symbols"> 
2995    <t>
2996      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
2997      "Header Classification"
2998    </t>
2999    <t>
3000      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
3001      "untangle ABNFs for header fields"
3002    </t>
3003    <t>
3004      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/277"/>:
3005      "potentially misleading MAY in media-type def"
3006    </t>
3007  </list>
3008</t>
3009</section>
3010
3011<section title="Since draft-ietf-httpbis-p3-payload-13" anchor="changes.since.13">
3012<t>
3013  Closed issues:
3014  <list style="symbols"> 
3015    <t>
3016      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/20"/>:
3017      "Default charsets for text media types"
3018    </t>
3019    <t>
3020      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/178"/>:
3021      "Content-MD5 and partial responses"
3022    </t>
3023    <t>
3024      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
3025      "untangle ABNFs for header fields"
3026    </t>
3027    <t>
3028      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/281"/>:
3029      "confusing undefined parameter in media range example"
3030    </t>
3031  </list>
3032</t>
3033</section>
3034
3035<section title="Since draft-ietf-httpbis-p3-payload-14" anchor="changes.since.14">
3036<t>
3037  None.
3038</t>
3039</section>
3040
3041<section title="Since draft-ietf-httpbis-p3-payload-15" anchor="changes.since.15">
3042<t>
3043  Closed issues:
3044  <list style="symbols"> 
3045    <t>
3046      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>:
3047      "Strength of requirements on Accept re: 406"
3048    </t>
3049  </list>
3050</t>
3051</section>
3052
3053<section title="Since draft-ietf-httpbis-p3-payload-16" anchor="changes.since.16">
3054<t>
3055  Closed issues:
3056  <list style="symbols"> 
3057    <t>
3058      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
3059      "Document HTTP's error-handling philosophy"
3060    </t>
3061  </list>
3062</t>
3063</section>
3064
3065</section>
3066
3067</back>
3068</rfc>
Note: See TracBrowser for help on using the repository browser.