source: draft-ietf-httpbis/14/draft-ietf-httpbis-p3-payload-14.txt @ 1856

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

-14

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