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