source: draft-ietf-httpbis/13/draft-ietf-httpbis-p3-payload-13.txt @ 1367

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

prepare publication of -13

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