source: draft-ietf-httpbis/08/draft-ietf-httpbis-p3-payload-08.txt @ 1627

Last change on this file since 1627 was 718, checked in by julian.reschke@…, 11 years ago

Prepare for -08 drafts

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