source: draft-ietf-httpbis/12/draft-ietf-httpbis-p3-payload-12.txt @ 1515

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

prepare publication of -12 drafts on 2010-10-25

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