source: draft-ietf-httpbis/16/draft-ietf-httpbis-p3-payload-16.txt @ 1831

Last change on this file since 1831 was 1401, checked in by julian.reschke@…, 9 years ago

prepare for publication of -16 on Aug 24.

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