source: draft-ietf-httpbis/00/draft-ietf-httpbis-p3-payload-00.txt @ 63

Last change on this file since 63 was 63, checked in by fielding@…, 12 years ago

Update issues list URI and draft names

  • Property svn:eol-style set to native
File size: 76.5 KB
Line 
1
2
3
4Network Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2068, 2616                                          J. Gettys
7(if approved)                                       One Laptop per Child
8Intended status: Standards Track                                J. Mogul
9Expires: June 22, 2008                                                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                                                       December 20, 2007
19
20
21       HTTP/1.1, part 3: Message Payload and Content Negotiation
22                    draft-ietf-httpbis-p3-payload-00
23
24Status of this Memo
25
26   By submitting this Internet-Draft, each author represents that any
27   applicable patent or other IPR claims of which he or she is aware
28   have been or will be disclosed, and any of which he or she becomes
29   aware will be disclosed, in accordance with Section 6 of BCP 79.
30
31   Internet-Drafts are working documents of the Internet Engineering
32   Task Force (IETF), its areas, and its working groups.  Note that
33   other groups may also distribute working documents as Internet-
34   Drafts.
35
36   Internet-Drafts are draft documents valid for a maximum of six months
37   and may be updated, replaced, or obsoleted by other documents at any
38   time.  It is inappropriate to use Internet-Drafts as reference
39   material or to cite them other than as "work in progress."
40
41   The list of current Internet-Drafts can be accessed at
42   http://www.ietf.org/ietf/1id-abstracts.txt.
43
44   The list of Internet-Draft Shadow Directories can be accessed at
45   http://www.ietf.org/shadow.html.
46
47   This Internet-Draft will expire on June 22, 2008.
48
49Copyright Notice
50
51   Copyright (C) The IETF Trust (2007).
52
53
54
55Fielding, et al.          Expires June 22, 2008                 [Page 1]
56
57Internet-Draft                  HTTP/1.1                   December 2007
58
59
60Abstract
61
62   The Hypertext Transfer Protocol (HTTP) is an application-level
63   protocol for distributed, collaborative, hypermedia information
64   systems.  HTTP has been in use by the World Wide Web global
65   information initiative since 1990.  This document is Part 3 of the
66   seven-part specification that defines the protocol referred to as
67   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 3 defines
68   HTTP message content, metadata, and content negotiation.
69
70Editorial Note (To be removed by RFC Editor)
71
72   This version of the HTTP specification contains only minimal
73   editorial changes from [RFC2616] (abstract, introductory paragraph,
74   and authors' addresses).  All other changes are due to partitioning
75   the original into seven mostly independent parts.  The intent is for
76   readers of future drafts to able to use draft 00 as the basis for
77   comparison when the WG makes later changes to the specification text.
78   This draft will shortly be followed by draft 01 (containing the first
79   round of changes that have already been agreed to on the mailing
80   list).  There is no point in reviewing this draft other than to
81   verify that the partitioning has been done correctly.  Roy T.
82   Fielding, Yves Lafon, and Julian Reschke will be the editors after
83   draft 00 is submitted.
84
85   Discussion of this draft should take place on the HTTPBIS working
86   group mailing list (ietf-http-wg@w3.org).  The current issues list is
87   at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related
88   documents (including fancy diffs) can be found at
89   <http://www3.tools.ietf.org/wg/httpbis/>.
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.          Expires June 22, 2008                 [Page 2]
112
113Internet-Draft                  HTTP/1.1                   December 2007
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
119   2.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . .  5
120     2.1.  Character Sets . . . . . . . . . . . . . . . . . . . . . .  5
121       2.1.1.  Missing Charset  . . . . . . . . . . . . . . . . . . .  6
122     2.2.  Content Codings  . . . . . . . . . . . . . . . . . . . . .  6
123     2.3.  Media Types  . . . . . . . . . . . . . . . . . . . . . . .  7
124       2.3.1.  Canonicalization and Text Defaults . . . . . . . . . .  8
125       2.3.2.  Multipart Types  . . . . . . . . . . . . . . . . . . .  9
126     2.4.  Quality Values . . . . . . . . . . . . . . . . . . . . . .  9
127     2.5.  Language Tags  . . . . . . . . . . . . . . . . . . . . . . 10
128   3.  Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
129     3.1.  Entity Header Fields . . . . . . . . . . . . . . . . . . . 10
130     3.2.  Entity Body  . . . . . . . . . . . . . . . . . . . . . . . 11
131       3.2.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 11
132       3.2.2.  Entity Length  . . . . . . . . . . . . . . . . . . . . 12
133   4.  Content Negotiation  . . . . . . . . . . . . . . . . . . . . . 12
134     4.1.  Server-driven Negotiation  . . . . . . . . . . . . . . . . 12
135     4.2.  Agent-driven Negotiation . . . . . . . . . . . . . . . . . 14
136     4.3.  Transparent Negotiation  . . . . . . . . . . . . . . . . . 14
137   5.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 15
138     5.1.  Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 15
139     5.2.  Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 17
140     5.3.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . . . 17
141     5.4.  Accept-Language  . . . . . . . . . . . . . . . . . . . . . 19
142     5.5.  Content-Encoding . . . . . . . . . . . . . . . . . . . . . 20
143     5.6.  Content-Language . . . . . . . . . . . . . . . . . . . . . 21
144     5.7.  Content-Location . . . . . . . . . . . . . . . . . . . . . 22
145     5.8.  Content-MD5  . . . . . . . . . . . . . . . . . . . . . . . 22
146     5.9.  Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24
147   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
148   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
149     7.1.  Privacy Issues Connected to Accept Headers . . . . . . . . 24
150     7.2.  Content-Disposition Issues . . . . . . . . . . . . . . . . 25
151   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
152   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
153   Appendix A.  Differences Between HTTP Entities and RFC 2045
154                Entities  . . . . . . . . . . . . . . . . . . . . . . 27
155     A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 28
156     A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 28
157     A.3.  Introduction of Content-Encoding . . . . . . . . . . . . . 29
158     A.4.  No Content-Transfer-Encoding . . . . . . . . . . . . . . . 29
159     A.5.  Introduction of Transfer-Encoding  . . . . . . . . . . . . 29
160     A.6.  MHTML and Line Length Limitations  . . . . . . . . . . . . 29
161   Appendix B.  Additional Features . . . . . . . . . . . . . . . . . 30
162     B.1.  Content-Disposition  . . . . . . . . . . . . . . . . . . . 30
163   Appendix C.  Changes from RFC 2068 . . . . . . . . . . . . . . . . 31
164
165
166
167Fielding, et al.          Expires June 22, 2008                 [Page 3]
168
169Internet-Draft                  HTTP/1.1                   December 2007
170
171
172   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
173   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
174   Intellectual Property and Copyright Statements . . . . . . . . . . 36
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223Fielding, et al.          Expires June 22, 2008                 [Page 4]
224
225Internet-Draft                  HTTP/1.1                   December 2007
226
227
2281.  Introduction
229
230   This document will define aspects of HTTP related to the payload of
231   messages (message content), including metadata and media types, along
232   with HTTP content negotiation.  Right now it only includes the
233   extracted relevant sections of RFC 2616 without edit.
234
235
2362.  Protocol Parameters
237
2382.1.  Character Sets
239
240   HTTP uses the same definition of the term "character set" as that
241   described for MIME:
242
243   The term "character set" is used in this document to refer to a
244   method used with one or more tables to convert a sequence of octets
245   into a sequence of characters.  Note that unconditional conversion in
246   the other direction is not required, in that not all characters may
247   be available in a given character set and a character set may provide
248   more than one sequence of octets to represent a particular character.
249   This definition is intended to allow various kinds of character
250   encoding, from simple single-table mappings such as US-ASCII to
251   complex table switching methods such as those that use ISO-2022's
252   techniques.  However, the definition associated with a MIME character
253   set name MUST fully specify the mapping to be performed from octets
254   to characters.  In particular, use of external profiling information
255   to determine the exact mapping is not permitted.
256
257      Note: This use of the term "character set" is more commonly
258      referred to as a "character encoding."  However, since HTTP and
259      MIME share the same registry, it is important that the terminology
260      also be shared.
261
262   HTTP character sets are identified by case-insensitive tokens.  The
263   complete set of tokens is defined by the IANA Character Set registry
264   [RFC1700].
265
266       charset = token
267
268   Although HTTP allows an arbitrary token to be used as a charset
269   value, any token that has a predefined value within the IANA
270   Character Set registry [RFC1700] MUST represent the character set
271   defined by that registry.  Applications SHOULD limit their use of
272   character sets to those defined by the IANA registry.
273
274   Implementors should be aware of IETF character set requirements
275   [RFC2279] [RFC2277].
276
277
278
279Fielding, et al.          Expires June 22, 2008                 [Page 5]
280
281Internet-Draft                  HTTP/1.1                   December 2007
282
283
2842.1.1.  Missing Charset
285
286   Some HTTP/1.0 software has interpreted a Content-Type header without
287   charset parameter incorrectly to mean "recipient should guess."
288   Senders wishing to defeat this behavior MAY include a charset
289   parameter even when the charset is ISO-8859-1 and SHOULD do so when
290   it is known that it will not confuse the recipient.
291
292   Unfortunately, some older HTTP/1.0 clients did not deal properly with
293   an explicit charset parameter.  HTTP/1.1 recipients MUST respect the
294   charset label provided by the sender; and those user agents that have
295   a provision to "guess" a charset MUST use the charset from the
296   content-type field if they support that charset, rather than the
297   recipient's preference, when initially displaying a document.  See
298   Section 2.3.1.
299
3002.2.  Content Codings
301
302   Content coding values indicate an encoding transformation that has
303   been or can be applied to an entity.  Content codings are primarily
304   used to allow a document to be compressed or otherwise usefully
305   transformed without losing the identity of its underlying media type
306   and without loss of information.  Frequently, the entity is stored in
307   coded form, transmitted directly, and only decoded by the recipient.
308
309       content-coding   = token
310
311   All content-coding values are case-insensitive.  HTTP/1.1 uses
312   content-coding values in the Accept-Encoding (Section 5.3) and
313   Content-Encoding (Section 5.5) header fields.  Although the value
314   describes the content-coding, what is more important is that it
315   indicates what decoding mechanism will be required to remove the
316   encoding.
317
318   The Internet Assigned Numbers Authority (IANA) acts as a registry for
319   content-coding value tokens.  Initially, the registry contains the
320   following tokens:
321
322   gzip
323
324      An encoding format produced by the file compression program "gzip"
325      (GNU zip) as described in RFC 1952 [RFC1952].  This format is a
326      Lempel-Ziv coding (LZ77) with a 32 bit CRC.
327
328   compress
329
330      The encoding format produced by the common UNIX file compression
331      program "compress".  This format is an adaptive Lempel-Ziv-Welch
332
333
334
335Fielding, et al.          Expires June 22, 2008                 [Page 6]
336
337Internet-Draft                  HTTP/1.1                   December 2007
338
339
340      coding (LZW).
341
342      Use of program names for the identification of encoding formats is
343      not desirable and is discouraged for future encodings.  Their use
344      here is representative of historical practice, not good design.
345      For compatibility with previous implementations of HTTP,
346      applications SHOULD consider "x-gzip" and "x-compress" to be
347      equivalent to "gzip" and "compress" respectively.
348
349   deflate
350
351      The "zlib" format defined in RFC 1950 [RFC1950] in combination
352      with the "deflate" compression mechanism described in RFC 1951
353      [RFC1951].
354
355   identity
356
357      The default (identity) encoding; the use of no transformation
358      whatsoever.  This content-coding is used only in the Accept-
359      Encoding header, and SHOULD NOT be used in the Content-Encoding
360      header.
361
362   New content-coding value tokens SHOULD be registered; to allow
363   interoperability between clients and servers, specifications of the
364   content coding algorithms needed to implement a new value SHOULD be
365   publicly available and adequate for independent implementation, and
366   conform to the purpose of content coding defined in this section.
367
3682.3.  Media Types
369
370   HTTP uses Internet Media Types [RFC1590] in the Content-Type
371   (Section 5.9) and Accept (Section 5.1) header fields in order to
372   provide open and extensible data typing and type negotiation.
373
374       media-type     = type "/" subtype *( ";" parameter )
375       type           = token
376       subtype        = token
377
378   Parameters MAY follow the type/subtype in the form of attribute/value
379   pairs.
380
381       parameter               = attribute "=" value
382       attribute               = token
383       value                   = token | quoted-string
384
385   The type, subtype, and parameter attribute names are case-
386   insensitive.  Parameter values might or might not be case-sensitive,
387   depending on the semantics of the parameter name.  Linear white space
388
389
390
391Fielding, et al.          Expires June 22, 2008                 [Page 7]
392
393Internet-Draft                  HTTP/1.1                   December 2007
394
395
396   (LWS) MUST NOT be used between the type and subtype, nor between an
397   attribute and its value.  The presence or absence of a parameter
398   might be significant to the processing of a media-type, depending on
399   its definition within the media type registry.
400
401   Note that some older HTTP applications do not recognize media type
402   parameters.  When sending data to older HTTP applications,
403   implementations SHOULD only use media type parameters when they are
404   required by that type/subtype definition.
405
406   Media-type values are registered with the Internet Assigned Number
407   Authority (IANA [RFC1700]).  The media type registration process is
408   outlined in RFC 1590 [RFC1590].  Use of non-registered media types is
409   discouraged.
410
4112.3.1.  Canonicalization and Text Defaults
412
413   Internet media types are registered with a canonical form.  An
414   entity-body transferred via HTTP messages MUST be represented in the
415   appropriate canonical form prior to its transmission except for
416   "text" types, as defined in the next paragraph.
417
418   When in canonical form, media subtypes of the "text" type use CRLF as
419   the text line break.  HTTP relaxes this requirement and allows the
420   transport of text media with plain CR or LF alone representing a line
421   break when it is done consistently for an entire entity-body.  HTTP
422   applications MUST accept CRLF, bare CR, and bare LF as being
423   representative of a line break in text media received via HTTP.  In
424   addition, if the text is represented in a character set that does not
425   use octets 13 and 10 for CR and LF respectively, as is the case for
426   some multi-byte character sets, HTTP allows the use of whatever octet
427   sequences are defined by that character set to represent the
428   equivalent of CR and LF for line breaks.  This flexibility regarding
429   line breaks applies only to text media in the entity-body; a bare CR
430   or LF MUST NOT be substituted for CRLF within any of the HTTP control
431   structures (such as header fields and multipart boundaries).
432
433   If an entity-body is encoded with a content-coding, the underlying
434   data MUST be in a form defined above prior to being encoded.
435
436   The "charset" parameter is used with some media types to define the
437   character set (Section 2.1) of the data.  When no explicit charset
438   parameter is provided by the sender, media subtypes of the "text"
439   type are defined to have a default charset value of "ISO-8859-1" when
440   received via HTTP.  Data in character sets other than "ISO-8859-1" or
441   its subsets MUST be labeled with an appropriate charset value.  See
442   Section 2.1.1 for compatibility problems.
443
444
445
446
447Fielding, et al.          Expires June 22, 2008                 [Page 8]
448
449Internet-Draft                  HTTP/1.1                   December 2007
450
451
4522.3.2.  Multipart Types
453
454   MIME provides for a number of "multipart" types -- encapsulations of
455   one or more entities within a single message-body.  All multipart
456   types share a common syntax, as defined in section 5.1.1 of RFC 2046
457   [RFC2046], and MUST include a boundary parameter as part of the media
458   type value.  The message body is itself a protocol element and MUST
459   therefore use only CRLF to represent line breaks between body-parts.
460   Unlike in RFC 2046, the epilogue of any multipart message MUST be
461   empty; HTTP applications MUST NOT transmit the epilogue (even if the
462   original multipart contains an epilogue).  These restrictions exist
463   in order to preserve the self-delimiting nature of a multipart
464   message-body, wherein the "end" of the message-body is indicated by
465   the ending multipart boundary.
466
467   In general, HTTP treats a multipart message-body no differently than
468   any other media type: strictly as payload.  The one exception is the
469   "multipart/byteranges" type (Appendix A of [Part5]) when it appears
470   in a 206 (Partial Content) response.  In all other cases, an HTTP
471   user agent SHOULD follow the same or similar behavior as a MIME user
472   agent would upon receipt of a multipart type.  The MIME header fields
473   within each body-part of a multipart message-body do not have any
474   significance to HTTP beyond that defined by their MIME semantics.
475
476   In general, an HTTP user agent SHOULD follow the same or similar
477   behavior as a MIME user agent would upon receipt of a multipart type.
478   If an application receives an unrecognized multipart subtype, the
479   application MUST treat it as being equivalent to "multipart/mixed".
480
481      Note: The "multipart/form-data" type has been specifically defined
482      for carrying form data suitable for processing via the POST
483      request method, as described in RFC 1867 [RFC1867].
484
4852.4.  Quality Values
486
487   HTTP content negotiation (Section 4) uses short "floating point"
488   numbers to indicate the relative importance ("weight") of various
489   negotiable parameters.  A weight is normalized to a real number in
490   the range 0 through 1, where 0 is the minimum and 1 the maximum
491   value.  If a parameter has a quality value of 0, then content with
492   this parameter is `not acceptable' for the client.  HTTP/1.1
493   applications MUST NOT generate more than three digits after the
494   decimal point.  User configuration of these values SHOULD also be
495   limited in this fashion.
496
497       qvalue         = ( "0" [ "." 0*3DIGIT ] )
498                      | ( "1" [ "." 0*3("0") ] )
499
500
501
502
503Fielding, et al.          Expires June 22, 2008                 [Page 9]
504
505Internet-Draft                  HTTP/1.1                   December 2007
506
507
508   "Quality values" is a misnomer, since these values merely represent
509   relative degradation in desired quality.
510
5112.5.  Language Tags
512
513   A language tag identifies a natural language spoken, written, or
514   otherwise conveyed by human beings for communication of information
515   to other human beings.  Computer languages are explicitly excluded.
516   HTTP uses language tags within the Accept-Language and Content-
517   Language fields.
518
519   The syntax and registry of HTTP language tags is the same as that
520   defined by RFC 1766 [RFC1766].  In summary, a language tag is
521   composed of 1 or more parts: A primary language tag and a possibly
522   empty series of subtags:
523
524        language-tag  = primary-tag *( "-" subtag )
525        primary-tag   = 1*8ALPHA
526        subtag        = 1*8ALPHA
527
528   White space is not allowed within the tag and all tags are case-
529   insensitive.  The name space of language tags is administered by the
530   IANA.  Example tags include:
531
532       en, en-US, en-cockney, i-cherokee, x-pig-latin
533
534   where any two-letter primary-tag is an ISO-639 language abbreviation
535   and any two-letter initial subtag is an ISO-3166 country code.  (The
536   last three tags above are not registered tags; all but the last are
537   examples of tags which could be registered in future.)
538
539
5403.  Entity
541
542   Request and Response messages MAY transfer an entity if not otherwise
543   restricted by the request method or response status code.  An entity
544   consists of entity-header fields and an entity-body, although some
545   responses will only include the entity-headers.
546
547   In this section, both sender and recipient refer to either the client
548   or the server, depending on who sends and who receives the entity.
549
5503.1.  Entity Header Fields
551
552   Entity-header fields define metainformation about the entity-body or,
553   if no body is present, about the resource identified by the request.
554   Some of this metainformation is OPTIONAL; some might be REQUIRED by
555   portions of this specification.
556
557
558
559Fielding, et al.          Expires June 22, 2008                [Page 10]
560
561Internet-Draft                  HTTP/1.1                   December 2007
562
563
564       entity-header  = Allow                    ; [Part2], Section 10.1
565                      | Content-Encoding         ; Section 5.5
566                      | Content-Language         ; Section 5.6
567                      | Content-Length           ; [Part1], Section 8.2
568                      | Content-Location         ; Section 5.7
569                      | Content-MD5              ; Section 5.8
570                      | Content-Range            ; [Part5], Section 5.2
571                      | Content-Type             ; Section 5.9
572                      | Expires                  ; [Part6], Section 3.3
573                      | Last-Modified            ; [Part4], Section 6.6
574                      | extension-header
575
576       extension-header = message-header
577
578   The extension-header mechanism allows additional entity-header fields
579   to be defined without changing the protocol, but these fields cannot
580   be assumed to be recognizable by the recipient.  Unrecognized header
581   fields SHOULD be ignored by the recipient and MUST be forwarded by
582   transparent proxies.
583
5843.2.  Entity Body
585
586   The entity-body (if any) sent with an HTTP request or response is in
587   a format and encoding defined by the entity-header fields.
588
589       entity-body    = *OCTET
590
591   An entity-body is only present in a message when a message-body is
592   present, as described in Section 4.3 of [Part1].  The entity-body is
593   obtained from the message-body by decoding any Transfer-Encoding that
594   might have been applied to ensure safe and proper transfer of the
595   message.
596
5973.2.1.  Type
598
599   When an entity-body is included with a message, the data type of that
600   body is determined via the header fields Content-Type and Content-
601   Encoding.  These define a two-layer, ordered encoding model:
602
603       entity-body := Content-Encoding( Content-Type( data ) )
604
605   Content-Type specifies the media type of the underlying data.
606   Content-Encoding may be used to indicate any additional content
607   codings applied to the data, usually for the purpose of data
608   compression, that are a property of the requested resource.  There is
609   no default encoding.
610
611   Any HTTP/1.1 message containing an entity-body SHOULD include a
612
613
614
615Fielding, et al.          Expires June 22, 2008                [Page 11]
616
617Internet-Draft                  HTTP/1.1                   December 2007
618
619
620   Content-Type header field defining the media type of that body.  If
621   and only if the media type is not given by a Content-Type field, the
622   recipient MAY attempt to guess the media type via inspection of its
623   content and/or the name extension(s) of the URI used to identify the
624   resource.  If the media type remains unknown, the recipient SHOULD
625   treat it as type "application/octet-stream".
626
6273.2.2.  Entity Length
628
629   The entity-length of a message is the length of the message-body
630   before any transfer-codings have been applied.  Section 4.4 of
631   [Part1] defines how the transfer-length of a message-body is
632   determined.
633
634
6354.  Content Negotiation
636
637   Most HTTP responses include an entity which contains information for
638   interpretation by a human user.  Naturally, it is desirable to supply
639   the user with the "best available" entity corresponding to the
640   request.  Unfortunately for servers and caches, not all users have
641   the same preferences for what is "best," and not all user agents are
642   equally capable of rendering all entity types.  For that reason, HTTP
643   has provisions for several mechanisms for "content negotiation" --
644   the process of selecting the best representation for a given response
645   when there are multiple representations available.
646
647      Note: This is not called "format negotiation" because the
648      alternate representations may be of the same media type, but use
649      different capabilities of that type, be in different languages,
650      etc.
651
652   Any response containing an entity-body MAY be subject to negotiation,
653   including error responses.
654
655   There are two kinds of content negotiation which are possible in
656   HTTP: server-driven and agent-driven negotiation.  These two kinds of
657   negotiation are orthogonal and thus may be used separately or in
658   combination.  One method of combination, referred to as transparent
659   negotiation, occurs when a cache uses the agent-driven negotiation
660   information provided by the origin server in order to provide server-
661   driven negotiation for subsequent requests.
662
6634.1.  Server-driven Negotiation
664
665   If the selection of the best representation for a response is made by
666   an algorithm located at the server, it is called server-driven
667   negotiation.  Selection is based on the available representations of
668
669
670
671Fielding, et al.          Expires June 22, 2008                [Page 12]
672
673Internet-Draft                  HTTP/1.1                   December 2007
674
675
676   the response (the dimensions over which it can vary; e.g. language,
677   content-coding, etc.) and the contents of particular header fields in
678   the request message or on other information pertaining to the request
679   (such as the network address of the client).
680
681   Server-driven negotiation is advantageous when the algorithm for
682   selecting from among the available representations is difficult to
683   describe to the user agent, or when the server desires to send its
684   "best guess" to the client along with the first response (hoping to
685   avoid the round-trip delay of a subsequent request if the "best
686   guess" is good enough for the user).  In order to improve the
687   server's guess, the user agent MAY include request header fields
688   (Accept, Accept-Language, Accept-Encoding, etc.) which describe its
689   preferences for such a response.
690
691   Server-driven negotiation has disadvantages:
692
693   1.  It is impossible for the server to accurately determine what
694       might be "best" for any given user, since that would require
695       complete knowledge of both the capabilities of the user agent and
696       the intended use for the response (e.g., does the user want to
697       view it on screen or print it on paper?).
698
699   2.  Having the user agent describe its capabilities in every request
700       can be both very inefficient (given that only a small percentage
701       of responses have multiple representations) and a potential
702       violation of the user's privacy.
703
704   3.  It complicates the implementation of an origin server and the
705       algorithms for generating responses to a request.
706
707   4.  It may limit a public cache's ability to use the same response
708       for multiple user's requests.
709
710   HTTP/1.1 includes the following request-header fields for enabling
711   server-driven negotiation through description of user agent
712   capabilities and user preferences: Accept (Section 5.1), Accept-
713   Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language
714   (Section 5.4), and User-Agent (Section 10.9 of [Part2]).  However, an
715   origin server is not limited to these dimensions and MAY vary the
716   response based on any aspect of the request, including information
717   outside the request-header fields or within extension header fields
718   not defined by this specification.
719
720   The Vary header field [Part6] can be used to express the parameters
721   the server uses to select a representation that is subject to server-
722   driven negotiation.
723
724
725
726
727Fielding, et al.          Expires June 22, 2008                [Page 13]
728
729Internet-Draft                  HTTP/1.1                   December 2007
730
731
7324.2.  Agent-driven Negotiation
733
734   With agent-driven negotiation, selection of the best representation
735   for a response is performed by the user agent after receiving an
736   initial response from the origin server.  Selection is based on a
737   list of the available representations of the response included within
738   the header fields or entity-body of the initial response, with each
739   representation identified by its own URI.  Selection from among the
740   representations may be performed automatically (if the user agent is
741   capable of doing so) or manually by the user selecting from a
742   generated (possibly hypertext) menu.
743
744   Agent-driven negotiation is advantageous when the response would vary
745   over commonly-used dimensions (such as type, language, or encoding),
746   when the origin server is unable to determine a user agent's
747   capabilities from examining the request, and generally when public
748   caches are used to distribute server load and reduce network usage.
749
750   Agent-driven negotiation suffers from the disadvantage of needing a
751   second request to obtain the best alternate representation.  This
752   second request is only efficient when caching is used.  In addition,
753   this specification does not define any mechanism for supporting
754   automatic selection, though it also does not prevent any such
755   mechanism from being developed as an extension and used within
756   HTTP/1.1.
757
758   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
759   status codes for enabling agent-driven negotiation when the server is
760   unwilling or unable to provide a varying response using server-driven
761   negotiation.
762
7634.3.  Transparent Negotiation
764
765   Transparent negotiation is a combination of both server-driven and
766   agent-driven negotiation.  When a cache is supplied with a form of
767   the list of available representations of the response (as in agent-
768   driven negotiation) and the dimensions of variance are completely
769   understood by the cache, then the cache becomes capable of performing
770   server-driven negotiation on behalf of the origin server for
771   subsequent requests on that resource.
772
773   Transparent negotiation has the advantage of distributing the
774   negotiation work that would otherwise be required of the origin
775   server and also removing the second request delay of agent-driven
776   negotiation when the cache is able to correctly guess the right
777   response.
778
779   This specification does not define any mechanism for transparent
780
781
782
783Fielding, et al.          Expires June 22, 2008                [Page 14]
784
785Internet-Draft                  HTTP/1.1                   December 2007
786
787
788   negotiation, though it also does not prevent any such mechanism from
789   being developed as an extension that could be used within HTTP/1.1.
790
791
7925.  Header Field Definitions
793
794   This section defines the syntax and semantics of all standard
795   HTTP/1.1 header fields.  For entity-header fields, both sender and
796   recipient refer to either the client or the server, depending on who
797   sends and who receives the entity.
798
7995.1.  Accept
800
801   The Accept request-header field can be used to specify certain media
802   types which are acceptable for the response.  Accept headers can be
803   used to indicate that the request is specifically limited to a small
804   set of desired types, as in the case of a request for an in-line
805   image.
806
807       Accept         = "Accept" ":"
808                        #( media-range [ accept-params ] )
809
810       media-range    = ( "*/*"
811                        | ( type "/" "*" )
812                        | ( type "/" subtype )
813                        ) *( ";" parameter )
814       accept-params  = ";" "q" "=" qvalue *( accept-extension )
815       accept-extension = ";" token [ "=" ( token | quoted-string ) ]
816
817   The asterisk "*" character is used to group media types into ranges,
818   with "*/*" indicating all media types and "type/*" indicating all
819   subtypes of that type.  The media-range MAY include media type
820   parameters that are applicable to that range.
821
822   Each media-range MAY be followed by one or more accept-params,
823   beginning with the "q" parameter for indicating a relative quality
824   factor.  The first "q" parameter (if any) separates the media-range
825   parameter(s) from the accept-params.  Quality factors allow the user
826   or user agent to indicate the relative degree of preference for that
827   media-range, using the qvalue scale from 0 to 1 (Section 2.4).  The
828   default value is q=1.
829
830      Note: Use of the "q" parameter name to separate media type
831      parameters from Accept extension parameters is due to historical
832      practice.  Although this prevents any media type parameter named
833      "q" from being used with a media range, such an event is believed
834      to be unlikely given the lack of any "q" parameters in the IANA
835      media type registry and the rare usage of any media type
836
837
838
839Fielding, et al.          Expires June 22, 2008                [Page 15]
840
841Internet-Draft                  HTTP/1.1                   December 2007
842
843
844      parameters in Accept.  Future media types are discouraged from
845      registering any parameter named "q".
846
847   The example
848
849       Accept: audio/*; q=0.2, audio/basic
850
851   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
852   type if it is the best available after an 80% mark-down in quality."
853
854   If no Accept header field is present, then it is assumed that the
855   client accepts all media types.  If an Accept header field is
856   present, and if the server cannot send a response which is acceptable
857   according to the combined Accept field value, then the server SHOULD
858   send a 406 (not acceptable) response.
859
860   A more elaborate example is
861
862       Accept: text/plain; q=0.5, text/html,
863               text/x-dvi; q=0.8, text/x-c
864
865   Verbally, this would be interpreted as "text/html and text/x-c are
866   the preferred media types, but if they do not exist, then send the
867   text/x-dvi entity, and if that does not exist, send the text/plain
868   entity."
869
870   Media ranges can be overridden by more specific media ranges or
871   specific media types.  If more than one media range applies to a
872   given type, the most specific reference has precedence.  For example,
873
874       Accept: text/*, text/html, text/html;level=1, */*
875
876   have the following precedence:
877
878       1) text/html;level=1
879       2) text/html
880       3) text/*
881       4) */*
882
883   The media type quality factor associated with a given type is
884   determined by finding the media range with the highest precedence
885   which matches that type.  For example,
886
887       Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
888               text/html;level=2;q=0.4, */*;q=0.5
889
890   would cause the following values to be associated:
891
892
893
894
895Fielding, et al.          Expires June 22, 2008                [Page 16]
896
897Internet-Draft                  HTTP/1.1                   December 2007
898
899
900       text/html;level=1         = 1
901       text/html                 = 0.7
902       text/plain                = 0.3
903       image/jpeg                = 0.5
904       text/html;level=2         = 0.4
905       text/html;level=3         = 0.7
906
907   Note: A user agent might be provided with a default set of quality
908   values for certain media ranges.  However, unless the user agent is a
909   closed system which cannot interact with other rendering agents, this
910   default set ought to be configurable by the user.
911
9125.2.  Accept-Charset
913
914   The Accept-Charset request-header field can be used to indicate what
915   character sets are acceptable for the response.  This field allows
916   clients capable of understanding more comprehensive or special-
917   purpose character sets to signal that capability to a server which is
918   capable of representing documents in those character sets.
919
920      Accept-Charset = "Accept-Charset" ":"
921              1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
922
923   Character set values are described in Section 2.1.  Each charset MAY
924   be given an associated quality value which represents the user's
925   preference for that charset.  The default value is q=1.  An example
926   is
927
928      Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
929
930   The special value "*", if present in the Accept-Charset field,
931   matches every character set (including ISO-8859-1) which is not
932   mentioned elsewhere in the Accept-Charset field.  If no "*" is
933   present in an Accept-Charset field, then all character sets not
934   explicitly mentioned get a quality value of 0, except for ISO-8859-1,
935   which gets a quality value of 1 if not explicitly mentioned.
936
937   If no Accept-Charset header is present, the default is that any
938   character set is acceptable.  If an Accept-Charset header is present,
939   and if the server cannot send a response which is acceptable
940   according to the Accept-Charset header, then the server SHOULD send
941   an error response with the 406 (not acceptable) status code, though
942   the sending of an unacceptable response is also allowed.
943
9445.3.  Accept-Encoding
945
946   The Accept-Encoding request-header field is similar to Accept, but
947   restricts the content-codings (Section 2.2) that are acceptable in
948
949
950
951Fielding, et al.          Expires June 22, 2008                [Page 17]
952
953Internet-Draft                  HTTP/1.1                   December 2007
954
955
956   the response.
957
958       Accept-Encoding  = "Accept-Encoding" ":"
959                          1#( codings [ ";" "q" "=" qvalue ] )
960       codings          = ( content-coding | "*" )
961
962   Examples of its use are:
963
964       Accept-Encoding: compress, gzip
965       Accept-Encoding:
966       Accept-Encoding: *
967       Accept-Encoding: compress;q=0.5, gzip;q=1.0
968       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
969
970   A server tests whether a content-coding is acceptable, according to
971   an Accept-Encoding field, using these rules:
972
973   1.  If the content-coding is one of the content-codings listed in the
974       Accept-Encoding field, then it is acceptable, unless it is
975       accompanied by a qvalue of 0.  (As defined in Section 2.4, a
976       qvalue of 0 means "not acceptable.")
977
978   2.  The special "*" symbol in an Accept-Encoding field matches any
979       available content-coding not explicitly listed in the header
980       field.
981
982   3.  If multiple content-codings are acceptable, then the acceptable
983       content-coding with the highest non-zero qvalue is preferred.
984
985   4.  The "identity" content-coding is always acceptable, unless
986       specifically refused because the Accept-Encoding field includes
987       "identity;q=0", or because the field includes "*;q=0" and does
988       not explicitly include the "identity" content-coding.  If the
989       Accept-Encoding field-value is empty, then only the "identity"
990       encoding is acceptable.
991
992   If an Accept-Encoding field is present in a request, and if the
993   server cannot send a response which is acceptable according to the
994   Accept-Encoding header, then the server SHOULD send an error response
995   with the 406 (Not Acceptable) status code.
996
997   If no Accept-Encoding field is present in a request, the server MAY
998   assume that the client will accept any content coding.  In this case,
999   if "identity" is one of the available content-codings, then the
1000   server SHOULD use the "identity" content-coding, unless it has
1001   additional information that a different content-coding is meaningful
1002   to the client.
1003
1004
1005
1006
1007Fielding, et al.          Expires June 22, 2008                [Page 18]
1008
1009Internet-Draft                  HTTP/1.1                   December 2007
1010
1011
1012      Note: If the request does not include an Accept-Encoding field,
1013      and if the "identity" content-coding is unavailable, then content-
1014      codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and
1015      "compress") are preferred; some older clients improperly display
1016      messages sent with other content-codings.  The server might also
1017      make this decision based on information about the particular user-
1018      agent or client.
1019
1020      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
1021      associated with content-codings.  This means that qvalues will not
1022      work and are not permitted with x-gzip or x-compress.
1023
10245.4.  Accept-Language
1025
1026   The Accept-Language request-header field is similar to Accept, but
1027   restricts the set of natural languages that are preferred as a
1028   response to the request.  Language tags are defined in Section 2.5.
1029
1030       Accept-Language = "Accept-Language" ":"
1031                         1#( language-range [ ";" "q" "=" qvalue ] )
1032       language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
1033
1034   Each language-range MAY be given an associated quality value which
1035   represents an estimate of the user's preference for the languages
1036   specified by that range.  The quality value defaults to "q=1".  For
1037   example,
1038
1039       Accept-Language: da, en-gb;q=0.8, en;q=0.7
1040
1041   would mean: "I prefer Danish, but will accept British English and
1042   other types of English."  A language-range matches a language-tag if
1043   it exactly equals the tag, or if it exactly equals a prefix of the
1044   tag such that the first tag character following the prefix is "-".
1045   The special range "*", if present in the Accept-Language field,
1046   matches every tag not matched by any other range present in the
1047   Accept-Language field.
1048
1049      Note: This use of a prefix matching rule does not imply that
1050      language tags are assigned to languages in such a way that it is
1051      always true that if a user understands a language with a certain
1052      tag, then this user will also understand all languages with tags
1053      for which this tag is a prefix.  The prefix rule simply allows the
1054      use of prefix tags if this is the case.
1055
1056   The language quality factor assigned to a language-tag by the Accept-
1057   Language field is the quality value of the longest language-range in
1058   the field that matches the language-tag.  If no language-range in the
1059   field matches the tag, the language quality factor assigned is 0.  If
1060
1061
1062
1063Fielding, et al.          Expires June 22, 2008                [Page 19]
1064
1065Internet-Draft                  HTTP/1.1                   December 2007
1066
1067
1068   no Accept-Language header is present in the request, the server
1069   SHOULD assume that all languages are equally acceptable.  If an
1070   Accept-Language header is present, then all languages which are
1071   assigned a quality factor greater than 0 are acceptable.
1072
1073   It might be contrary to the privacy expectations of the user to send
1074   an Accept-Language header with the complete linguistic preferences of
1075   the user in every request.  For a discussion of this issue, see
1076   Section 7.1.
1077
1078   As intelligibility is highly dependent on the individual user, it is
1079   recommended that client applications make the choice of linguistic
1080   preference available to the user.  If the choice is not made
1081   available, then the Accept-Language header field MUST NOT be given in
1082   the request.
1083
1084      Note: When making the choice of linguistic preference available to
1085      the user, we remind implementors of the fact that users are not
1086      familiar with the details of language matching as described above,
1087      and should provide appropriate guidance.  As an example, users
1088      might assume that on selecting "en-gb", they will be served any
1089      kind of English document if British English is not available.  A
1090      user agent might suggest in such a case to add "en" to get the
1091      best matching behavior.
1092
10935.5.  Content-Encoding
1094
1095   The Content-Encoding entity-header field is used as a modifier to the
1096   media-type.  When present, its value indicates what additional
1097   content codings have been applied to the entity-body, and thus what
1098   decoding mechanisms must be applied in order to obtain the media-type
1099   referenced by the Content-Type header field.  Content-Encoding is
1100   primarily used to allow a document to be compressed without losing
1101   the identity of its underlying media type.
1102
1103       Content-Encoding  = "Content-Encoding" ":" 1#content-coding
1104
1105   Content codings are defined in Section 2.2.  An example of its use is
1106
1107       Content-Encoding: gzip
1108
1109   The content-coding is a characteristic of the entity identified by
1110   the Request-URI.  Typically, the entity-body is stored with this
1111   encoding and is only decoded before rendering or analogous usage.
1112   However, a non-transparent proxy MAY modify the content-coding if the
1113   new coding is known to be acceptable to the recipient, unless the
1114   "no-transform" cache-control directive is present in the message.
1115
1116
1117
1118
1119Fielding, et al.          Expires June 22, 2008                [Page 20]
1120
1121Internet-Draft                  HTTP/1.1                   December 2007
1122
1123
1124   If the content-coding of an entity is not "identity", then the
1125   response MUST include a Content-Encoding entity-header (Section 5.5)
1126   that lists the non-identity content-coding(s) used.
1127
1128   If the content-coding of an entity in a request message is not
1129   acceptable to the origin server, the server SHOULD respond with a
1130   status code of 415 (Unsupported Media Type).
1131
1132   If multiple encodings have been applied to an entity, the content
1133   codings MUST be listed in the order in which they were applied.
1134   Additional information about the encoding parameters MAY be provided
1135   by other entity-header fields not defined by this specification.
1136
11375.6.  Content-Language
1138
1139   The Content-Language entity-header field describes the natural
1140   language(s) of the intended audience for the enclosed entity.  Note
1141   that this might not be equivalent to all the languages used within
1142   the entity-body.
1143
1144       Content-Language  = "Content-Language" ":" 1#language-tag
1145
1146   Language tags are defined in Section 2.5.  The primary purpose of
1147   Content-Language is to allow a user to identify and differentiate
1148   entities according to the user's own preferred language.  Thus, if
1149   the body content is intended only for a Danish-literate audience, the
1150   appropriate field is
1151
1152       Content-Language: da
1153
1154   If no Content-Language is specified, the default is that the content
1155   is intended for all language audiences.  This might mean that the
1156   sender does not consider it to be specific to any natural language,
1157   or that the sender does not know for which language it is intended.
1158
1159   Multiple languages MAY be listed for content that is intended for
1160   multiple audiences.  For example, a rendition of the "Treaty of
1161   Waitangi," presented simultaneously in the original Maori and English
1162   versions, would call for
1163
1164       Content-Language: mi, en
1165
1166   However, just because multiple languages are present within an entity
1167   does not mean that it is intended for multiple linguistic audiences.
1168   An example would be a beginner's language primer, such as "A First
1169   Lesson in Latin," which is clearly intended to be used by an English-
1170   literate audience.  In this case, the Content-Language would properly
1171   only include "en".
1172
1173
1174
1175Fielding, et al.          Expires June 22, 2008                [Page 21]
1176
1177Internet-Draft                  HTTP/1.1                   December 2007
1178
1179
1180   Content-Language MAY be applied to any media type -- it is not
1181   limited to textual documents.
1182
11835.7.  Content-Location
1184
1185   The Content-Location entity-header field MAY be used to supply the
1186   resource location for the entity enclosed in the message when that
1187   entity is accessible from a location separate from the requested
1188   resource's URI.  A server SHOULD provide a Content-Location for the
1189   variant corresponding to the response entity; especially in the case
1190   where a resource has multiple entities associated with it, and those
1191   entities actually have separate locations by which they might be
1192   individually accessed, the server SHOULD provide a Content-Location
1193   for the particular variant which is returned.
1194
1195       Content-Location = "Content-Location" ":"
1196                         ( absoluteURI | relativeURI )
1197
1198   The value of Content-Location also defines the base URI for the
1199   entity.
1200
1201   The Content-Location value is not a replacement for the original
1202   requested URI; it is only a statement of the location of the resource
1203   corresponding to this particular entity at the time of the request.
1204   Future requests MAY specify the Content-Location URI as the request-
1205   URI if the desire is to identify the source of that particular
1206   entity.
1207
1208   A cache cannot assume that an entity with a Content-Location
1209   different from the URI used to retrieve it can be used to respond to
1210   later requests on that Content-Location URI.  However, the Content-
1211   Location can be used to differentiate between multiple entities
1212   retrieved from a single requested resource, as described in [Part6].
1213
1214   If the Content-Location is a relative URI, the relative URI is
1215   interpreted relative to the Request-URI.
1216
1217   The meaning of the Content-Location header in PUT or POST requests is
1218   undefined; servers are free to ignore it in those cases.
1219
12205.8.  Content-MD5
1221
1222   The Content-MD5 entity-header field, as defined in RFC 1864
1223   [RFC1864], is an MD5 digest of the entity-body for the purpose of
1224   providing an end-to-end message integrity check (MIC) of the entity-
1225   body.  (Note: a MIC is good for detecting accidental modification of
1226   the entity-body in transit, but is not proof against malicious
1227   attacks.)
1228
1229
1230
1231Fielding, et al.          Expires June 22, 2008                [Page 22]
1232
1233Internet-Draft                  HTTP/1.1                   December 2007
1234
1235
1236        Content-MD5   = "Content-MD5" ":" md5-digest
1237        md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>
1238
1239   The Content-MD5 header field MAY be generated by an origin server or
1240   client to function as an integrity check of the entity-body.  Only
1241   origin servers or clients MAY generate the Content-MD5 header field;
1242   proxies and gateways MUST NOT generate it, as this would defeat its
1243   value as an end-to-end integrity check.  Any recipient of the entity-
1244   body, including gateways and proxies, MAY check that the digest value
1245   in this header field matches that of the entity-body as received.
1246
1247   The MD5 digest is computed based on the content of the entity-body,
1248   including any content-coding that has been applied, but not including
1249   any transfer-encoding applied to the message-body.  If the message is
1250   received with a transfer-encoding, that encoding MUST be removed
1251   prior to checking the Content-MD5 value against the received entity.
1252
1253   This has the result that the digest is computed on the octets of the
1254   entity-body exactly as, and in the order that, they would be sent if
1255   no transfer-encoding were being applied.
1256
1257   HTTP extends RFC 1864 to permit the digest to be computed for MIME
1258   composite media-types (e.g., multipart/* and message/rfc822), but
1259   this does not change how the digest is computed as defined in the
1260   preceding paragraph.
1261
1262   There are several consequences of this.  The entity-body for
1263   composite types MAY contain many body-parts, each with its own MIME
1264   and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
1265   and Content-Encoding headers).  If a body-part has a Content-
1266   Transfer-Encoding or Content-Encoding header, it is assumed that the
1267   content of the body-part has had the encoding applied, and the body-
1268   part is included in the Content-MD5 digest as is -- i.e., after the
1269   application.  The Transfer-Encoding header field is not allowed
1270   within body-parts.
1271
1272   Conversion of all line breaks to CRLF MUST NOT be done before
1273   computing or checking the digest: the line break convention used in
1274   the text actually transmitted MUST be left unaltered when computing
1275   the digest.
1276
1277      Note: while the definition of Content-MD5 is exactly the same for
1278      HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
1279      in which the application of Content-MD5 to HTTP entity-bodies
1280      differs from its application to MIME entity-bodies.  One is that
1281      HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
1282      does use Transfer-Encoding and Content-Encoding.  Another is that
1283      HTTP more frequently uses binary content types than MIME, so it is
1284
1285
1286
1287Fielding, et al.          Expires June 22, 2008                [Page 23]
1288
1289Internet-Draft                  HTTP/1.1                   December 2007
1290
1291
1292      worth noting that, in such cases, the byte order used to compute
1293      the digest is the transmission byte order defined for the type.
1294      Lastly, HTTP allows transmission of text types with any of several
1295      line break conventions and not just the canonical form using CRLF.
1296
12975.9.  Content-Type
1298
1299   The Content-Type entity-header field indicates the media type of the
1300   entity-body sent to the recipient or, in the case of the HEAD method,
1301   the media type that would have been sent had the request been a GET.
1302
1303       Content-Type   = "Content-Type" ":" media-type
1304
1305   Media types are defined in Section 2.3.  An example of the field is
1306
1307       Content-Type: text/html; charset=ISO-8859-4
1308
1309   Further discussion of methods for identifying the media type of an
1310   entity is provided in Section 3.2.1.
1311
1312
13136.  IANA Considerations
1314
1315   TBD.
1316
1317
13187.  Security Considerations
1319
1320   This section is meant to inform application developers, information
1321   providers, and users of the security limitations in HTTP/1.1 as
1322   described by this document.  The discussion does not include
1323   definitive solutions to the problems revealed, though it does make
1324   some suggestions for reducing security risks.
1325
13267.1.  Privacy Issues Connected to Accept Headers
1327
1328   Accept request-headers can reveal information about the user to all
1329   servers which are accessed.  The Accept-Language header in particular
1330   can reveal information the user would consider to be of a private
1331   nature, because the understanding of particular languages is often
1332   strongly correlated to the membership of a particular ethnic group.
1333   User agents which offer the option to configure the contents of an
1334   Accept-Language header to be sent in every request are strongly
1335   encouraged to let the configuration process include a message which
1336   makes the user aware of the loss of privacy involved.
1337
1338   An approach that limits the loss of privacy would be for a user agent
1339   to omit the sending of Accept-Language headers by default, and to ask
1340
1341
1342
1343Fielding, et al.          Expires June 22, 2008                [Page 24]
1344
1345Internet-Draft                  HTTP/1.1                   December 2007
1346
1347
1348   the user whether or not to start sending Accept-Language headers to a
1349   server if it detects, by looking for any Vary response-header fields
1350   generated by the server, that such sending could improve the quality
1351   of service.
1352
1353   Elaborate user-customized accept header fields sent in every request,
1354   in particular if these include quality values, can be used by servers
1355   as relatively reliable and long-lived user identifiers.  Such user
1356   identifiers would allow content providers to do click-trail tracking,
1357   and would allow collaborating content providers to match cross-server
1358   click-trails or form submissions of individual users.  Note that for
1359   many users not behind a proxy, the network address of the host
1360   running the user agent will also serve as a long-lived user
1361   identifier.  In environments where proxies are used to enhance
1362   privacy, user agents ought to be conservative in offering accept
1363   header configuration options to end users.  As an extreme privacy
1364   measure, proxies could filter the accept headers in relayed requests.
1365   General purpose user agents which provide a high degree of header
1366   configurability SHOULD warn users about the loss of privacy which can
1367   be involved.
1368
13697.2.  Content-Disposition Issues
1370
1371   RFC 1806 [RFC1806], from which the often implemented Content-
1372   Disposition (see Appendix B.1) header in HTTP is derived, has a
1373   number of very serious security considerations.  Content-Disposition
1374   is not part of the HTTP standard, but since it is widely implemented,
1375   we are documenting its use and risks for implementors.  See RFC 2183
1376   [RFC2183] (which updates RFC 1806) for details.
1377
1378
13798.  Acknowledgments
1380
1381   Based on an XML translation of RFC 2616 by Julian Reschke.
1382
1383
13849.  References
1385
1386   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1387              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1388              part 1: URIs, Connections, and Message Parsing",
1389              draft-ietf-httpbis-p1-messaging-00 (work in progress),
1390              December 2007.
1391
1392   [Part2]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1393              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1394              part 2: Message Semantics",
1395              draft-ietf-httpbis-p2-semantics-00 (work in progress),
1396
1397
1398
1399Fielding, et al.          Expires June 22, 2008                [Page 25]
1400
1401Internet-Draft                  HTTP/1.1                   December 2007
1402
1403
1404              December 2007.
1405
1406   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1407              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1408              part 4: Conditional Requests",
1409              draft-ietf-httpbis-p4-conditional-00 (work in progress),
1410              December 2007.
1411
1412   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1413              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1414              part 5: Range Requests and Partial Responses",
1415              draft-ietf-httpbis-p5-range-00 (work in progress),
1416              December 2007.
1417
1418   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1419              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1420              part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in
1421              progress), December 2007.
1422
1423   [RFC1590]  Postel, J., "Media Type Registration Procedure", RFC 1590,
1424              November 1996.
1425
1426   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
1427              RFC 1700, October 1994.
1428
1429   [RFC1766]  Alvestrand, H., "Tags for the Identification of
1430              Languages", RFC 1766, March 1995.
1431
1432   [RFC1806]  Troost, R. and S. Dorner, "Communicating Presentation
1433              Information in Internet Messages: The Content-Disposition
1434              Header", RFC 1806, June 1995.
1435
1436   [RFC1864]  Myers, J. and M. Rose, "The Content-MD5 Header Field",
1437              RFC 1864, October 1995.
1438
1439   [RFC1867]  Masinter, L. and E. Nebel, "Form-based File Upload in
1440              HTML", RFC 1867, November 1995.
1441
1442   [RFC1950]  Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
1443              Specification version 3.3", RFC 1950, May 1996.
1444
1445   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
1446              version 1.3", RFC 1951, May 1996.
1447
1448   [RFC1952]  Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
1449              Randers-Pehrson, "GZIP file format specification version
1450              4.3", RFC 1952, May 1996.
1451
1452
1453
1454
1455Fielding, et al.          Expires June 22, 2008                [Page 26]
1456
1457Internet-Draft                  HTTP/1.1                   December 2007
1458
1459
1460   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1461              Extensions (MIME) Part One: Format of Internet Message
1462              Bodies", RFC 2045, November 1996.
1463
1464   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1465              Extensions (MIME) Part Two: Media Types", RFC 2046,
1466              November 1996.
1467
1468   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1469              Extensions (MIME) Part Five: Conformance Criteria and
1470              Examples", RFC 2049, November 1996.
1471
1472   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
1473              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
1474              RFC 2068, January 1997.
1475
1476   [RFC2076]  Palme, J., "Common Internet Message Headers", RFC 2076,
1477              February 1997.
1478
1479   [RFC2110]  Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
1480              Aggregate Documents, such as HTML (MHTML)", RFC 2110,
1481              March 1997.
1482
1483   [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
1484              Presentation Information in Internet Messages: The
1485              Content-Disposition Header Field", RFC 2183, August 1997.
1486
1487   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
1488              Languages", BCP 18, RFC 2277, January 1998.
1489
1490   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
1491              10646", RFC 2279, January 1998.
1492
1493   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1494              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1495              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1496
1497   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
1498              text messages", STD 11, RFC 822, August 1982.
1499
1500
1501Appendix A.  Differences Between HTTP Entities and RFC 2045 Entities
1502
1503   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
1504   822 [RFC822]) and the Multipurpose Internet Mail Extensions (MIME
1505   [RFC2045]) to allow entities to be transmitted in an open variety of
1506   representations and with extensible mechanisms.  However, RFC 2045
1507   discusses mail, and HTTP has a few features that are different from
1508
1509
1510
1511Fielding, et al.          Expires June 22, 2008                [Page 27]
1512
1513Internet-Draft                  HTTP/1.1                   December 2007
1514
1515
1516   those described in RFC 2045.  These differences were carefully chosen
1517   to optimize performance over binary connections, to allow greater
1518   freedom in the use of new media types, to make date comparisons
1519   easier, and to acknowledge the practice of some early HTTP servers
1520   and clients.
1521
1522   This appendix describes specific areas where HTTP differs from RFC
1523   2045.  Proxies and gateways to strict MIME environments SHOULD be
1524   aware of these differences and provide the appropriate conversions
1525   where necessary.  Proxies and gateways from MIME environments to HTTP
1526   also need to be aware of the differences because some conversions
1527   might be required.
1528
1529A.1.  MIME-Version
1530
1531   HTTP is not a MIME-compliant protocol.  However, HTTP/1.1 messages
1532   MAY include a single MIME-Version general-header field to indicate
1533   what version of the MIME protocol was used to construct the message.
1534   Use of the MIME-Version header field indicates that the message is in
1535   full compliance with the MIME protocol (as defined in RFC
1536   2045[RFC2045]).  Proxies/gateways are responsible for ensuring full
1537   compliance (where possible) when exporting HTTP messages to strict
1538   MIME environments.
1539
1540       MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
1541
1542   MIME version "1.0" is the default for use in HTTP/1.1.  However,
1543   HTTP/1.1 message parsing and semantics are defined by this document
1544   and not the MIME specification.
1545
1546A.2.  Conversion to Canonical Form
1547
1548   RFC 2045 [RFC2045] requires that an Internet mail entity be converted
1549   to canonical form prior to being transferred, as described in section
1550   4 of RFC 2049 [RFC2049].  Section 2.3.1 of this document describes
1551   the forms allowed for subtypes of the "text" media type when
1552   transmitted over HTTP.  RFC 2046 requires that content with a type of
1553   "text" represent line breaks as CRLF and forbids the use of CR or LF
1554   outside of line break sequences.  HTTP allows CRLF, bare CR, and bare
1555   LF to indicate a line break within text content when a message is
1556   transmitted over HTTP.
1557
1558   Where it is possible, a proxy or gateway from HTTP to a strict MIME
1559   environment SHOULD translate all line breaks within the text media
1560   types described in Section 2.3.1 of this document to the RFC 2049
1561   canonical form of CRLF.  Note, however, that this might be
1562   complicated by the presence of a Content-Encoding and by the fact
1563   that HTTP allows the use of some character sets which do not use
1564
1565
1566
1567Fielding, et al.          Expires June 22, 2008                [Page 28]
1568
1569Internet-Draft                  HTTP/1.1                   December 2007
1570
1571
1572   octets 13 and 10 to represent CR and LF, as is the case for some
1573   multi-byte character sets.
1574
1575   Implementors should note that conversion will break any cryptographic
1576   checksums applied to the original content unless the original content
1577   is already in canonical form.  Therefore, the canonical form is
1578   recommended for any content that uses such checksums in HTTP.
1579
1580A.3.  Introduction of Content-Encoding
1581
1582   RFC 2045 does not include any concept equivalent to HTTP/1.1's
1583   Content-Encoding header field.  Since this acts as a modifier on the
1584   media type, proxies and gateways from HTTP to MIME-compliant
1585   protocols MUST either change the value of the Content-Type header
1586   field or decode the entity-body before forwarding the message.  (Some
1587   experimental applications of Content-Type for Internet mail have used
1588   a media-type parameter of ";conversions=<content-coding>" to perform
1589   a function equivalent to Content-Encoding.  However, this parameter
1590   is not part of RFC 2045).
1591
1592A.4.  No Content-Transfer-Encoding
1593
1594   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
1595   2045.  Proxies and gateways from MIME-compliant protocols to HTTP
1596   MUST remove any non-identity CTE ("quoted-printable" or "base64")
1597   encoding prior to delivering the response message to an HTTP client.
1598
1599   Proxies and gateways from HTTP to MIME-compliant protocols are
1600   responsible for ensuring that the message is in the correct format
1601   and encoding for safe transport on that protocol, where "safe
1602   transport" is defined by the limitations of the protocol being used.
1603   Such a proxy or gateway SHOULD label the data with an appropriate
1604   Content-Transfer-Encoding if doing so will improve the likelihood of
1605   safe transport over the destination protocol.
1606
1607A.5.  Introduction of Transfer-Encoding
1608
1609   HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7
1610   of [Part1]).  Proxies/gateways MUST remove any transfer-coding prior
1611   to forwarding a message via a MIME-compliant protocol.
1612
1613A.6.  MHTML and Line Length Limitations
1614
1615   HTTP implementations which share code with MHTML [RFC2110]
1616   implementations need to be aware of MIME line length limitations.
1617   Since HTTP does not have this limitation, HTTP does not fold long
1618   lines.  MHTML messages being transported by HTTP follow all
1619   conventions of MHTML, including line length limitations and folding,
1620
1621
1622
1623Fielding, et al.          Expires June 22, 2008                [Page 29]
1624
1625Internet-Draft                  HTTP/1.1                   December 2007
1626
1627
1628   canonicalization, etc., since HTTP transports all message-bodies as
1629   payload (see Section 2.3.2) and does not interpret the content or any
1630   MIME header lines that might be contained therein.
1631
1632
1633Appendix B.  Additional Features
1634
1635   RFC 1945 and RFC 2068 document protocol elements used by some
1636   existing HTTP implementations, but not consistently and correctly
1637   across most HTTP/1.1 applications.  Implementors are advised to be
1638   aware of these features, but cannot rely upon their presence in, or
1639   interoperability with, other HTTP/1.1 applications.  Some of these
1640   describe proposed experimental features, and some describe features
1641   that experimental deployment found lacking that are now addressed in
1642   the base HTTP/1.1 specification.
1643
1644   A number of other headers, such as Content-Disposition and Title,
1645   from SMTP and MIME are also often implemented (see RFC 2076
1646   [RFC2076]).
1647
1648B.1.  Content-Disposition
1649
1650   The Content-Disposition response-header field has been proposed as a
1651   means for the origin server to suggest a default filename if the user
1652   requests that the content is saved to a file.  This usage is derived
1653   from the definition of Content-Disposition in RFC 1806 [RFC1806].
1654
1655        content-disposition = "Content-Disposition" ":"
1656                              disposition-type *( ";" disposition-parm )
1657        disposition-type = "attachment" | disp-extension-token
1658        disposition-parm = filename-parm | disp-extension-parm
1659        filename-parm = "filename" "=" quoted-string
1660        disp-extension-token = token
1661        disp-extension-parm = token "=" ( token | quoted-string )
1662
1663   An example is
1664
1665        Content-Disposition: attachment; filename="fname.ext"
1666
1667   The receiving user agent SHOULD NOT respect any directory path
1668   information present in the filename-parm parameter, which is the only
1669   parameter believed to apply to HTTP implementations at this time.
1670   The filename SHOULD be treated as a terminal component only.
1671
1672   If this header is used in a response with the application/
1673   octet-stream content-type, the implied suggestion is that the user
1674   agent should not display the response, but directly enter a `save
1675   response as...' dialog.
1676
1677
1678
1679Fielding, et al.          Expires June 22, 2008                [Page 30]
1680
1681Internet-Draft                  HTTP/1.1                   December 2007
1682
1683
1684   See Section 7.2 for Content-Disposition security issues.
1685
1686
1687Appendix C.  Changes from RFC 2068
1688
1689   Charset wildcarding is introduced to avoid explosion of character set
1690   names in accept headers.  (Section 5.2)
1691
1692   Content-Base was deleted from the specification: it was not
1693   implemented widely, and there is no simple, safe way to introduce it
1694   without a robust extension mechanism.  In addition, it is used in a
1695   similar, but not identical fashion in MHTML [RFC2110].
1696
1697   A content-coding of "identity" was introduced, to solve problems
1698   discovered in caching.  (Section 2.2)
1699
1700   Quality Values of zero should indicate that "I don't want something"
1701   to allow clients to refuse a representation.  (Section 2.4)
1702
1703   The Alternates, Content-Version, Derived-From, Link, URI, Public and
1704   Content-Base header fields were defined in previous versions of this
1705   specification, but not commonly implemented.  See RFC 2068 [RFC2068].
1706
1707
1708Index
1709
1710   A
1711      Accept header  15
1712      Accept-Charset header  17
1713      Accept-Encoding header  17
1714      Accept-Language header  19
1715      Alternates header  31
1716
1717   C
1718      compress  6
1719      Content-Base header  31
1720      Content-Disposition header  30
1721      Content-Encoding header  20
1722      Content-Language header  21
1723      Content-Location header  22
1724      Content-MD5 header  22
1725      Content-Type header  24
1726      Content-Version header  31
1727
1728   D
1729      deflate  7
1730      Derived-From header  31
1731
1732
1733
1734
1735Fielding, et al.          Expires June 22, 2008                [Page 31]
1736
1737Internet-Draft                  HTTP/1.1                   December 2007
1738
1739
1740   G
1741      Grammar
1742         Accept  15
1743         Accept-Charset  17
1744         Accept-Encoding  18
1745         accept-extension  15
1746         Accept-Language  19
1747         accept-params  15
1748         attribute  7
1749         charset  5
1750         codings  18
1751         content-coding  6
1752         content-disposition  30
1753         Content-Encoding  20
1754         Content-Language  21
1755         Content-Location  22
1756         Content-MD5  23
1757         Content-Type  24
1758         disp-extension-parm  30
1759         disp-extension-token  30
1760         disposition-parm  30
1761         disposition-type  30
1762         entity-body  11
1763         entity-header  11
1764         extension-header  11
1765         filename-parm  30
1766         language-range  19
1767         language-tag  10
1768         md5-digest  23
1769         media-range  15
1770         media-type  7
1771         MIME-Version  28
1772         parameter  7
1773         primary-tag  10
1774         qvalue  9
1775         subtag  10
1776         subtype  7
1777         type  7
1778         value  7
1779      gzip  6
1780
1781   H
1782      Headers
1783         Accept  15
1784         Accept-Charset  17
1785         Accept-Encoding  17
1786         Accept-Language  19
1787         Alternate  31
1788
1789
1790
1791Fielding, et al.          Expires June 22, 2008                [Page 32]
1792
1793Internet-Draft                  HTTP/1.1                   December 2007
1794
1795
1796         Content-Base  31
1797         Content-Disposition  30
1798         Content-Encoding  20
1799         Content-Language  21
1800         Content-Location  22
1801         Content-MD5  22
1802         Content-Type  24
1803         Content-Version  31
1804         Derived-From  31
1805         Link  31
1806         Public  31
1807         URI  31
1808
1809   I
1810      identity  7
1811
1812   L
1813      Link header  31
1814
1815   P
1816      Public header  31
1817
1818   U
1819      URI header  31
1820
1821
1822Authors' Addresses
1823
1824   Roy T. Fielding (editor)
1825   Day Software
1826   23 Corporate Plaza DR, Suite 280
1827   Newport Beach, CA  92660
1828   USA
1829
1830   Phone: +1-949-706-5300
1831   Fax:   +1-949-706-5305
1832   Email: fielding@gbiv.com
1833   URI:   http://roy.gbiv.com/
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847Fielding, et al.          Expires June 22, 2008                [Page 33]
1848
1849Internet-Draft                  HTTP/1.1                   December 2007
1850
1851
1852   Jim Gettys
1853   One Laptop per Child
1854   21 Oak Knoll Road
1855   Carlisle, MA  01741
1856   USA
1857
1858   Email: jg@laptop.org
1859   URI:   http://www.laptop.org/
1860
1861
1862   Jeffrey C. Mogul
1863   Hewlett-Packard Company
1864   HP Labs, Large Scale Systems Group
1865   1501 Page Mill Road, MS 1177
1866   Palo Alto, CA  94304
1867   USA
1868
1869   Email: JeffMogul@acm.org
1870
1871
1872   Henrik Frystyk Nielsen
1873   Microsoft Corporation
1874   1 Microsoft Way
1875   Redmond, WA  98052
1876   USA
1877
1878   Email: henrikn@microsoft.com
1879
1880
1881   Larry Masinter
1882   Adobe Systems, Incorporated
1883   345 Park Ave
1884   San Jose, CA  95110
1885   USA
1886
1887   Email: LMM@acm.org
1888   URI:   http://larry.masinter.net/
1889
1890
1891   Paul J. Leach
1892   Microsoft Corporation
1893   1 Microsoft Way
1894   Redmond, WA  98052
1895
1896   Email: paulle@microsoft.com
1897
1898
1899
1900
1901
1902
1903Fielding, et al.          Expires June 22, 2008                [Page 34]
1904
1905Internet-Draft                  HTTP/1.1                   December 2007
1906
1907
1908   Tim Berners-Lee
1909   World Wide Web Consortium
1910   MIT Computer Science and Artificial Intelligence Laboratory
1911   The Stata Center, Building 32
1912   32 Vassar Street
1913   Cambridge, MA  02139
1914   USA
1915
1916   Email: timbl@w3.org
1917   URI:   http://www.w3.org/People/Berners-Lee/
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959Fielding, et al.          Expires June 22, 2008                [Page 35]
1960
1961Internet-Draft                  HTTP/1.1                   December 2007
1962
1963
1964Full Copyright Statement
1965
1966   Copyright (C) The IETF Trust (2007).
1967
1968   This document is subject to the rights, licenses and restrictions
1969   contained in BCP 78, and except as set forth therein, the authors
1970   retain all their rights.
1971
1972   This document and the information contained herein are provided on an
1973   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1974   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1975   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1976   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1977   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1978   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1979
1980
1981Intellectual Property
1982
1983   The IETF takes no position regarding the validity or scope of any
1984   Intellectual Property Rights or other rights that might be claimed to
1985   pertain to the implementation or use of the technology described in
1986   this document or the extent to which any license under such rights
1987   might or might not be available; nor does it represent that it has
1988   made any independent effort to identify any such rights.  Information
1989   on the procedures with respect to rights in RFC documents can be
1990   found in BCP 78 and BCP 79.
1991
1992   Copies of IPR disclosures made to the IETF Secretariat and any
1993   assurances of licenses to be made available, or the result of an
1994   attempt made to obtain a general license or permission for the use of
1995   such proprietary rights by implementers or users of this
1996   specification can be obtained from the IETF on-line IPR repository at
1997   http://www.ietf.org/ipr.
1998
1999   The IETF invites any interested party to bring to its attention any
2000   copyrights, patents or patent applications, or other proprietary
2001   rights that may cover technology that may be required to implement
2002   this standard.  Please address the information to the IETF at
2003   ietf-ipr@ietf.org.
2004
2005
2006Acknowledgment
2007
2008   Funding for the RFC Editor function is provided by the IETF
2009   Administrative Support Activity (IASA).
2010
2011
2012
2013
2014
2015Fielding, et al.          Expires June 22, 2008                [Page 36]
2016
Note: See TracBrowser for help on using the repository browser.