source: draft-ietf-httpbis/19/draft-ietf-httpbis-p3-payload-19.txt

Last change on this file was 1596, checked in by fielding@…, 8 years ago

remove executable bit

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