source: draft-ietf-httpbis/15/draft-ietf-httpbis-p3-payload-15.txt @ 2082

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

Fix "none yet" entries in -15 change log entries, update -latest accordingly.

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