source: draft-ietf-httpbis/16/draft-ietf-httpbis-p3-payload-16.xml @ 1860

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

fix mime types

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