1 | <?xml version="1.0" encoding="UTF-8"?> |
---|
2 | <!-- |
---|
3 | This XML document is the output of clean-for-DTD.xslt; a tool that strips |
---|
4 | extensions to RFC2629(bis) from documents for processing with xml2rfc. |
---|
5 | --> |
---|
6 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
7 | <?rfc toc="yes" ?> |
---|
8 | <?rfc symrefs="yes" ?> |
---|
9 | <?rfc sortrefs="yes" ?> |
---|
10 | <?rfc compact="yes"?> |
---|
11 | <?rfc subcompact="no" ?> |
---|
12 | <?rfc linkmailto="no" ?> |
---|
13 | <?rfc editing="no" ?> |
---|
14 | <?rfc comments="yes"?> |
---|
15 | <?rfc inline="yes"?> |
---|
16 | <?rfc rfcedstyle="yes"?> |
---|
17 | <!DOCTYPE rfc |
---|
18 | PUBLIC "" "rfc2629.dtd"> |
---|
19 | <rfc obsoletes="2616" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p3-payload-10"> |
---|
20 | <front> |
---|
21 | |
---|
22 | <title abbrev="HTTP/1.1, Part 3">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> |
---|
23 | |
---|
24 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
25 | <organization abbrev="Day Software">Day Software</organization> |
---|
26 | <address> |
---|
27 | <postal> |
---|
28 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
29 | <city>Newport Beach</city> |
---|
30 | <region>CA</region> |
---|
31 | <code>92660</code> |
---|
32 | <country>USA</country> |
---|
33 | </postal> |
---|
34 | <phone>+1-949-706-5300</phone> |
---|
35 | <facsimile>+1-949-706-5305</facsimile> |
---|
36 | <email>fielding@gbiv.com</email> |
---|
37 | <uri>http://roy.gbiv.com/</uri> |
---|
38 | </address> |
---|
39 | </author> |
---|
40 | |
---|
41 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
42 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
43 | <address> |
---|
44 | <postal> |
---|
45 | <street>21 Oak Knoll Road</street> |
---|
46 | <city>Carlisle</city> |
---|
47 | <region>MA</region> |
---|
48 | <code>01741</code> |
---|
49 | <country>USA</country> |
---|
50 | </postal> |
---|
51 | <email>jg@freedesktop.org</email> |
---|
52 | <uri>http://gettys.wordpress.com/</uri> |
---|
53 | </address> |
---|
54 | </author> |
---|
55 | |
---|
56 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
57 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
58 | <address> |
---|
59 | <postal> |
---|
60 | <street>HP Labs, Large Scale Systems Group</street> |
---|
61 | <street>1501 Page Mill Road, MS 1177</street> |
---|
62 | <city>Palo Alto</city> |
---|
63 | <region>CA</region> |
---|
64 | <code>94304</code> |
---|
65 | <country>USA</country> |
---|
66 | </postal> |
---|
67 | <email>JeffMogul@acm.org</email> |
---|
68 | </address> |
---|
69 | </author> |
---|
70 | |
---|
71 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
72 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
73 | <address> |
---|
74 | <postal> |
---|
75 | <street>1 Microsoft Way</street> |
---|
76 | <city>Redmond</city> |
---|
77 | <region>WA</region> |
---|
78 | <code>98052</code> |
---|
79 | <country>USA</country> |
---|
80 | </postal> |
---|
81 | <email>henrikn@microsoft.com</email> |
---|
82 | </address> |
---|
83 | </author> |
---|
84 | |
---|
85 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
86 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
87 | <address> |
---|
88 | <postal> |
---|
89 | <street>345 Park Ave</street> |
---|
90 | <city>San Jose</city> |
---|
91 | <region>CA</region> |
---|
92 | <code>95110</code> |
---|
93 | <country>USA</country> |
---|
94 | </postal> |
---|
95 | <email>LMM@acm.org</email> |
---|
96 | <uri>http://larry.masinter.net/</uri> |
---|
97 | </address> |
---|
98 | </author> |
---|
99 | |
---|
100 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
101 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
102 | <address> |
---|
103 | <postal> |
---|
104 | <street>1 Microsoft Way</street> |
---|
105 | <city>Redmond</city> |
---|
106 | <region>WA</region> |
---|
107 | <code>98052</code> |
---|
108 | </postal> |
---|
109 | <email>paulle@microsoft.com</email> |
---|
110 | </address> |
---|
111 | </author> |
---|
112 | |
---|
113 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
114 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
115 | <address> |
---|
116 | <postal> |
---|
117 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
118 | <street>The Stata Center, Building 32</street> |
---|
119 | <street>32 Vassar Street</street> |
---|
120 | <city>Cambridge</city> |
---|
121 | <region>MA</region> |
---|
122 | <code>02139</code> |
---|
123 | <country>USA</country> |
---|
124 | </postal> |
---|
125 | <email>timbl@w3.org</email> |
---|
126 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
127 | </address> |
---|
128 | </author> |
---|
129 | |
---|
130 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
131 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
132 | <address> |
---|
133 | <postal> |
---|
134 | <street>W3C / ERCIM</street> |
---|
135 | <street>2004, rte des Lucioles</street> |
---|
136 | <city>Sophia-Antipolis</city> |
---|
137 | <region>AM</region> |
---|
138 | <code>06902</code> |
---|
139 | <country>France</country> |
---|
140 | </postal> |
---|
141 | <email>ylafon@w3.org</email> |
---|
142 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
143 | </address> |
---|
144 | </author> |
---|
145 | |
---|
146 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
147 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
148 | <address> |
---|
149 | <postal> |
---|
150 | <street>Hafenweg 16</street> |
---|
151 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
152 | <country>Germany</country> |
---|
153 | </postal> |
---|
154 | <phone>+49 251 2807760</phone> |
---|
155 | <facsimile>+49 251 2807761</facsimile> |
---|
156 | <email>julian.reschke@greenbytes.de</email> |
---|
157 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
158 | </address> |
---|
159 | </author> |
---|
160 | |
---|
161 | <date month="July" year="2010" day="12"/> |
---|
162 | <workgroup>HTTPbis Working Group</workgroup> |
---|
163 | |
---|
164 | <abstract> |
---|
165 | <t> |
---|
166 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
167 | protocol for distributed, collaborative, hypermedia information |
---|
168 | systems. HTTP has been in use by the World Wide Web global information |
---|
169 | initiative since 1990. This document is Part 3 of the seven-part specification |
---|
170 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
171 | obsoletes RFC 2616. Part 3 defines HTTP message content, |
---|
172 | metadata, and content negotiation. |
---|
173 | </t> |
---|
174 | </abstract> |
---|
175 | |
---|
176 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
177 | <t> |
---|
178 | Discussion of this draft should take place on the HTTPBIS working group |
---|
179 | mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
180 | at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> |
---|
181 | and related documents (including fancy diffs) can be found at |
---|
182 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
183 | </t> |
---|
184 | <t> |
---|
185 | The changes in this draft are summarized in <xref target="changes.since.09"/>. |
---|
186 | </t> |
---|
187 | </note> |
---|
188 | </front> |
---|
189 | <middle> |
---|
190 | <section title="Introduction" anchor="introduction"> |
---|
191 | <t> |
---|
192 | This document defines HTTP/1.1 message payloads (a.k.a., content), the |
---|
193 | associated metadata header fields that define how the payload is intended |
---|
194 | to be interpreted by a recipient, the request header fields that |
---|
195 | may influence content selection, and the various selection algorithms |
---|
196 | that are collectively referred to as HTTP content negotiation. |
---|
197 | </t> |
---|
198 | <t> |
---|
199 | This document is currently disorganized in order to minimize the changes |
---|
200 | between drafts and enable reviewers to see the smaller errata changes. |
---|
201 | The next draft will reorganize the sections to better reflect the content. |
---|
202 | In particular, the sections on entities will be renamed payload and moved |
---|
203 | to the first half of the document, while the sections on content negotiation |
---|
204 | and associated request header fields will be moved to the second half. The |
---|
205 | current mess reflects how widely dispersed these topics and associated |
---|
206 | requirements had become in <xref target="RFC2616"/>. |
---|
207 | </t> |
---|
208 | |
---|
209 | <section title="Terminology" anchor="terminology"> |
---|
210 | <t> |
---|
211 | This specification uses a number of terms to refer to the roles |
---|
212 | played by participants in, and objects of, the HTTP communication. |
---|
213 | </t> |
---|
214 | <t> |
---|
215 | <iref item="content negotiation"/> |
---|
216 | <?rfc needLines="4"?>content negotiation |
---|
217 | <list> |
---|
218 | <t> |
---|
219 | The mechanism for selecting the appropriate representation when |
---|
220 | servicing a request. The representation of entities in any response |
---|
221 | can be negotiated (including error responses). |
---|
222 | </t> |
---|
223 | </list> |
---|
224 | </t> |
---|
225 | <t> |
---|
226 | <iref item="entity"/> |
---|
227 | <?rfc needLines="4"?>entity |
---|
228 | <list> |
---|
229 | <t> |
---|
230 | The information transferred as the payload of a request or |
---|
231 | response. An entity consists of metadata in the form of |
---|
232 | entity-header fields and content in the form of an entity-body. |
---|
233 | </t> |
---|
234 | </list> |
---|
235 | </t> |
---|
236 | <t> |
---|
237 | <iref item="representation"/> |
---|
238 | <?rfc needLines="4"?>representation |
---|
239 | <list> |
---|
240 | <t> |
---|
241 | An entity included with a response that is subject to content |
---|
242 | negotiation. There may exist multiple |
---|
243 | representations associated with a particular response status. |
---|
244 | </t> |
---|
245 | </list> |
---|
246 | </t> |
---|
247 | <t> |
---|
248 | <iref item="variant"/> |
---|
249 | <?rfc needLines="4"?>variant |
---|
250 | <list> |
---|
251 | <t> |
---|
252 | A resource may have one, or more than one, representation(s) |
---|
253 | associated with it at any given instant. Each of these |
---|
254 | representations is termed a "variant". Use of the term "variant" |
---|
255 | does not necessarily imply that the resource is subject to content |
---|
256 | negotiation. |
---|
257 | </t> |
---|
258 | </list> |
---|
259 | </t> |
---|
260 | </section> |
---|
261 | |
---|
262 | <section title="Requirements" anchor="intro.requirements"> |
---|
263 | <t> |
---|
264 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
265 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
266 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
267 | </t> |
---|
268 | <t> |
---|
269 | An implementation is not compliant if it fails to satisfy one or more |
---|
270 | of the "MUST" or "REQUIRED" level requirements for the protocols it |
---|
271 | implements. An implementation that satisfies all the "MUST" or "REQUIRED" |
---|
272 | level and all the "SHOULD" level requirements for its protocols is said |
---|
273 | to be "unconditionally compliant"; one that satisfies all the "MUST" |
---|
274 | level requirements but not all the "SHOULD" level requirements for its |
---|
275 | protocols is said to be "conditionally compliant". |
---|
276 | </t> |
---|
277 | </section> |
---|
278 | |
---|
279 | <section title="Syntax Notation" anchor="notation"> |
---|
280 | |
---|
281 | |
---|
282 | |
---|
283 | |
---|
284 | |
---|
285 | |
---|
286 | |
---|
287 | <t> |
---|
288 | This specification uses the ABNF syntax defined in Section 1.2 of <xref target="Part1"/> (which |
---|
289 | extends the syntax defined in <xref target="RFC5234"/> with a list rule). |
---|
290 | <xref target="collected.abnf"/> shows the collected ABNF, with the list |
---|
291 | rule expanded. |
---|
292 | </t> |
---|
293 | <t> |
---|
294 | The following core rules are included by |
---|
295 | reference, as defined in <xref target="RFC5234"/>, Appendix B.1: |
---|
296 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
297 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
298 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), |
---|
299 | OCTET (any 8-bit sequence of data), SP (space), |
---|
300 | VCHAR (any visible USASCII character), |
---|
301 | and WSP (whitespace). |
---|
302 | </t> |
---|
303 | |
---|
304 | <section title="Core Rules" anchor="core.rules"> |
---|
305 | |
---|
306 | |
---|
307 | |
---|
308 | |
---|
309 | <t> |
---|
310 | The core rules below are defined in Section 1.2.2 of <xref target="Part1"/>: |
---|
311 | </t> |
---|
312 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
313 | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
---|
314 | token = <token, defined in [Part1], Section 1.2.2> |
---|
315 | word = <word, defined in [Part1], Section 1.2.2> |
---|
316 | OWS = <OWS, defined in [Part1], Section 1.2.2> |
---|
317 | ]]></artwork></figure> |
---|
318 | </section> |
---|
319 | |
---|
320 | <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> |
---|
321 | |
---|
322 | |
---|
323 | |
---|
324 | |
---|
325 | |
---|
326 | |
---|
327 | |
---|
328 | |
---|
329 | |
---|
330 | <t> |
---|
331 | The ABNF rules below are defined in other parts: |
---|
332 | </t> |
---|
333 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
334 | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
---|
335 | Content-Length = <Content-Length, defined in [Part1], Section 9.2> |
---|
336 | header-field = <header-field, defined in [Part1], Section 3.2> |
---|
337 | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
---|
338 | qvalue = <qvalue, defined in [Part1], Section 6.4> |
---|
339 | ]]></artwork></figure> |
---|
340 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
341 | Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |
---|
342 | ]]></artwork></figure> |
---|
343 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
344 | Content-Range = <Content-Range, defined in [Part5], Section 5.2> |
---|
345 | ]]></artwork></figure> |
---|
346 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
347 | Expires = <Expires, defined in [Part6], Section 3.3> |
---|
348 | ]]></artwork></figure> |
---|
349 | </section> |
---|
350 | |
---|
351 | </section> |
---|
352 | |
---|
353 | </section> |
---|
354 | |
---|
355 | <section title="Protocol Parameters" anchor="protocol.parameters"> |
---|
356 | |
---|
357 | <section title="Character Sets" anchor="character.sets"> |
---|
358 | <t> |
---|
359 | HTTP uses the same definition of the term "character set" as that |
---|
360 | described for MIME: |
---|
361 | </t> |
---|
362 | <t> |
---|
363 | The term "character set" is used in this document to refer to a |
---|
364 | method used with one or more tables to convert a sequence of octets |
---|
365 | into a sequence of characters. Note that unconditional conversion in |
---|
366 | the other direction is not required, in that not all characters may |
---|
367 | be available in a given character set and a character set may provide |
---|
368 | more than one sequence of octets to represent a particular character. |
---|
369 | This definition is intended to allow various kinds of character |
---|
370 | encoding, from simple single-table mappings such as US-ASCII to |
---|
371 | complex table switching methods such as those that use ISO-2022's |
---|
372 | techniques. However, the definition associated with a MIME character |
---|
373 | set name MUST fully specify the mapping to be performed from octets |
---|
374 | to characters. In particular, use of external profiling information |
---|
375 | to determine the exact mapping is not permitted. |
---|
376 | </t> |
---|
377 | <t><list> |
---|
378 | <t> |
---|
379 | Note: This use of the term "character set" is more commonly |
---|
380 | referred to as a "character encoding." However, since HTTP and |
---|
381 | MIME share the same registry, it is important that the terminology |
---|
382 | also be shared. |
---|
383 | </t> |
---|
384 | </list></t> |
---|
385 | <t anchor="rule.charset"> |
---|
386 | |
---|
387 | HTTP character sets are identified by case-insensitive tokens. The |
---|
388 | complete set of tokens is defined by the IANA Character Set registry |
---|
389 | (<eref target="http://www.iana.org/assignments/character-sets"/>). |
---|
390 | </t> |
---|
391 | <figure><iref primary="true" item="Grammar" subitem="charset"/><artwork type="abnf2616"><![CDATA[ |
---|
392 | charset = token |
---|
393 | ]]></artwork></figure> |
---|
394 | <t> |
---|
395 | Although HTTP allows an arbitrary token to be used as a charset |
---|
396 | value, any token that has a predefined value within the IANA |
---|
397 | Character Set registry MUST represent the character set defined |
---|
398 | by that registry. Applications SHOULD limit their use of character |
---|
399 | sets to those defined by the IANA registry. |
---|
400 | </t> |
---|
401 | <t> |
---|
402 | HTTP uses charset in two contexts: within an Accept-Charset request |
---|
403 | header (in which the charset value is an unquoted token) and as the |
---|
404 | value of a parameter in a Content-Type header (within a request or |
---|
405 | response), in which case the parameter value of the charset parameter |
---|
406 | may be quoted. |
---|
407 | </t> |
---|
408 | <t> |
---|
409 | Implementors should be aware of IETF character set requirements <xref target="RFC3629"/> |
---|
410 | <xref target="RFC2277"/>. |
---|
411 | </t> |
---|
412 | |
---|
413 | <section title="Missing Charset" anchor="missing.charset"> |
---|
414 | <t> |
---|
415 | Some HTTP/1.0 software has interpreted a Content-Type header without |
---|
416 | charset parameter incorrectly to mean "recipient should guess." |
---|
417 | Senders wishing to defeat this behavior MAY include a charset |
---|
418 | parameter even when the charset is ISO-8859-1 (<xref target="ISO-8859-1"/>) and SHOULD do so when |
---|
419 | it is known that it will not confuse the recipient. |
---|
420 | </t> |
---|
421 | <t> |
---|
422 | Unfortunately, some older HTTP/1.0 clients did not deal properly with |
---|
423 | an explicit charset parameter. HTTP/1.1 recipients MUST respect the |
---|
424 | charset label provided by the sender; and those user agents that have |
---|
425 | a provision to "guess" a charset MUST use the charset from the |
---|
426 | content-type field if they support that charset, rather than the |
---|
427 | recipient's preference, when initially displaying a document. See |
---|
428 | <xref target="canonicalization.and.text.defaults"/>. |
---|
429 | </t> |
---|
430 | </section> |
---|
431 | </section> |
---|
432 | |
---|
433 | <section title="Content Codings" anchor="content.codings"> |
---|
434 | |
---|
435 | <t> |
---|
436 | Content coding values indicate an encoding transformation that has |
---|
437 | been or can be applied to an entity. Content codings are primarily |
---|
438 | used to allow a document to be compressed or otherwise usefully |
---|
439 | transformed without losing the identity of its underlying media type |
---|
440 | and without loss of information. Frequently, the entity is stored in |
---|
441 | coded form, transmitted directly, and only decoded by the recipient. |
---|
442 | </t> |
---|
443 | <figure><iref primary="true" item="Grammar" subitem="content-coding"/><artwork type="abnf2616"><![CDATA[ |
---|
444 | content-coding = token |
---|
445 | ]]></artwork></figure> |
---|
446 | <t> |
---|
447 | All content-coding values are case-insensitive. HTTP/1.1 uses |
---|
448 | content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and |
---|
449 | Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value |
---|
450 | describes the content-coding, what is more important is that it |
---|
451 | indicates what decoding mechanism will be required to remove the |
---|
452 | encoding. |
---|
453 | </t> |
---|
454 | <t> |
---|
455 | compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/> |
---|
456 | <list> |
---|
457 | <t> |
---|
458 | See Section 6.2.2.1 of <xref target="Part1"/>. |
---|
459 | </t> |
---|
460 | </list> |
---|
461 | </t> |
---|
462 | <t> |
---|
463 | deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/> |
---|
464 | <list> |
---|
465 | <t> |
---|
466 | See Section 6.2.2.2 of <xref target="Part1"/>. |
---|
467 | </t> |
---|
468 | </list> |
---|
469 | </t> |
---|
470 | <t> |
---|
471 | gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/> |
---|
472 | <list> |
---|
473 | <t> |
---|
474 | See Section 6.2.2.3 of <xref target="Part1"/>. |
---|
475 | </t> |
---|
476 | </list> |
---|
477 | </t> |
---|
478 | <t> |
---|
479 | identity<iref item="identity (Coding Format)"/><iref item="Coding Format" subitem="identity"/> |
---|
480 | <list><t> |
---|
481 | The default (identity) encoding; the use of no transformation |
---|
482 | whatsoever. This content-coding is used only in the Accept-Encoding |
---|
483 | header, and SHOULD NOT be used in the Content-Encoding |
---|
484 | header. |
---|
485 | </t></list> |
---|
486 | </t> |
---|
487 | |
---|
488 | <section title="Content Coding Registry" anchor="content.coding.registry"> |
---|
489 | <t> |
---|
490 | The HTTP Content Coding Registry defines the name space for the content |
---|
491 | coding names. |
---|
492 | </t> |
---|
493 | <t> |
---|
494 | Registrations MUST include the following fields: |
---|
495 | <list style="symbols"> |
---|
496 | <t>Name</t> |
---|
497 | <t>Description</t> |
---|
498 | <t>Pointer to specification text</t> |
---|
499 | </list> |
---|
500 | </t> |
---|
501 | <t> |
---|
502 | Names of content codings MUST NOT overlap with names of transfer codings |
---|
503 | (Section 6.2 of <xref target="Part1"/>), unless the encoding transformation is identical (as it |
---|
504 | is the case for the compression codings defined in |
---|
505 | Section 6.2.2 of <xref target="Part1"/>). |
---|
506 | </t> |
---|
507 | <t> |
---|
508 | Values to be added to this name space require expert review and a specification |
---|
509 | (see "Expert Review" and "Specification Required" in |
---|
510 | Section 4.1 of <xref target="RFC5226"/>), and MUST |
---|
511 | conform to the purpose of content coding defined in this section. |
---|
512 | </t> |
---|
513 | <t> |
---|
514 | The registry itself is maintained at |
---|
515 | <eref target="http://www.iana.org/assignments/http-parameters"/>. |
---|
516 | </t> |
---|
517 | </section> |
---|
518 | |
---|
519 | </section> |
---|
520 | |
---|
521 | <section title="Media Types" anchor="media.types"> |
---|
522 | |
---|
523 | |
---|
524 | |
---|
525 | <t> |
---|
526 | HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>) |
---|
527 | and Accept (<xref target="header.accept"/>) header fields in order to provide |
---|
528 | open and extensible data typing and type negotiation. |
---|
529 | </t> |
---|
530 | <figure><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/><artwork type="abnf2616"><![CDATA[ |
---|
531 | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
---|
532 | type = token |
---|
533 | subtype = token |
---|
534 | ]]></artwork></figure> |
---|
535 | <t anchor="rule.parameter"> |
---|
536 | |
---|
537 | |
---|
538 | |
---|
539 | Parameters MAY follow the type/subtype in the form of attribute/value |
---|
540 | pairs. |
---|
541 | </t> |
---|
542 | <figure><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/><artwork type="abnf2616"><![CDATA[ |
---|
543 | parameter = attribute "=" value |
---|
544 | attribute = token |
---|
545 | value = word |
---|
546 | ]]></artwork></figure> |
---|
547 | <t> |
---|
548 | The type, subtype, and parameter attribute names are case-insensitive. |
---|
549 | Parameter values might or might not be case-sensitive, depending on the |
---|
550 | semantics of the parameter name. The presence or absence of a parameter might |
---|
551 | be significant to the processing of a media-type, depending on its |
---|
552 | definition within the media type registry. |
---|
553 | </t> |
---|
554 | <t> |
---|
555 | A parameter value that matches the <xref target="core.rules" format="none">token</xref> production may be |
---|
556 | transmitted as either a token or within a quoted-string. The quoted and |
---|
557 | unquoted values are equivalent. |
---|
558 | </t> |
---|
559 | <t> |
---|
560 | Note that some older HTTP applications do not recognize media type |
---|
561 | parameters. When sending data to older HTTP applications, |
---|
562 | implementations SHOULD only use media type parameters when they are |
---|
563 | required by that type/subtype definition. |
---|
564 | </t> |
---|
565 | <t> |
---|
566 | Media-type values are registered with the Internet Assigned Number |
---|
567 | Authority (IANA). The media type registration process is |
---|
568 | outlined in <xref target="RFC4288"/>. Use of non-registered media types is |
---|
569 | discouraged. |
---|
570 | </t> |
---|
571 | |
---|
572 | <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults"> |
---|
573 | <t> |
---|
574 | Internet media types are registered with a canonical form. An |
---|
575 | entity-body transferred via HTTP messages MUST be represented in the |
---|
576 | appropriate canonical form prior to its transmission except for |
---|
577 | "text" types, as defined in the next paragraph. |
---|
578 | </t> |
---|
579 | <t> |
---|
580 | When in canonical form, media subtypes of the "text" type use CRLF as |
---|
581 | the text line break. HTTP relaxes this requirement and allows the |
---|
582 | transport of text media with plain CR or LF alone representing a line |
---|
583 | break when it is done consistently for an entire entity-body. HTTP |
---|
584 | applications MUST accept CRLF, bare CR, and bare LF as being |
---|
585 | representative of a line break in text media received via HTTP. In |
---|
586 | addition, if the text is represented in a character set that does not |
---|
587 | use octets 13 and 10 for CR and LF respectively, as is the case for |
---|
588 | some multi-byte character sets, HTTP allows the use of whatever octet |
---|
589 | sequences are defined by that character set to represent the |
---|
590 | equivalent of CR and LF for line breaks. This flexibility regarding |
---|
591 | line breaks applies only to text media in the entity-body; a bare CR |
---|
592 | or LF MUST NOT be substituted for CRLF within any of the HTTP control |
---|
593 | structures (such as header fields and multipart boundaries). |
---|
594 | </t> |
---|
595 | <t> |
---|
596 | If an entity-body is encoded with a content-coding, the underlying |
---|
597 | data MUST be in a form defined above prior to being encoded. |
---|
598 | </t> |
---|
599 | <t> |
---|
600 | The "charset" parameter is used with some media types to define the |
---|
601 | character set (<xref target="character.sets"/>) of the data. When no explicit charset |
---|
602 | parameter is provided by the sender, media subtypes of the "text" |
---|
603 | type are defined to have a default charset value of "ISO-8859-1" when |
---|
604 | received via HTTP. Data in character sets other than "ISO-8859-1" or |
---|
605 | its subsets MUST be labeled with an appropriate charset value. See |
---|
606 | <xref target="missing.charset"/> for compatibility problems. |
---|
607 | </t> |
---|
608 | </section> |
---|
609 | |
---|
610 | <section title="Multipart Types" anchor="multipart.types"> |
---|
611 | <t> |
---|
612 | MIME provides for a number of "multipart" types -- encapsulations of |
---|
613 | one or more entities within a single message-body. All multipart |
---|
614 | types share a common syntax, as defined in Section 5.1.1 of <xref target="RFC2046"/>, |
---|
615 | and MUST include a boundary parameter as part of the media type |
---|
616 | value. The message body is itself a protocol element and MUST |
---|
617 | therefore use only CRLF to represent line breaks between body-parts. |
---|
618 | Unlike in RFC 2046, the epilogue of any multipart message MUST be |
---|
619 | empty; HTTP applications MUST NOT transmit the epilogue (even if the |
---|
620 | original multipart contains an epilogue). These restrictions exist in |
---|
621 | order to preserve the self-delimiting nature of a multipart message-body, |
---|
622 | wherein the "end" of the message-body is indicated by the |
---|
623 | ending multipart boundary. |
---|
624 | </t> |
---|
625 | <t> |
---|
626 | In general, HTTP treats a multipart message-body no differently than |
---|
627 | any other media type: strictly as payload. The one exception is the |
---|
628 | "multipart/byteranges" type (Appendix A of <xref target="Part5"/>) when it appears in a 206 |
---|
629 | (Partial Content) response. |
---|
630 | <!-- jre: re-insert removed text pointing to caching? --> |
---|
631 | In all |
---|
632 | other cases, an HTTP user agent SHOULD follow the same or similar |
---|
633 | behavior as a MIME user agent would upon receipt of a multipart type. |
---|
634 | The MIME header fields within each body-part of a multipart message-body |
---|
635 | do not have any significance to HTTP beyond that defined by |
---|
636 | their MIME semantics. |
---|
637 | </t> |
---|
638 | <t> |
---|
639 | In general, an HTTP user agent SHOULD follow the same or similar |
---|
640 | behavior as a MIME user agent would upon receipt of a multipart type. |
---|
641 | If an application receives an unrecognized multipart subtype, the |
---|
642 | application MUST treat it as being equivalent to "multipart/mixed". |
---|
643 | </t> |
---|
644 | <t><list> |
---|
645 | <t> |
---|
646 | Note: The "multipart/form-data" type has been specifically defined |
---|
647 | for carrying form data suitable for processing via the POST |
---|
648 | request method, as described in <xref target="RFC2388"/>. |
---|
649 | </t> |
---|
650 | </list></t> |
---|
651 | </section> |
---|
652 | </section> |
---|
653 | |
---|
654 | <section title="Language Tags" anchor="language.tags"> |
---|
655 | |
---|
656 | <t> |
---|
657 | A language tag, as defined in <xref target="RFC5646"/>, identifies a |
---|
658 | natural language spoken, written, or otherwise conveyed by human beings for |
---|
659 | communication of information to other human beings. Computer languages are |
---|
660 | explicitly excluded. HTTP uses language tags within the Accept-Language and |
---|
661 | Content-Language fields. |
---|
662 | </t> |
---|
663 | <t> |
---|
664 | In summary, a language tag is composed of one or more parts: A primary |
---|
665 | language subtag followed by a possibly empty series of subtags: |
---|
666 | </t> |
---|
667 | <figure><iref primary="true" item="Grammar" subitem="language-tag"/><artwork type="abnf2616"><![CDATA[ |
---|
668 | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
---|
669 | ]]></artwork></figure> |
---|
670 | <t> |
---|
671 | White space is not allowed within the tag and all tags are case-insensitive. |
---|
672 | The name space of language subtags is administered by the IANA (see |
---|
673 | <eref target="http://www.iana.org/assignments/language-subtag-registry"/>). |
---|
674 | </t> |
---|
675 | <figure> |
---|
676 | <preamble>Example tags include:</preamble> |
---|
677 | <artwork type="example"><![CDATA[ |
---|
678 | en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |
---|
679 | ]]></artwork> |
---|
680 | </figure> |
---|
681 | <t> |
---|
682 | See <xref target="RFC5646"/> for further information. |
---|
683 | </t> |
---|
684 | </section> |
---|
685 | </section> |
---|
686 | |
---|
687 | <section title="Entity" anchor="entity"> |
---|
688 | <t> |
---|
689 | Request and Response messages MAY transfer an entity if not otherwise |
---|
690 | restricted by the request method or response status code. An entity |
---|
691 | consists of entity-header fields and an entity-body, although some |
---|
692 | responses will only include the entity-headers. |
---|
693 | </t> |
---|
694 | <t> |
---|
695 | In this section, both sender and recipient refer to either the client |
---|
696 | or the server, depending on who sends and who receives the entity. |
---|
697 | </t> |
---|
698 | |
---|
699 | <section title="Entity Header Fields" anchor="entity.header.fields"> |
---|
700 | |
---|
701 | |
---|
702 | <t> |
---|
703 | Entity-header fields define metainformation about the entity-body or, |
---|
704 | if no body is present, about the resource identified by the request. |
---|
705 | </t> |
---|
706 | <figure><iref primary="true" item="Grammar" subitem="entity-header"/><iref primary="true" item="Grammar" subitem="extension-header"/><artwork type="abnf2616"><![CDATA[ |
---|
707 | entity-header = Content-Encoding ; Section 5.5 |
---|
708 | / Content-Language ; Section 5.6 |
---|
709 | / Content-Length ; [Part1], Section 9.2 |
---|
710 | / Content-Location ; Section 5.7 |
---|
711 | / Content-MD5 ; Section 5.8 |
---|
712 | / Content-Range ; [Part5], Section 5.2 |
---|
713 | / Content-Type ; Section 5.9 |
---|
714 | / Expires ; [Part6], Section 3.3 |
---|
715 | / Last-Modified ; [Part4], Section 6.6 |
---|
716 | / extension-header |
---|
717 | |
---|
718 | extension-header = header-field |
---|
719 | ]]></artwork></figure> |
---|
720 | <t> |
---|
721 | The extension-header mechanism allows additional entity-header fields |
---|
722 | to be defined without changing the protocol, but these fields cannot |
---|
723 | be assumed to be recognizable by the recipient. Unrecognized header |
---|
724 | fields SHOULD be ignored by the recipient and MUST be forwarded by |
---|
725 | transparent proxies. |
---|
726 | </t> |
---|
727 | </section> |
---|
728 | |
---|
729 | <section title="Entity Body" anchor="entity.body"> |
---|
730 | |
---|
731 | <t> |
---|
732 | The entity-body (if any) sent with an HTTP request or response is in |
---|
733 | a format and encoding defined by the entity-header fields. |
---|
734 | </t> |
---|
735 | <figure><iref primary="true" item="Grammar" subitem="entity-body"/><artwork type="abnf2616"><![CDATA[ |
---|
736 | entity-body = *OCTET |
---|
737 | ]]></artwork></figure> |
---|
738 | <t> |
---|
739 | An entity-body is only present in a message when a message-body is |
---|
740 | present, as described in Section 3.3 of <xref target="Part1"/>. The entity-body is obtained |
---|
741 | from the message-body by decoding any Transfer-Encoding that might |
---|
742 | have been applied to ensure safe and proper transfer of the message. |
---|
743 | </t> |
---|
744 | |
---|
745 | <section title="Type" anchor="type"> |
---|
746 | <t> |
---|
747 | When an entity-body is included with a message, the data type of that |
---|
748 | body is determined via the header fields Content-Type and Content-Encoding. |
---|
749 | These define a two-layer, ordered encoding model: |
---|
750 | </t> |
---|
751 | <figure><artwork type="example"><![CDATA[ |
---|
752 | entity-body := Content-Encoding( Content-Type( data ) ) |
---|
753 | ]]></artwork></figure> |
---|
754 | <t> |
---|
755 | Content-Type specifies the media type of the underlying data. Any HTTP/1.1 |
---|
756 | message containing an entity-body SHOULD include a Content-Type header |
---|
757 | field defining the media type of that body, unless that information is |
---|
758 | unknown. |
---|
759 | </t> |
---|
760 | <t> |
---|
761 | If the Content-Type header field is not present, it indicates that |
---|
762 | the sender does not know the media type of the data; recipients MAY |
---|
763 | either assume that it is "application/octet-stream" (<xref target="RFC2046"/>, Section 4.5.1) |
---|
764 | or examine the content to determine its type. |
---|
765 | </t> |
---|
766 | <t> |
---|
767 | In practice, currently-deployed servers sometimes provide a Content-Type |
---|
768 | header which does not correctly convey the intended interpretation of the |
---|
769 | content sent, with the result that some clients will examine the response |
---|
770 | body's content and override the specified type. |
---|
771 | </t> |
---|
772 | <t> |
---|
773 | Client that do so risk drawing incorrect conclusions, which may expose |
---|
774 | additional security risks (e.g., "privilege escalation"). Implementers are |
---|
775 | encouraged to provide a means of disabling such "content sniffing" when it |
---|
776 | is used. |
---|
777 | </t> |
---|
778 | <t> |
---|
779 | Content-Encoding may be used to indicate any additional content |
---|
780 | codings applied to the data, usually for the purpose of data |
---|
781 | compression, that are a property of the requested resource. There is |
---|
782 | no default encoding. |
---|
783 | </t> |
---|
784 | </section> |
---|
785 | |
---|
786 | <section title="Entity Length" anchor="entity.length"> |
---|
787 | <t> |
---|
788 | The entity-length of a message is the length of the message-body |
---|
789 | before any transfer-codings have been applied. Section 3.4 of <xref target="Part1"/> defines |
---|
790 | how the transfer-length of a message-body is determined. |
---|
791 | </t> |
---|
792 | </section> |
---|
793 | </section> |
---|
794 | </section> |
---|
795 | |
---|
796 | <section title="Content Negotiation" anchor="content.negotiation"> |
---|
797 | <t> |
---|
798 | HTTP responses include a representation which contains information for |
---|
799 | interpretation, whether by a human user or for further processing. |
---|
800 | Often, the server has different ways of representing the |
---|
801 | same information; for example, in different formats, languages, |
---|
802 | or using different character encodings. |
---|
803 | </t> |
---|
804 | <t> |
---|
805 | HTTP clients and their users might have different or variable |
---|
806 | capabilities, characteristics or preferences which would influence |
---|
807 | which representation, among those available from the server, |
---|
808 | would be best for the server to deliver. For this reason, HTTP |
---|
809 | provides mechanisms for "content negotiation" -- a process of |
---|
810 | allowing selection of a representation of a given resource, |
---|
811 | when more than one is available. |
---|
812 | </t> |
---|
813 | <t> |
---|
814 | This specification defines two patterns of content negotiation; |
---|
815 | "server-driven", where the server selects the representation based |
---|
816 | upon the client's stated preferences, and "agent-driven" negotiation, |
---|
817 | where the server provides a list of representations for the client to |
---|
818 | choose from, based upon their metadata. In addition, there are |
---|
819 | other patterns: some applications use an "active content" pattern, |
---|
820 | where the server returns active content which runs on the client |
---|
821 | and, based on client available parameters, selects additional |
---|
822 | resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>) |
---|
823 | has also been proposed. |
---|
824 | </t> |
---|
825 | <t> |
---|
826 | These patterns are all widely used, and have trade-offs in applicability |
---|
827 | and practicality. In particular, when the number of preferences or |
---|
828 | capabilities to be expressed by a client are large (such as when many |
---|
829 | different formats are supported by a user-agent), server-driven |
---|
830 | negotiation becomes unwieldy, and may not be appropriate. Conversely, |
---|
831 | when the number of representations to choose from is very large, |
---|
832 | agent-driven negotiation may not be appropriate. |
---|
833 | </t> |
---|
834 | <t> |
---|
835 | Note that in all cases, the supplier of representations has the |
---|
836 | responsibility for determining which representations might be |
---|
837 | considered to be the "same information". |
---|
838 | </t> |
---|
839 | |
---|
840 | <section title="Server-driven Negotiation" anchor="server-driven.negotiation"> |
---|
841 | <t> |
---|
842 | If the selection of the best representation for a response is made by |
---|
843 | an algorithm located at the server, it is called server-driven |
---|
844 | negotiation. Selection is based on the available representations of |
---|
845 | the response (the dimensions over which it can vary; e.g., language, |
---|
846 | content-coding, etc.) and the contents of particular header fields in |
---|
847 | the request message or on other information pertaining to the request |
---|
848 | (such as the network address of the client). |
---|
849 | </t> |
---|
850 | <t> |
---|
851 | Server-driven negotiation is advantageous when the algorithm for |
---|
852 | selecting from among the available representations is difficult to |
---|
853 | describe to the user agent, or when the server desires to send its |
---|
854 | "best guess" to the client along with the first response (hoping to |
---|
855 | avoid the round-trip delay of a subsequent request if the "best |
---|
856 | guess" is good enough for the user). In order to improve the server's |
---|
857 | guess, the user agent MAY include request header fields (Accept, |
---|
858 | Accept-Language, Accept-Encoding, etc.) which describe its |
---|
859 | preferences for such a response. |
---|
860 | </t> |
---|
861 | <t> |
---|
862 | Server-driven negotiation has disadvantages: |
---|
863 | <list style="numbers"> |
---|
864 | <t> |
---|
865 | It is impossible for the server to accurately determine what |
---|
866 | might be "best" for any given user, since that would require |
---|
867 | complete knowledge of both the capabilities of the user agent |
---|
868 | and the intended use for the response (e.g., does the user want |
---|
869 | to view it on screen or print it on paper?). |
---|
870 | </t> |
---|
871 | <t> |
---|
872 | Having the user agent describe its capabilities in every |
---|
873 | request can be both very inefficient (given that only a small |
---|
874 | percentage of responses have multiple representations) and a |
---|
875 | potential violation of the user's privacy. |
---|
876 | </t> |
---|
877 | <t> |
---|
878 | It complicates the implementation of an origin server and the |
---|
879 | algorithms for generating responses to a request. |
---|
880 | </t> |
---|
881 | <t> |
---|
882 | It may limit a public cache's ability to use the same response |
---|
883 | for multiple user's requests. |
---|
884 | </t> |
---|
885 | </list> |
---|
886 | </t> |
---|
887 | <t> |
---|
888 | HTTP/1.1 includes the following request-header fields for enabling |
---|
889 | server-driven negotiation through description of user agent |
---|
890 | capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset |
---|
891 | (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language |
---|
892 | (<xref target="header.accept-language"/>), and User-Agent (Section 9.9 of <xref target="Part2"/>). |
---|
893 | However, an origin server is not limited to these dimensions and MAY vary |
---|
894 | the response based on any aspect of the request, including information |
---|
895 | outside the request-header fields or within extension header fields |
---|
896 | not defined by this specification. |
---|
897 | </t> |
---|
898 | <t><list> |
---|
899 | <t> |
---|
900 | Note: In practice, User-Agent based negotiation is fragile, |
---|
901 | because new clients might not be recognized. |
---|
902 | </t> |
---|
903 | </list></t> |
---|
904 | <t> |
---|
905 | The Vary header field (Section 3.5 of <xref target="Part6"/>) can be used to express the parameters the |
---|
906 | server uses to select a representation that is subject to server-driven |
---|
907 | negotiation. |
---|
908 | </t> |
---|
909 | </section> |
---|
910 | |
---|
911 | <section title="Agent-driven Negotiation" anchor="agent-driven.negotiation"> |
---|
912 | <t> |
---|
913 | With agent-driven negotiation, selection of the best representation |
---|
914 | for a response is performed by the user agent after receiving an |
---|
915 | initial response from the origin server. Selection is based on a list |
---|
916 | of the available representations of the response included within the |
---|
917 | header fields or entity-body of the initial response, with each |
---|
918 | representation identified by its own URI. Selection from among the |
---|
919 | representations may be performed automatically (if the user agent is |
---|
920 | capable of doing so) or manually by the user selecting from a |
---|
921 | generated (possibly hypertext) menu. |
---|
922 | </t> |
---|
923 | <t> |
---|
924 | Agent-driven negotiation is advantageous when the response would vary |
---|
925 | over commonly-used dimensions (such as type, language, or encoding), |
---|
926 | when the origin server is unable to determine a user agent's |
---|
927 | capabilities from examining the request, and generally when public |
---|
928 | caches are used to distribute server load and reduce network usage. |
---|
929 | </t> |
---|
930 | <t> |
---|
931 | Agent-driven negotiation suffers from the disadvantage of needing a |
---|
932 | second request to obtain the best alternate representation. This |
---|
933 | second request is only efficient when caching is used. In addition, |
---|
934 | this specification does not define any mechanism for supporting |
---|
935 | automatic selection, though it also does not prevent any such |
---|
936 | mechanism from being developed as an extension and used within |
---|
937 | HTTP/1.1. |
---|
938 | </t> |
---|
939 | <t> |
---|
940 | This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) |
---|
941 | status codes for enabling agent-driven negotiation when the server is |
---|
942 | unwilling or unable to provide a varying response using server-driven |
---|
943 | negotiation. |
---|
944 | </t> |
---|
945 | </section> |
---|
946 | </section> |
---|
947 | |
---|
948 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
949 | <t> |
---|
950 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
951 | related to the payload of messages. |
---|
952 | </t> |
---|
953 | <t> |
---|
954 | For entity-header fields, both sender and recipient refer to either the |
---|
955 | client or the server, depending on who sends and who receives the entity. |
---|
956 | </t> |
---|
957 | |
---|
958 | <section title="Accept" anchor="header.accept"> |
---|
959 | <iref primary="true" item="Accept header"/> |
---|
960 | <iref primary="true" item="Headers" subitem="Accept"/> |
---|
961 | |
---|
962 | |
---|
963 | |
---|
964 | |
---|
965 | |
---|
966 | <t> |
---|
967 | The "Accept" request-header field can be used by user agents to specify |
---|
968 | response media types that are acceptable. Accept headers can be used to |
---|
969 | indicate that the request is specifically limited to a small set of desired |
---|
970 | types, as in the case of a request for an in-line image. |
---|
971 | </t> |
---|
972 | <figure><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="Accept-v"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/><artwork type="abnf2616"><![CDATA[ |
---|
973 | Accept = "Accept" ":" OWS Accept-v |
---|
974 | Accept-v = #( media-range [ accept-params ] ) |
---|
975 | |
---|
976 | media-range = ( "*/*" |
---|
977 | / ( type "/" "*" ) |
---|
978 | / ( type "/" subtype ) |
---|
979 | ) *( OWS ";" OWS parameter ) |
---|
980 | accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) |
---|
981 | accept-ext = OWS ";" OWS token |
---|
982 | [ "=" word ] |
---|
983 | ]]></artwork></figure> |
---|
984 | <t> |
---|
985 | The asterisk "*" character is used to group media types into ranges, |
---|
986 | with "*/*" indicating all media types and "type/*" indicating all |
---|
987 | subtypes of that type. The media-range MAY include media type |
---|
988 | parameters that are applicable to that range. |
---|
989 | </t> |
---|
990 | <t> |
---|
991 | Each media-range MAY be followed by one or more accept-params, |
---|
992 | beginning with the "q" parameter for indicating a relative quality |
---|
993 | factor. The first "q" parameter (if any) separates the media-range |
---|
994 | parameter(s) from the accept-params. Quality factors allow the user |
---|
995 | or user agent to indicate the relative degree of preference for that |
---|
996 | media-range, using the qvalue scale from 0 to 1 (Section 6.4 of <xref target="Part1"/>). The |
---|
997 | default value is q=1. |
---|
998 | </t> |
---|
999 | <t><list> |
---|
1000 | <t> |
---|
1001 | Note: Use of the "q" parameter name to separate media type |
---|
1002 | parameters from Accept extension parameters is due to historical |
---|
1003 | practice. Although this prevents any media type parameter named |
---|
1004 | "q" from being used with a media range, such an event is believed |
---|
1005 | to be unlikely given the lack of any "q" parameters in the IANA |
---|
1006 | media type registry and the rare usage of any media type |
---|
1007 | parameters in Accept. Future media types are discouraged from |
---|
1008 | registering any parameter named "q". |
---|
1009 | </t> |
---|
1010 | </list></t> |
---|
1011 | <t> |
---|
1012 | The example |
---|
1013 | </t> |
---|
1014 | <figure><artwork type="example"><![CDATA[ |
---|
1015 | Accept: audio/*; q=0.2, audio/basic |
---|
1016 | ]]></artwork></figure> |
---|
1017 | <t> |
---|
1018 | SHOULD be interpreted as "I prefer audio/basic, but send me any audio |
---|
1019 | type if it is the best available after an 80% mark-down in quality." |
---|
1020 | </t> |
---|
1021 | <t> |
---|
1022 | If no Accept header field is present, then it is assumed that the |
---|
1023 | client accepts all media types. If an Accept header field is present, |
---|
1024 | and if the server cannot send a response which is acceptable |
---|
1025 | according to the combined Accept field value, then the server SHOULD |
---|
1026 | send a 406 (Not Acceptable) response. |
---|
1027 | </t> |
---|
1028 | <t> |
---|
1029 | A more elaborate example is |
---|
1030 | </t> |
---|
1031 | <figure><artwork type="example"><![CDATA[ |
---|
1032 | Accept: text/plain; q=0.5, text/html, |
---|
1033 | text/x-dvi; q=0.8, text/x-c |
---|
1034 | ]]></artwork></figure> |
---|
1035 | <t> |
---|
1036 | Verbally, this would be interpreted as "text/html and text/x-c are |
---|
1037 | the preferred media types, but if they do not exist, then send the |
---|
1038 | text/x-dvi entity, and if that does not exist, send the text/plain |
---|
1039 | entity." |
---|
1040 | </t> |
---|
1041 | <t> |
---|
1042 | Media ranges can be overridden by more specific media ranges or |
---|
1043 | specific media types. If more than one media range applies to a given |
---|
1044 | type, the most specific reference has precedence. For example, |
---|
1045 | </t> |
---|
1046 | <figure><artwork type="example"><![CDATA[ |
---|
1047 | Accept: text/*, text/html, text/html;level=1, */* |
---|
1048 | ]]></artwork></figure> |
---|
1049 | <t> |
---|
1050 | have the following precedence: |
---|
1051 | <list style="numbers"> |
---|
1052 | <t>text/html;level=1</t> |
---|
1053 | <t>text/html</t> |
---|
1054 | <t>text/*</t> |
---|
1055 | <t>*/*</t> |
---|
1056 | </list> |
---|
1057 | </t> |
---|
1058 | <t> |
---|
1059 | The media type quality factor associated with a given type is |
---|
1060 | determined by finding the media range with the highest precedence |
---|
1061 | which matches that type. For example, |
---|
1062 | </t> |
---|
1063 | <figure><artwork type="example"><![CDATA[ |
---|
1064 | Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, |
---|
1065 | text/html;level=2;q=0.4, */*;q=0.5 |
---|
1066 | ]]></artwork></figure> |
---|
1067 | <t> |
---|
1068 | would cause the following values to be associated: |
---|
1069 | </t> |
---|
1070 | <texttable align="left"> |
---|
1071 | <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol> |
---|
1072 | <c>text/html;level=1</c> <c>1</c> |
---|
1073 | <c>text/html</c> <c>0.7</c> |
---|
1074 | <c>text/plain</c> <c>0.3</c> |
---|
1075 | <c>image/jpeg</c> <c>0.5</c> |
---|
1076 | <c>text/html;level=2</c> <c>0.4</c> |
---|
1077 | <c>text/html;level=3</c> <c>0.7</c> |
---|
1078 | </texttable> |
---|
1079 | <t> |
---|
1080 | Note: A user agent might be provided with a default set of quality |
---|
1081 | values for certain media ranges. However, unless the user agent is |
---|
1082 | a closed system which cannot interact with other rendering agents, |
---|
1083 | this default set ought to be configurable by the user. |
---|
1084 | </t> |
---|
1085 | </section> |
---|
1086 | |
---|
1087 | <section title="Accept-Charset" anchor="header.accept-charset"> |
---|
1088 | <iref primary="true" item="Accept-Charset header"/> |
---|
1089 | <iref primary="true" item="Headers" subitem="Accept-Charset"/> |
---|
1090 | |
---|
1091 | |
---|
1092 | <t> |
---|
1093 | The "Accept-Charset" request-header field can be used by user agents to |
---|
1094 | indicate what response character sets are acceptable. This field allows |
---|
1095 | clients capable of understanding more comprehensive or special-purpose |
---|
1096 | character sets to signal that capability to a server which is capable of |
---|
1097 | representing documents in those character sets. |
---|
1098 | </t> |
---|
1099 | <figure><iref primary="true" item="Grammar" subitem="Accept-Charset"/><iref primary="true" item="Grammar" subitem="Accept-Charset-v"/><artwork type="abnf2616"><![CDATA[ |
---|
1100 | Accept-Charset = "Accept-Charset" ":" OWS |
---|
1101 | Accept-Charset-v |
---|
1102 | Accept-Charset-v = 1#( ( charset / "*" ) |
---|
1103 | [ OWS ";" OWS "q=" qvalue ] ) |
---|
1104 | ]]></artwork></figure> |
---|
1105 | <t> |
---|
1106 | Character set values are described in <xref target="character.sets"/>. Each charset MAY |
---|
1107 | be given an associated quality value which represents the user's |
---|
1108 | preference for that charset. The default value is q=1. An example is |
---|
1109 | </t> |
---|
1110 | <figure><artwork type="example"><![CDATA[ |
---|
1111 | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
---|
1112 | ]]></artwork></figure> |
---|
1113 | <t> |
---|
1114 | The special value "*", if present in the Accept-Charset field, |
---|
1115 | matches every character set (including ISO-8859-1) which is not |
---|
1116 | mentioned elsewhere in the Accept-Charset field. If no "*" is present |
---|
1117 | in an Accept-Charset field, then all character sets not explicitly |
---|
1118 | mentioned get a quality value of 0, except for ISO-8859-1, which gets |
---|
1119 | a quality value of 1 if not explicitly mentioned. |
---|
1120 | </t> |
---|
1121 | <t> |
---|
1122 | If no Accept-Charset header is present, the default is that any |
---|
1123 | character set is acceptable. If an Accept-Charset header is present, |
---|
1124 | and if the server cannot send a response which is acceptable |
---|
1125 | according to the Accept-Charset header, then the server SHOULD send |
---|
1126 | an error response with the 406 (Not Acceptable) status code, though |
---|
1127 | the sending of an unacceptable response is also allowed. |
---|
1128 | </t> |
---|
1129 | </section> |
---|
1130 | |
---|
1131 | <section title="Accept-Encoding" anchor="header.accept-encoding"> |
---|
1132 | <iref primary="true" item="Accept-Encoding header"/> |
---|
1133 | <iref primary="true" item="Headers" subitem="Accept-Encoding"/> |
---|
1134 | |
---|
1135 | |
---|
1136 | |
---|
1137 | <t> |
---|
1138 | The "Accept-Encoding" request-header field can be used by user agents to |
---|
1139 | indicate what response content-codings (<xref target="content.codings"/>) |
---|
1140 | are acceptable in the response. |
---|
1141 | </t> |
---|
1142 | <figure><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="Accept-Encoding-v"/><iref primary="true" item="Grammar" subitem="codings"/><artwork type="abnf2616"><![CDATA[ |
---|
1143 | Accept-Encoding = "Accept-Encoding" ":" OWS |
---|
1144 | Accept-Encoding-v |
---|
1145 | Accept-Encoding-v = |
---|
1146 | #( codings [ OWS ";" OWS "q=" qvalue ] ) |
---|
1147 | codings = ( content-coding / "*" ) |
---|
1148 | ]]></artwork></figure> |
---|
1149 | <t> |
---|
1150 | Each codings value MAY be given an associated quality value which |
---|
1151 | represents the preference for that encoding. The default value is q=1. |
---|
1152 | </t> |
---|
1153 | <t> |
---|
1154 | Examples of its use are: |
---|
1155 | </t> |
---|
1156 | <figure><artwork type="example"><![CDATA[ |
---|
1157 | Accept-Encoding: compress, gzip |
---|
1158 | Accept-Encoding: |
---|
1159 | Accept-Encoding: * |
---|
1160 | Accept-Encoding: compress;q=0.5, gzip;q=1.0 |
---|
1161 | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |
---|
1162 | ]]></artwork></figure> |
---|
1163 | <t> |
---|
1164 | A server tests whether a content-coding is acceptable, according to |
---|
1165 | an Accept-Encoding field, using these rules: |
---|
1166 | <list style="numbers"> |
---|
1167 | <t>If the content-coding is one of the content-codings listed in |
---|
1168 | the Accept-Encoding field, then it is acceptable, unless it is |
---|
1169 | accompanied by a qvalue of 0. (As defined in Section 6.4 of <xref target="Part1"/>, a |
---|
1170 | qvalue of 0 means "not acceptable.")</t> |
---|
1171 | |
---|
1172 | <t>The special "*" symbol in an Accept-Encoding field matches any |
---|
1173 | available content-coding not explicitly listed in the header |
---|
1174 | field.</t> |
---|
1175 | |
---|
1176 | <t>If multiple content-codings are acceptable, then the acceptable |
---|
1177 | content-coding with the highest non-zero qvalue is preferred.</t> |
---|
1178 | |
---|
1179 | <t>The "identity" content-coding is always acceptable, unless |
---|
1180 | specifically refused because the Accept-Encoding field includes |
---|
1181 | "identity;q=0", or because the field includes "*;q=0" and does |
---|
1182 | not explicitly include the "identity" content-coding. If the |
---|
1183 | Accept-Encoding field-value is empty, then only the "identity" |
---|
1184 | encoding is acceptable.</t> |
---|
1185 | </list> |
---|
1186 | </t> |
---|
1187 | <t> |
---|
1188 | If an Accept-Encoding field is present in a request, and if the |
---|
1189 | server cannot send a response which is acceptable according to the |
---|
1190 | Accept-Encoding header, then the server SHOULD send an error response |
---|
1191 | with the 406 (Not Acceptable) status code. |
---|
1192 | </t> |
---|
1193 | <t> |
---|
1194 | If no Accept-Encoding field is present in a request, the server MAY |
---|
1195 | assume that the client will accept any content coding. In this case, |
---|
1196 | if "identity" is one of the available content-codings, then the |
---|
1197 | server SHOULD use the "identity" content-coding, unless it has |
---|
1198 | additional information that a different content-coding is meaningful |
---|
1199 | to the client. |
---|
1200 | </t> |
---|
1201 | <t><list> |
---|
1202 | <t> |
---|
1203 | Note: If the request does not include an Accept-Encoding field, |
---|
1204 | and if the "identity" content-coding is unavailable, then |
---|
1205 | content-codings commonly understood by HTTP/1.0 clients (i.e., |
---|
1206 | "gzip" and "compress") are preferred; some older clients |
---|
1207 | improperly display messages sent with other content-codings. The |
---|
1208 | server might also make this decision based on information about |
---|
1209 | the particular user-agent or client. |
---|
1210 | </t> |
---|
1211 | </list></t> |
---|
1212 | <t><list> |
---|
1213 | <t> |
---|
1214 | Note: Most HTTP/1.0 applications do not recognize or obey qvalues |
---|
1215 | associated with content-codings. This means that qvalues will not |
---|
1216 | work and are not permitted with x-gzip or x-compress. |
---|
1217 | </t> |
---|
1218 | </list></t> |
---|
1219 | </section> |
---|
1220 | |
---|
1221 | <section title="Accept-Language" anchor="header.accept-language"> |
---|
1222 | <iref primary="true" item="Accept-Language header"/> |
---|
1223 | <iref primary="true" item="Headers" subitem="Accept-Language"/> |
---|
1224 | |
---|
1225 | |
---|
1226 | |
---|
1227 | <t> |
---|
1228 | The "Accept-Language" request-header field can be used by user agents to |
---|
1229 | indicate the set of natural languages that are preferred in the response. |
---|
1230 | Language tags are defined in <xref target="language.tags"/>. |
---|
1231 | </t> |
---|
1232 | <figure><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="Accept-Language-v"/><iref primary="true" item="Grammar" subitem="language-range"/><artwork type="abnf2616"><![CDATA[ |
---|
1233 | Accept-Language = "Accept-Language" ":" OWS |
---|
1234 | Accept-Language-v |
---|
1235 | Accept-Language-v = |
---|
1236 | 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) |
---|
1237 | language-range = |
---|
1238 | <language-range, defined in [RFC4647], Section 2.1> |
---|
1239 | ]]></artwork></figure> |
---|
1240 | <t> |
---|
1241 | Each language-range can be given an associated quality value which |
---|
1242 | represents an estimate of the user's preference for the languages |
---|
1243 | specified by that range. The quality value defaults to "q=1". For |
---|
1244 | example, |
---|
1245 | </t> |
---|
1246 | <figure><artwork type="example"><![CDATA[ |
---|
1247 | Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
---|
1248 | ]]></artwork></figure> |
---|
1249 | <t> |
---|
1250 | would mean: "I prefer Danish, but will accept British English and |
---|
1251 | other types of English." |
---|
1252 | (see also Section 2.3 of <xref target="RFC4647"/>) |
---|
1253 | </t> |
---|
1254 | <t> |
---|
1255 | For matching, Section 3 of <xref target="RFC4647"/> defines |
---|
1256 | several matching schemes. Implementations can offer the most appropriate |
---|
1257 | matching scheme for their requirements. |
---|
1258 | </t> |
---|
1259 | <t><list> |
---|
1260 | <t> |
---|
1261 | Note: The "Basic Filtering" scheme (<xref target="RFC4647"/>, Section 3.3.1) is identical to the matching scheme that was |
---|
1262 | previously defined in Section 14.4 of <xref target="RFC2616"/>. |
---|
1263 | </t> |
---|
1264 | </list></t> |
---|
1265 | <t> |
---|
1266 | It might be contrary to the privacy expectations of the user to send |
---|
1267 | an Accept-Language header with the complete linguistic preferences of |
---|
1268 | the user in every request. For a discussion of this issue, see |
---|
1269 | <xref target="privacy.issues.connected.to.accept.headers"/>. |
---|
1270 | </t> |
---|
1271 | <t> |
---|
1272 | As intelligibility is highly dependent on the individual user, it is |
---|
1273 | recommended that client applications make the choice of linguistic |
---|
1274 | preference available to the user. If the choice is not made |
---|
1275 | available, then the Accept-Language header field MUST NOT be given in |
---|
1276 | the request. |
---|
1277 | </t> |
---|
1278 | <t><list> |
---|
1279 | <t> |
---|
1280 | Note: When making the choice of linguistic preference available to |
---|
1281 | the user, we remind implementors of the fact that users are not |
---|
1282 | familiar with the details of language matching as described above, |
---|
1283 | and should provide appropriate guidance. As an example, users |
---|
1284 | might assume that on selecting "en-gb", they will be served any |
---|
1285 | kind of English document if British English is not available. A |
---|
1286 | user agent might suggest in such a case to add "en" to get the |
---|
1287 | best matching behavior. |
---|
1288 | </t> |
---|
1289 | </list></t> |
---|
1290 | </section> |
---|
1291 | |
---|
1292 | <section title="Content-Encoding" anchor="header.content-encoding"> |
---|
1293 | <iref primary="true" item="Content-Encoding header"/> |
---|
1294 | <iref primary="true" item="Headers" subitem="Content-Encoding"/> |
---|
1295 | |
---|
1296 | |
---|
1297 | <t> |
---|
1298 | The "Content-Encoding" entity-header field indicates what content-codings |
---|
1299 | have been applied to the entity-body, and thus what decoding mechanisms |
---|
1300 | must be applied in order to obtain the media-type referenced by the |
---|
1301 | Content-Type header field. Content-Encoding is primarily used to allow a |
---|
1302 | document to be compressed without losing the identity of its underlying |
---|
1303 | media type. |
---|
1304 | </t> |
---|
1305 | <figure><iref primary="true" item="Grammar" subitem="Content-Encoding"/><iref primary="true" item="Grammar" subitem="Content-Encoding-v"/><artwork type="abnf2616"><![CDATA[ |
---|
1306 | Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v |
---|
1307 | Content-Encoding-v = 1#content-coding |
---|
1308 | ]]></artwork></figure> |
---|
1309 | <t> |
---|
1310 | Content codings are defined in <xref target="content.codings"/>. An example of its use is |
---|
1311 | </t> |
---|
1312 | <figure><artwork type="example"><![CDATA[ |
---|
1313 | Content-Encoding: gzip |
---|
1314 | ]]></artwork></figure> |
---|
1315 | <t> |
---|
1316 | The content-coding is a characteristic of the entity identified by |
---|
1317 | the Effective Request URI (Section 4.3 of <xref target="Part1"/>). Typically, the entity-body is stored with this |
---|
1318 | encoding and is only decoded before rendering or analogous usage. |
---|
1319 | However, a non-transparent proxy MAY modify the content-coding if the |
---|
1320 | new coding is known to be acceptable to the recipient, unless the |
---|
1321 | "no-transform" cache-control directive is present in the message. |
---|
1322 | </t> |
---|
1323 | <t> |
---|
1324 | If the content-coding of an entity is not "identity", then the |
---|
1325 | response MUST include a Content-Encoding entity-header (<xref target="header.content-encoding"/>) |
---|
1326 | that lists the non-identity content-coding(s) used. |
---|
1327 | </t> |
---|
1328 | <t> |
---|
1329 | If the content-coding of an entity in a request message is not |
---|
1330 | acceptable to the origin server, the server SHOULD respond with a |
---|
1331 | status code of 415 (Unsupported Media Type). |
---|
1332 | </t> |
---|
1333 | <t> |
---|
1334 | If multiple encodings have been applied to an entity, the content |
---|
1335 | codings MUST be listed in the order in which they were applied. |
---|
1336 | Additional information about the encoding parameters MAY be provided |
---|
1337 | by other entity-header fields not defined by this specification. |
---|
1338 | </t> |
---|
1339 | </section> |
---|
1340 | |
---|
1341 | <section title="Content-Language" anchor="header.content-language"> |
---|
1342 | <iref primary="true" item="Content-Language header"/> |
---|
1343 | <iref primary="true" item="Headers" subitem="Content-Language"/> |
---|
1344 | |
---|
1345 | |
---|
1346 | <t> |
---|
1347 | The "Content-Language" entity-header field describes the natural |
---|
1348 | language(s) of the intended audience for the entity. Note that this might |
---|
1349 | not be equivalent to all the languages used within the entity-body. |
---|
1350 | </t> |
---|
1351 | <figure><iref primary="true" item="Grammar" subitem="Content-Language"/><iref primary="true" item="Grammar" subitem="Content-Language-v"/><artwork type="abnf2616"><![CDATA[ |
---|
1352 | Content-Language = "Content-Language" ":" OWS Content-Language-v |
---|
1353 | Content-Language-v = 1#language-tag |
---|
1354 | ]]></artwork></figure> |
---|
1355 | <t> |
---|
1356 | Language tags are defined in <xref target="language.tags"/>. The primary purpose of |
---|
1357 | Content-Language is to allow a user to identify and differentiate |
---|
1358 | entities according to the user's own preferred language. Thus, if the |
---|
1359 | body content is intended only for a Danish-literate audience, the |
---|
1360 | appropriate field is |
---|
1361 | </t> |
---|
1362 | <figure><artwork type="example"><![CDATA[ |
---|
1363 | Content-Language: da |
---|
1364 | ]]></artwork></figure> |
---|
1365 | <t> |
---|
1366 | If no Content-Language is specified, the default is that the content |
---|
1367 | is intended for all language audiences. This might mean that the |
---|
1368 | sender does not consider it to be specific to any natural language, |
---|
1369 | or that the sender does not know for which language it is intended. |
---|
1370 | </t> |
---|
1371 | <t> |
---|
1372 | Multiple languages MAY be listed for content that is intended for |
---|
1373 | multiple audiences. For example, a rendition of the "Treaty of |
---|
1374 | Waitangi," presented simultaneously in the original Maori and English |
---|
1375 | versions, would call for |
---|
1376 | </t> |
---|
1377 | <figure><artwork type="example"><![CDATA[ |
---|
1378 | Content-Language: mi, en |
---|
1379 | ]]></artwork></figure> |
---|
1380 | <t> |
---|
1381 | However, just because multiple languages are present within an entity |
---|
1382 | does not mean that it is intended for multiple linguistic audiences. |
---|
1383 | An example would be a beginner's language primer, such as "A First |
---|
1384 | Lesson in Latin," which is clearly intended to be used by an |
---|
1385 | English-literate audience. In this case, the Content-Language would |
---|
1386 | properly only include "en". |
---|
1387 | </t> |
---|
1388 | <t> |
---|
1389 | Content-Language MAY be applied to any media type -- it is not |
---|
1390 | limited to textual documents. |
---|
1391 | </t> |
---|
1392 | </section> |
---|
1393 | |
---|
1394 | <section title="Content-Location" anchor="header.content-location"> |
---|
1395 | <iref primary="true" item="Content-Location header"/> |
---|
1396 | <iref primary="true" item="Headers" subitem="Content-Location"/> |
---|
1397 | |
---|
1398 | |
---|
1399 | <t> |
---|
1400 | The "Content-Location" entity-header field is used to supply a URI for the |
---|
1401 | entity in the message when it is accessible from a location separate from |
---|
1402 | the requested resource's URI. |
---|
1403 | </t> |
---|
1404 | <t> |
---|
1405 | A server SHOULD provide a Content-Location for the variant corresponding |
---|
1406 | to the response entity, especially in the case where a resource has multiple |
---|
1407 | entities associated with it, and those entities actually have separate |
---|
1408 | locations by which they might be individually accessed, the server SHOULD |
---|
1409 | provide a Content-Location for the particular variant which is returned. |
---|
1410 | </t> |
---|
1411 | <figure><iref primary="true" item="Grammar" subitem="Content-Location"/><iref primary="true" item="Grammar" subitem="Content-Location-v"/><artwork type="abnf2616"><![CDATA[ |
---|
1412 | Content-Location = "Content-Location" ":" OWS |
---|
1413 | Content-Location-v |
---|
1414 | Content-Location-v = |
---|
1415 | absolute-URI / partial-URI |
---|
1416 | ]]></artwork></figure> |
---|
1417 | <t> |
---|
1418 | The Content-Location value is not a replacement for the Effective |
---|
1419 | Request URI (Section 4.3 of <xref target="Part1"/>); it is only a statement of the location of the resource |
---|
1420 | corresponding to this particular entity at the time of the request. |
---|
1421 | Future requests MAY may be addressed to the Content-Location URI |
---|
1422 | if the desire is to identify the source of that particular |
---|
1423 | entity. |
---|
1424 | </t> |
---|
1425 | <t> |
---|
1426 | Section 6.1 of <xref target="Part2"/> describes how clients may process the Content-Location header field. |
---|
1427 | </t> |
---|
1428 | <t> |
---|
1429 | A cache cannot assume that an entity with a Content-Location |
---|
1430 | different from the URI used to retrieve it can be used to respond to |
---|
1431 | later requests on that Content-Location URI. However, the Content-Location |
---|
1432 | can be used to differentiate between multiple entities |
---|
1433 | retrieved from a single requested resource, as described in Section 2.7 of <xref target="Part6"/>. |
---|
1434 | </t> |
---|
1435 | <t> |
---|
1436 | If the Content-Location is a relative URI, the relative URI is |
---|
1437 | interpreted relative to the Effective Request URI. |
---|
1438 | </t> |
---|
1439 | <t> |
---|
1440 | The meaning of the Content-Location header in requests is |
---|
1441 | undefined; servers are free to ignore it in those cases. |
---|
1442 | </t> |
---|
1443 | </section> |
---|
1444 | |
---|
1445 | <section title="Content-MD5" anchor="header.content-md5"> |
---|
1446 | <iref primary="true" item="Content-MD5 header"/> |
---|
1447 | <iref primary="true" item="Headers" subitem="Content-MD5"/> |
---|
1448 | |
---|
1449 | |
---|
1450 | <t> |
---|
1451 | The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is |
---|
1452 | an MD5 digest of the entity-body that provides an end-to-end message |
---|
1453 | integrity check (MIC) of the entity-body. Note that a MIC is good for |
---|
1454 | detecting accidental modification of the entity-body in transit, but is not |
---|
1455 | proof against malicious attacks. |
---|
1456 | </t> |
---|
1457 | <figure><iref primary="true" item="Grammar" subitem="Content-MD5"/><iref primary="true" item="Grammar" subitem="Content-MD5-v"/><artwork type="abnf2616"><![CDATA[ |
---|
1458 | Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v |
---|
1459 | Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> |
---|
1460 | ]]></artwork></figure> |
---|
1461 | <t> |
---|
1462 | The Content-MD5 header field MAY be generated by an origin server or |
---|
1463 | client to function as an integrity check of the entity-body. Only |
---|
1464 | origin servers or clients MAY generate the Content-MD5 header field; |
---|
1465 | proxies and gateways MUST NOT generate it, as this would defeat its |
---|
1466 | value as an end-to-end integrity check. Any recipient of the entity-body, |
---|
1467 | including gateways and proxies, MAY check that the digest value |
---|
1468 | in this header field matches that of the entity-body as received. |
---|
1469 | </t> |
---|
1470 | <t> |
---|
1471 | The MD5 digest is computed based on the content of the entity-body, |
---|
1472 | including any content-coding that has been applied, but not including |
---|
1473 | any transfer-encoding applied to the message-body. If the message is |
---|
1474 | received with a transfer-encoding, that encoding MUST be removed |
---|
1475 | prior to checking the Content-MD5 value against the received entity. |
---|
1476 | </t> |
---|
1477 | <t> |
---|
1478 | This has the result that the digest is computed on the octets of the |
---|
1479 | entity-body exactly as, and in the order that, they would be sent if |
---|
1480 | no transfer-encoding were being applied. |
---|
1481 | </t> |
---|
1482 | <t> |
---|
1483 | HTTP extends RFC 1864 to permit the digest to be computed for MIME |
---|
1484 | composite media-types (e.g., multipart/* and message/rfc822), but |
---|
1485 | this does not change how the digest is computed as defined in the |
---|
1486 | preceding paragraph. |
---|
1487 | </t> |
---|
1488 | <t> |
---|
1489 | There are several consequences of this. The entity-body for composite |
---|
1490 | types MAY contain many body-parts, each with its own MIME and HTTP |
---|
1491 | headers (including Content-MD5, Content-Transfer-Encoding, and |
---|
1492 | Content-Encoding headers). If a body-part has a Content-Transfer-Encoding |
---|
1493 | or Content-Encoding header, it is assumed that the content |
---|
1494 | of the body-part has had the encoding applied, and the body-part is |
---|
1495 | included in the Content-MD5 digest as is -- i.e., after the |
---|
1496 | application. The Transfer-Encoding header field is not allowed within |
---|
1497 | body-parts. |
---|
1498 | </t> |
---|
1499 | <t> |
---|
1500 | Conversion of all line breaks to CRLF MUST NOT be done before |
---|
1501 | computing or checking the digest: the line break convention used in |
---|
1502 | the text actually transmitted MUST be left unaltered when computing |
---|
1503 | the digest. |
---|
1504 | </t> |
---|
1505 | <t><list> |
---|
1506 | <t> |
---|
1507 | Note: While the definition of Content-MD5 is exactly the same for |
---|
1508 | HTTP as in RFC 1864 for MIME entity-bodies, there are several ways |
---|
1509 | in which the application of Content-MD5 to HTTP entity-bodies |
---|
1510 | differs from its application to MIME entity-bodies. One is that |
---|
1511 | HTTP, unlike MIME, does not use Content-Transfer-Encoding, and |
---|
1512 | does use Transfer-Encoding and Content-Encoding. Another is that |
---|
1513 | HTTP more frequently uses binary content types than MIME, so it is |
---|
1514 | worth noting that, in such cases, the byte order used to compute |
---|
1515 | the digest is the transmission byte order defined for the type. |
---|
1516 | Lastly, HTTP allows transmission of text types with any of several |
---|
1517 | line break conventions and not just the canonical form using CRLF. |
---|
1518 | </t> |
---|
1519 | </list></t> |
---|
1520 | </section> |
---|
1521 | |
---|
1522 | <section title="Content-Type" anchor="header.content-type"> |
---|
1523 | <iref primary="true" item="Content-Type header"/> |
---|
1524 | <iref primary="true" item="Headers" subitem="Content-Type"/> |
---|
1525 | |
---|
1526 | |
---|
1527 | <t> |
---|
1528 | The "Content-Type" entity-header field indicates the media type of the |
---|
1529 | entity-body. In the case of responses to the HEAD method, the media type is |
---|
1530 | that which would have been sent had the request been a GET. |
---|
1531 | </t> |
---|
1532 | <figure><iref primary="true" item="Grammar" subitem="Content-Type"/><iref primary="true" item="Grammar" subitem="Content-Type-v"/><artwork type="abnf2616"><![CDATA[ |
---|
1533 | Content-Type = "Content-Type" ":" OWS Content-Type-v |
---|
1534 | Content-Type-v = media-type |
---|
1535 | ]]></artwork></figure> |
---|
1536 | <t> |
---|
1537 | Media types are defined in <xref target="media.types"/>. An example of the field is |
---|
1538 | </t> |
---|
1539 | <figure><artwork type="example"><![CDATA[ |
---|
1540 | Content-Type: text/html; charset=ISO-8859-4 |
---|
1541 | ]]></artwork></figure> |
---|
1542 | <t> |
---|
1543 | Further discussion of methods for identifying the media type of an |
---|
1544 | entity is provided in <xref target="type"/>. |
---|
1545 | </t> |
---|
1546 | </section> |
---|
1547 | |
---|
1548 | </section> |
---|
1549 | |
---|
1550 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
1551 | <section title="Message Header Registration" anchor="message.header.registration"> |
---|
1552 | <t> |
---|
1553 | The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated |
---|
1554 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
1555 | </t> |
---|
1556 | |
---|
1557 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
1558 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
1559 | <ttcol>Header Field Name</ttcol> |
---|
1560 | <ttcol>Protocol</ttcol> |
---|
1561 | <ttcol>Status</ttcol> |
---|
1562 | <ttcol>Reference</ttcol> |
---|
1563 | |
---|
1564 | <c>Accept</c> |
---|
1565 | <c>http</c> |
---|
1566 | <c>standard</c> |
---|
1567 | <c> |
---|
1568 | <xref target="header.accept"/> |
---|
1569 | </c> |
---|
1570 | <c>Accept-Charset</c> |
---|
1571 | <c>http</c> |
---|
1572 | <c>standard</c> |
---|
1573 | <c> |
---|
1574 | <xref target="header.accept-charset"/> |
---|
1575 | </c> |
---|
1576 | <c>Accept-Encoding</c> |
---|
1577 | <c>http</c> |
---|
1578 | <c>standard</c> |
---|
1579 | <c> |
---|
1580 | <xref target="header.accept-encoding"/> |
---|
1581 | </c> |
---|
1582 | <c>Accept-Language</c> |
---|
1583 | <c>http</c> |
---|
1584 | <c>standard</c> |
---|
1585 | <c> |
---|
1586 | <xref target="header.accept-language"/> |
---|
1587 | </c> |
---|
1588 | <c>Content-Disposition</c> |
---|
1589 | <c>http</c> |
---|
1590 | <c/> |
---|
1591 | <c> |
---|
1592 | <xref target="content-disposition"/> |
---|
1593 | </c> |
---|
1594 | <c>Content-Encoding</c> |
---|
1595 | <c>http</c> |
---|
1596 | <c>standard</c> |
---|
1597 | <c> |
---|
1598 | <xref target="header.content-encoding"/> |
---|
1599 | </c> |
---|
1600 | <c>Content-Language</c> |
---|
1601 | <c>http</c> |
---|
1602 | <c>standard</c> |
---|
1603 | <c> |
---|
1604 | <xref target="header.content-language"/> |
---|
1605 | </c> |
---|
1606 | <c>Content-Location</c> |
---|
1607 | <c>http</c> |
---|
1608 | <c>standard</c> |
---|
1609 | <c> |
---|
1610 | <xref target="header.content-location"/> |
---|
1611 | </c> |
---|
1612 | <c>Content-MD5</c> |
---|
1613 | <c>http</c> |
---|
1614 | <c>standard</c> |
---|
1615 | <c> |
---|
1616 | <xref target="header.content-md5"/> |
---|
1617 | </c> |
---|
1618 | <c>Content-Type</c> |
---|
1619 | <c>http</c> |
---|
1620 | <c>standard</c> |
---|
1621 | <c> |
---|
1622 | <xref target="header.content-type"/> |
---|
1623 | </c> |
---|
1624 | <c>MIME-Version</c> |
---|
1625 | <c>http</c> |
---|
1626 | <c/> |
---|
1627 | <c> |
---|
1628 | <xref target="mime-version"/> |
---|
1629 | </c> |
---|
1630 | </texttable> |
---|
1631 | <!--(END)--> |
---|
1632 | |
---|
1633 | <t> |
---|
1634 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
1635 | </t> |
---|
1636 | </section> |
---|
1637 | |
---|
1638 | <section title="Content Coding Registry" anchor="content.coding.registration"> |
---|
1639 | <t> |
---|
1640 | The registration procedure for HTTP Content Codings is now defined |
---|
1641 | by <xref target="content.coding.registry"/> of this document. |
---|
1642 | </t> |
---|
1643 | <t> |
---|
1644 | The HTTP Content Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/> |
---|
1645 | should be updated with the registration below: |
---|
1646 | </t> |
---|
1647 | <texttable align="left" suppress-title="true" anchor="iana.content.coding.registration.table"> |
---|
1648 | <ttcol>Name</ttcol> |
---|
1649 | <ttcol>Description</ttcol> |
---|
1650 | <ttcol>Reference</ttcol> |
---|
1651 | <c>compress</c> |
---|
1652 | <c>UNIX "compress" program method</c> |
---|
1653 | <c> |
---|
1654 | Section 6.2.2.1 of <xref target="Part1"/> |
---|
1655 | </c> |
---|
1656 | <c>deflate</c> |
---|
1657 | <c>"deflate" compression mechanism (<xref target="RFC1951"/>) used inside |
---|
1658 | the "zlib" data format (<xref target="RFC1950"/>) |
---|
1659 | </c> |
---|
1660 | <c> |
---|
1661 | Section 6.2.2.2 of <xref target="Part1"/> |
---|
1662 | </c> |
---|
1663 | <c>gzip</c> |
---|
1664 | <c>Same as GNU zip <xref target="RFC1952"/></c> |
---|
1665 | <c> |
---|
1666 | Section 6.2.2.3 of <xref target="Part1"/> |
---|
1667 | </c> |
---|
1668 | <c>identity</c> |
---|
1669 | <c>No transformation</c> |
---|
1670 | <c> |
---|
1671 | <xref target="content.codings"/> |
---|
1672 | </c> |
---|
1673 | </texttable> |
---|
1674 | </section> |
---|
1675 | |
---|
1676 | </section> |
---|
1677 | |
---|
1678 | <section title="Security Considerations" anchor="security.considerations"> |
---|
1679 | <t> |
---|
1680 | This section is meant to inform application developers, information |
---|
1681 | providers, and users of the security limitations in HTTP/1.1 as |
---|
1682 | described by this document. The discussion does not include |
---|
1683 | definitive solutions to the problems revealed, though it does make |
---|
1684 | some suggestions for reducing security risks. |
---|
1685 | </t> |
---|
1686 | |
---|
1687 | <section title="Privacy Issues Connected to Accept Headers" anchor="privacy.issues.connected.to.accept.headers"> |
---|
1688 | <t> |
---|
1689 | Accept request-headers can reveal information about the user to all |
---|
1690 | servers which are accessed. The Accept-Language header in particular |
---|
1691 | can reveal information the user would consider to be of a private |
---|
1692 | nature, because the understanding of particular languages is often |
---|
1693 | strongly correlated to the membership of a particular ethnic group. |
---|
1694 | User agents which offer the option to configure the contents of an |
---|
1695 | Accept-Language header to be sent in every request are strongly |
---|
1696 | encouraged to let the configuration process include a message which |
---|
1697 | makes the user aware of the loss of privacy involved. |
---|
1698 | </t> |
---|
1699 | <t> |
---|
1700 | An approach that limits the loss of privacy would be for a user agent |
---|
1701 | to omit the sending of Accept-Language headers by default, and to ask |
---|
1702 | the user whether or not to start sending Accept-Language headers to a |
---|
1703 | server if it detects, by looking for any Vary response-header fields |
---|
1704 | generated by the server, that such sending could improve the quality |
---|
1705 | of service. |
---|
1706 | </t> |
---|
1707 | <t> |
---|
1708 | Elaborate user-customized accept header fields sent in every request, |
---|
1709 | in particular if these include quality values, can be used by servers |
---|
1710 | as relatively reliable and long-lived user identifiers. Such user |
---|
1711 | identifiers would allow content providers to do click-trail tracking, |
---|
1712 | and would allow collaborating content providers to match cross-server |
---|
1713 | click-trails or form submissions of individual users. Note that for |
---|
1714 | many users not behind a proxy, the network address of the host |
---|
1715 | running the user agent will also serve as a long-lived user |
---|
1716 | identifier. In environments where proxies are used to enhance |
---|
1717 | privacy, user agents ought to be conservative in offering accept |
---|
1718 | header configuration options to end users. As an extreme privacy |
---|
1719 | measure, proxies could filter the accept headers in relayed requests. |
---|
1720 | General purpose user agents which provide a high degree of header |
---|
1721 | configurability SHOULD warn users about the loss of privacy which can |
---|
1722 | be involved. |
---|
1723 | </t> |
---|
1724 | </section> |
---|
1725 | |
---|
1726 | <section title="Content-Disposition Issues" anchor="content-disposition.issues"> |
---|
1727 | <t> |
---|
1728 | <xref target="RFC2183"/>, from which the often implemented Content-Disposition |
---|
1729 | (see <xref target="content-disposition"/>) header in HTTP is derived, has a number of very |
---|
1730 | serious security considerations. Content-Disposition is not part of |
---|
1731 | the HTTP standard, but since it is widely implemented, we are |
---|
1732 | documenting its use and risks for implementors. See Section 5 of <xref target="RFC2183"/> |
---|
1733 | for details. |
---|
1734 | </t> |
---|
1735 | </section> |
---|
1736 | |
---|
1737 | </section> |
---|
1738 | |
---|
1739 | <section title="Acknowledgments" anchor="ack"> |
---|
1740 | </section> |
---|
1741 | </middle> |
---|
1742 | <back> |
---|
1743 | |
---|
1744 | <references title="Normative References"> |
---|
1745 | |
---|
1746 | <reference anchor="ISO-8859-1"> |
---|
1747 | <front> |
---|
1748 | <title> |
---|
1749 | Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1 |
---|
1750 | </title> |
---|
1751 | <author> |
---|
1752 | <organization>International Organization for Standardization</organization> |
---|
1753 | </author> |
---|
1754 | <date year="1998"/> |
---|
1755 | </front> |
---|
1756 | <seriesInfo name="ISO/IEC" value="8859-1:1998"/> |
---|
1757 | </reference> |
---|
1758 | |
---|
1759 | <reference anchor="Part1"> |
---|
1760 | <front> |
---|
1761 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
1762 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
1763 | <organization abbrev="Day Software">Day Software</organization> |
---|
1764 | <address><email>fielding@gbiv.com</email></address> |
---|
1765 | </author> |
---|
1766 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
1767 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
1768 | <address><email>jg@freedesktop.org</email></address> |
---|
1769 | </author> |
---|
1770 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
1771 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
1772 | <address><email>JeffMogul@acm.org</email></address> |
---|
1773 | </author> |
---|
1774 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
1775 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1776 | <address><email>henrikn@microsoft.com</email></address> |
---|
1777 | </author> |
---|
1778 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
1779 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
1780 | <address><email>LMM@acm.org</email></address> |
---|
1781 | </author> |
---|
1782 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
1783 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1784 | <address><email>paulle@microsoft.com</email></address> |
---|
1785 | </author> |
---|
1786 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
1787 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
1788 | <address><email>timbl@w3.org</email></address> |
---|
1789 | </author> |
---|
1790 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1791 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1792 | <address><email>ylafon@w3.org</email></address> |
---|
1793 | </author> |
---|
1794 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1795 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1796 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1797 | </author> |
---|
1798 | <date month="July" year="2010"/> |
---|
1799 | </front> |
---|
1800 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-10"/> |
---|
1801 | |
---|
1802 | </reference> |
---|
1803 | |
---|
1804 | <reference anchor="Part2"> |
---|
1805 | <front> |
---|
1806 | <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title> |
---|
1807 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
1808 | <organization abbrev="Day Software">Day Software</organization> |
---|
1809 | <address><email>fielding@gbiv.com</email></address> |
---|
1810 | </author> |
---|
1811 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
1812 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
1813 | <address><email>jg@freedesktop.org</email></address> |
---|
1814 | </author> |
---|
1815 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
1816 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
1817 | <address><email>JeffMogul@acm.org</email></address> |
---|
1818 | </author> |
---|
1819 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
1820 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1821 | <address><email>henrikn@microsoft.com</email></address> |
---|
1822 | </author> |
---|
1823 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
1824 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
1825 | <address><email>LMM@acm.org</email></address> |
---|
1826 | </author> |
---|
1827 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
1828 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1829 | <address><email>paulle@microsoft.com</email></address> |
---|
1830 | </author> |
---|
1831 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
1832 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
1833 | <address><email>timbl@w3.org</email></address> |
---|
1834 | </author> |
---|
1835 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1836 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1837 | <address><email>ylafon@w3.org</email></address> |
---|
1838 | </author> |
---|
1839 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1840 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1841 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1842 | </author> |
---|
1843 | <date month="July" year="2010"/> |
---|
1844 | </front> |
---|
1845 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-10"/> |
---|
1846 | |
---|
1847 | </reference> |
---|
1848 | |
---|
1849 | <reference anchor="Part4"> |
---|
1850 | <front> |
---|
1851 | <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> |
---|
1852 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
1853 | <organization abbrev="Day Software">Day Software</organization> |
---|
1854 | <address><email>fielding@gbiv.com</email></address> |
---|
1855 | </author> |
---|
1856 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
1857 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
1858 | <address><email>jg@freedesktop.org</email></address> |
---|
1859 | </author> |
---|
1860 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
1861 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
1862 | <address><email>JeffMogul@acm.org</email></address> |
---|
1863 | </author> |
---|
1864 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
1865 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1866 | <address><email>henrikn@microsoft.com</email></address> |
---|
1867 | </author> |
---|
1868 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
1869 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
1870 | <address><email>LMM@acm.org</email></address> |
---|
1871 | </author> |
---|
1872 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
1873 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1874 | <address><email>paulle@microsoft.com</email></address> |
---|
1875 | </author> |
---|
1876 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
1877 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
1878 | <address><email>timbl@w3.org</email></address> |
---|
1879 | </author> |
---|
1880 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1881 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1882 | <address><email>ylafon@w3.org</email></address> |
---|
1883 | </author> |
---|
1884 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1885 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1886 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1887 | </author> |
---|
1888 | <date month="July" year="2010"/> |
---|
1889 | </front> |
---|
1890 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-10"/> |
---|
1891 | |
---|
1892 | </reference> |
---|
1893 | |
---|
1894 | <reference anchor="Part5"> |
---|
1895 | <front> |
---|
1896 | <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
1897 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
1898 | <organization abbrev="Day Software">Day Software</organization> |
---|
1899 | <address><email>fielding@gbiv.com</email></address> |
---|
1900 | </author> |
---|
1901 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
1902 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
1903 | <address><email>jg@freedesktop.org</email></address> |
---|
1904 | </author> |
---|
1905 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
1906 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
1907 | <address><email>JeffMogul@acm.org</email></address> |
---|
1908 | </author> |
---|
1909 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
1910 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1911 | <address><email>henrikn@microsoft.com</email></address> |
---|
1912 | </author> |
---|
1913 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
1914 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
1915 | <address><email>LMM@acm.org</email></address> |
---|
1916 | </author> |
---|
1917 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
1918 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1919 | <address><email>paulle@microsoft.com</email></address> |
---|
1920 | </author> |
---|
1921 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
1922 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
1923 | <address><email>timbl@w3.org</email></address> |
---|
1924 | </author> |
---|
1925 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1926 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1927 | <address><email>ylafon@w3.org</email></address> |
---|
1928 | </author> |
---|
1929 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1930 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1931 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1932 | </author> |
---|
1933 | <date month="July" year="2010"/> |
---|
1934 | </front> |
---|
1935 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-10"/> |
---|
1936 | |
---|
1937 | </reference> |
---|
1938 | |
---|
1939 | <reference anchor="Part6"> |
---|
1940 | <front> |
---|
1941 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
1942 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
1943 | <organization abbrev="Day Software">Day Software</organization> |
---|
1944 | <address><email>fielding@gbiv.com</email></address> |
---|
1945 | </author> |
---|
1946 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
1947 | <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization> |
---|
1948 | <address><email>jg@freedesktop.org</email></address> |
---|
1949 | </author> |
---|
1950 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
1951 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
1952 | <address><email>JeffMogul@acm.org</email></address> |
---|
1953 | </author> |
---|
1954 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
1955 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1956 | <address><email>henrikn@microsoft.com</email></address> |
---|
1957 | </author> |
---|
1958 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
1959 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
1960 | <address><email>LMM@acm.org</email></address> |
---|
1961 | </author> |
---|
1962 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
1963 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
1964 | <address><email>paulle@microsoft.com</email></address> |
---|
1965 | </author> |
---|
1966 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
1967 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
1968 | <address><email>timbl@w3.org</email></address> |
---|
1969 | </author> |
---|
1970 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1971 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1972 | <address><email>ylafon@w3.org</email></address> |
---|
1973 | </author> |
---|
1974 | <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> |
---|
1975 | <address><email>mnot@mnot.net</email></address> |
---|
1976 | </author> |
---|
1977 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1978 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1979 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1980 | </author> |
---|
1981 | <date month="July" year="2010"/> |
---|
1982 | </front> |
---|
1983 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-10"/> |
---|
1984 | |
---|
1985 | </reference> |
---|
1986 | |
---|
1987 | <reference anchor="RFC1864"> |
---|
1988 | <front> |
---|
1989 | <title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title> |
---|
1990 | <author initials="J." surname="Myers" fullname="John G. Myers"> |
---|
1991 | <organization>Carnegie Mellon University</organization> |
---|
1992 | <address><email>jgm+@cmu.edu</email></address> |
---|
1993 | </author> |
---|
1994 | <author initials="M." surname="Rose" fullname="Marshall T. Rose"> |
---|
1995 | <organization>Dover Beach Consulting, Inc.</organization> |
---|
1996 | <address><email>mrose@dbc.mtview.ca.us</email></address> |
---|
1997 | </author> |
---|
1998 | <date month="October" year="1995"/> |
---|
1999 | </front> |
---|
2000 | <seriesInfo name="RFC" value="1864"/> |
---|
2001 | </reference> |
---|
2002 | |
---|
2003 | <reference anchor="RFC1950"> |
---|
2004 | <front> |
---|
2005 | <title>ZLIB Compressed Data Format Specification version 3.3</title> |
---|
2006 | <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
2007 | <organization>Aladdin Enterprises</organization> |
---|
2008 | <address><email>ghost@aladdin.com</email></address> |
---|
2009 | </author> |
---|
2010 | <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"/> |
---|
2011 | <date month="May" year="1996"/> |
---|
2012 | </front> |
---|
2013 | <seriesInfo name="RFC" value="1950"/> |
---|
2014 | <annotation> |
---|
2015 | RFC 1950 is an Informational RFC, thus it may be less stable than |
---|
2016 | this specification. On the other hand, this downward reference was |
---|
2017 | present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>), |
---|
2018 | therefore it is unlikely to cause problems in practice. See also |
---|
2019 | <xref target="BCP97"/>. |
---|
2020 | </annotation> |
---|
2021 | </reference> |
---|
2022 | |
---|
2023 | <reference anchor="RFC1951"> |
---|
2024 | <front> |
---|
2025 | <title>DEFLATE Compressed Data Format Specification version 1.3</title> |
---|
2026 | <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
2027 | <organization>Aladdin Enterprises</organization> |
---|
2028 | <address><email>ghost@aladdin.com</email></address> |
---|
2029 | </author> |
---|
2030 | <date month="May" year="1996"/> |
---|
2031 | </front> |
---|
2032 | <seriesInfo name="RFC" value="1951"/> |
---|
2033 | <annotation> |
---|
2034 | RFC 1951 is an Informational RFC, thus it may be less stable than |
---|
2035 | this specification. On the other hand, this downward reference was |
---|
2036 | present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>), |
---|
2037 | therefore it is unlikely to cause problems in practice. See also |
---|
2038 | <xref target="BCP97"/>. |
---|
2039 | </annotation> |
---|
2040 | </reference> |
---|
2041 | |
---|
2042 | <reference anchor="RFC1952"> |
---|
2043 | <front> |
---|
2044 | <title>GZIP file format specification version 4.3</title> |
---|
2045 | <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
2046 | <organization>Aladdin Enterprises</organization> |
---|
2047 | <address><email>ghost@aladdin.com</email></address> |
---|
2048 | </author> |
---|
2049 | <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"> |
---|
2050 | <address><email>gzip@prep.ai.mit.edu</email></address> |
---|
2051 | </author> |
---|
2052 | <author initials="M." surname="Adler" fullname="Mark Adler"> |
---|
2053 | <address><email>madler@alumni.caltech.edu</email></address> |
---|
2054 | </author> |
---|
2055 | <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> |
---|
2056 | <address><email>ghost@aladdin.com</email></address> |
---|
2057 | </author> |
---|
2058 | <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson"> |
---|
2059 | <address><email>randeg@alumni.rpi.edu</email></address> |
---|
2060 | </author> |
---|
2061 | <date month="May" year="1996"/> |
---|
2062 | </front> |
---|
2063 | <seriesInfo name="RFC" value="1952"/> |
---|
2064 | <annotation> |
---|
2065 | RFC 1952 is an Informational RFC, thus it may be less stable than |
---|
2066 | this specification. On the other hand, this downward reference was |
---|
2067 | present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>), |
---|
2068 | therefore it is unlikely to cause problems in practice. See also |
---|
2069 | <xref target="BCP97"/>. |
---|
2070 | </annotation> |
---|
2071 | </reference> |
---|
2072 | |
---|
2073 | <reference anchor="RFC2045"> |
---|
2074 | <front> |
---|
2075 | <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> |
---|
2076 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
2077 | <organization>Innosoft International, Inc.</organization> |
---|
2078 | <address><email>ned@innosoft.com</email></address> |
---|
2079 | </author> |
---|
2080 | <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
2081 | <organization>First Virtual Holdings</organization> |
---|
2082 | <address><email>nsb@nsb.fv.com</email></address> |
---|
2083 | </author> |
---|
2084 | <date month="November" year="1996"/> |
---|
2085 | </front> |
---|
2086 | <seriesInfo name="RFC" value="2045"/> |
---|
2087 | </reference> |
---|
2088 | |
---|
2089 | <reference anchor="RFC2046"> |
---|
2090 | <front> |
---|
2091 | <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> |
---|
2092 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
2093 | <organization>Innosoft International, Inc.</organization> |
---|
2094 | <address><email>ned@innosoft.com</email></address> |
---|
2095 | </author> |
---|
2096 | <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
2097 | <organization>First Virtual Holdings</organization> |
---|
2098 | <address><email>nsb@nsb.fv.com</email></address> |
---|
2099 | </author> |
---|
2100 | <date month="November" year="1996"/> |
---|
2101 | </front> |
---|
2102 | <seriesInfo name="RFC" value="2046"/> |
---|
2103 | </reference> |
---|
2104 | |
---|
2105 | <reference anchor="RFC2119"> |
---|
2106 | <front> |
---|
2107 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
2108 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
2109 | <organization>Harvard University</organization> |
---|
2110 | <address><email>sob@harvard.edu</email></address> |
---|
2111 | </author> |
---|
2112 | <date month="March" year="1997"/> |
---|
2113 | </front> |
---|
2114 | <seriesInfo name="BCP" value="14"/> |
---|
2115 | <seriesInfo name="RFC" value="2119"/> |
---|
2116 | </reference> |
---|
2117 | |
---|
2118 | <reference anchor="RFC4647"> |
---|
2119 | <front> |
---|
2120 | <title>Matching of Language Tags</title> |
---|
2121 | <author initials="A." surname="Phillips" fullname="Addison Phillips" role="editor"> |
---|
2122 | <organization>Yahoo! Inc.</organization> |
---|
2123 | <address><email>addison@inter-locale.com</email></address> |
---|
2124 | </author> |
---|
2125 | <author initials="M." surname="Davis" fullname="Mark Davis" role="editor"> |
---|
2126 | <organization>Google</organization> |
---|
2127 | <address><email>mark.davis@macchiato.com</email></address> |
---|
2128 | </author> |
---|
2129 | <date year="2006" month="September"/> |
---|
2130 | </front> |
---|
2131 | <seriesInfo name="BCP" value="47"/> |
---|
2132 | <seriesInfo name="RFC" value="4647"/> |
---|
2133 | </reference> |
---|
2134 | |
---|
2135 | <reference anchor="RFC5234"> |
---|
2136 | <front> |
---|
2137 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
2138 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
2139 | <organization>Brandenburg InternetWorking</organization> |
---|
2140 | <address> |
---|
2141 | <email>dcrocker@bbiw.net</email> |
---|
2142 | </address> |
---|
2143 | </author> |
---|
2144 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
2145 | <organization>THUS plc.</organization> |
---|
2146 | <address> |
---|
2147 | <email>paul.overell@thus.net</email> |
---|
2148 | </address> |
---|
2149 | </author> |
---|
2150 | <date month="January" year="2008"/> |
---|
2151 | </front> |
---|
2152 | <seriesInfo name="STD" value="68"/> |
---|
2153 | <seriesInfo name="RFC" value="5234"/> |
---|
2154 | </reference> |
---|
2155 | |
---|
2156 | <reference anchor="RFC5646"> |
---|
2157 | <front> |
---|
2158 | <title>Tags for Identifying Languages</title> |
---|
2159 | <author initials="A." surname="Phillips" fullname="Addison Phillips" role="editor"> |
---|
2160 | <organization>Lab126</organization> |
---|
2161 | <address><email>addison@inter-locale.com</email></address> |
---|
2162 | </author> |
---|
2163 | <author initials="M." surname="Davis" fullname="Mark Davis" role="editor"> |
---|
2164 | <organization>Google</organization> |
---|
2165 | <address><email>mark.davis@google.com</email></address> |
---|
2166 | </author> |
---|
2167 | <date month="September" year="2009"/> |
---|
2168 | </front> |
---|
2169 | <seriesInfo name="BCP" value="47"/> |
---|
2170 | <seriesInfo name="RFC" value="5646"/> |
---|
2171 | </reference> |
---|
2172 | |
---|
2173 | </references> |
---|
2174 | |
---|
2175 | <references title="Informative References"> |
---|
2176 | |
---|
2177 | <reference anchor="RFC1945"> |
---|
2178 | <front> |
---|
2179 | <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> |
---|
2180 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
2181 | <organization>MIT, Laboratory for Computer Science</organization> |
---|
2182 | <address><email>timbl@w3.org</email></address> |
---|
2183 | </author> |
---|
2184 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
2185 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
2186 | <address><email>fielding@ics.uci.edu</email></address> |
---|
2187 | </author> |
---|
2188 | <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
2189 | <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> |
---|
2190 | <address><email>frystyk@w3.org</email></address> |
---|
2191 | </author> |
---|
2192 | <date month="May" year="1996"/> |
---|
2193 | </front> |
---|
2194 | <seriesInfo name="RFC" value="1945"/> |
---|
2195 | </reference> |
---|
2196 | |
---|
2197 | <reference anchor="RFC2049"> |
---|
2198 | <front> |
---|
2199 | <title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title> |
---|
2200 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
2201 | <organization>Innosoft International, Inc.</organization> |
---|
2202 | <address><email>ned@innosoft.com</email></address> |
---|
2203 | </author> |
---|
2204 | <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
2205 | <organization>First Virtual Holdings</organization> |
---|
2206 | <address><email>nsb@nsb.fv.com</email></address> |
---|
2207 | </author> |
---|
2208 | <date month="November" year="1996"/> |
---|
2209 | </front> |
---|
2210 | <seriesInfo name="RFC" value="2049"/> |
---|
2211 | </reference> |
---|
2212 | |
---|
2213 | <reference anchor="RFC2068"> |
---|
2214 | <front> |
---|
2215 | <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
2216 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
2217 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
2218 | <address><email>fielding@ics.uci.edu</email></address> |
---|
2219 | </author> |
---|
2220 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
2221 | <organization>MIT Laboratory for Computer Science</organization> |
---|
2222 | <address><email>jg@w3.org</email></address> |
---|
2223 | </author> |
---|
2224 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
2225 | <organization>Digital Equipment Corporation, Western Research Laboratory</organization> |
---|
2226 | <address><email>mogul@wrl.dec.com</email></address> |
---|
2227 | </author> |
---|
2228 | <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
2229 | <organization>MIT Laboratory for Computer Science</organization> |
---|
2230 | <address><email>frystyk@w3.org</email></address> |
---|
2231 | </author> |
---|
2232 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
2233 | <organization>MIT Laboratory for Computer Science</organization> |
---|
2234 | <address><email>timbl@w3.org</email></address> |
---|
2235 | </author> |
---|
2236 | <date month="January" year="1997"/> |
---|
2237 | </front> |
---|
2238 | <seriesInfo name="RFC" value="2068"/> |
---|
2239 | </reference> |
---|
2240 | |
---|
2241 | <reference anchor="RFC2076"> |
---|
2242 | <front> |
---|
2243 | <title abbrev="Internet Message Headers">Common Internet Message Headers</title> |
---|
2244 | <author initials="J." surname="Palme" fullname="Jacob Palme"> |
---|
2245 | <organization>Stockholm University/KTH</organization> |
---|
2246 | <address><email>jpalme@dsv.su.se</email></address> |
---|
2247 | </author> |
---|
2248 | <date month="February" year="1997"/> |
---|
2249 | </front> |
---|
2250 | <seriesInfo name="RFC" value="2076"/> |
---|
2251 | </reference> |
---|
2252 | |
---|
2253 | <reference anchor="RFC2183"> |
---|
2254 | <front> |
---|
2255 | <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title> |
---|
2256 | <author initials="R." surname="Troost" fullname="Rens Troost"> |
---|
2257 | <organization>New Century Systems</organization> |
---|
2258 | <address><email>rens@century.com</email></address> |
---|
2259 | </author> |
---|
2260 | <author initials="S." surname="Dorner" fullname="Steve Dorner"> |
---|
2261 | <organization>QUALCOMM Incorporated</organization> |
---|
2262 | <address><email>sdorner@qualcomm.com</email></address> |
---|
2263 | </author> |
---|
2264 | <author initials="K." surname="Moore" fullname="Keith Moore"> |
---|
2265 | <organization>Department of Computer Science</organization> |
---|
2266 | <address><email>moore@cs.utk.edu</email></address> |
---|
2267 | </author> |
---|
2268 | <date month="August" year="1997"/> |
---|
2269 | </front> |
---|
2270 | <seriesInfo name="RFC" value="2183"/> |
---|
2271 | </reference> |
---|
2272 | |
---|
2273 | <reference anchor="RFC2277"> |
---|
2274 | <front> |
---|
2275 | <title abbrev="Charset Policy">IETF Policy on Character Sets and Languages</title> |
---|
2276 | <author initials="H.T." surname="Alvestrand" fullname="Harald Tveit Alvestrand"> |
---|
2277 | <organization>UNINETT</organization> |
---|
2278 | <address><email>Harald.T.Alvestrand@uninett.no</email></address> |
---|
2279 | </author> |
---|
2280 | <date month="January" year="1998"/> |
---|
2281 | </front> |
---|
2282 | <seriesInfo name="BCP" value="18"/> |
---|
2283 | <seriesInfo name="RFC" value="2277"/> |
---|
2284 | </reference> |
---|
2285 | |
---|
2286 | <reference anchor="RFC2295"> |
---|
2287 | <front> |
---|
2288 | <title abbrev="HTTP Content Negotiation">Transparent Content Negotiation in HTTP</title> |
---|
2289 | <author initials="K." surname="Holtman" fullname="Koen Holtman"> |
---|
2290 | <organization>Technische Universiteit Eindhoven</organization> |
---|
2291 | <address> |
---|
2292 | <email>koen@win.tue.nl</email> |
---|
2293 | </address> |
---|
2294 | </author> |
---|
2295 | <author initials="A.H." surname="Mutz" fullname="Andrew H. Mutz"> |
---|
2296 | <organization>Hewlett-Packard Company</organization> |
---|
2297 | <address> |
---|
2298 | <email>mutz@hpl.hp.com</email> |
---|
2299 | </address> |
---|
2300 | </author> |
---|
2301 | <date year="1998" month="March"/> |
---|
2302 | </front> |
---|
2303 | <seriesInfo name="RFC" value="2295"/> |
---|
2304 | </reference> |
---|
2305 | |
---|
2306 | <reference anchor="RFC2388"> |
---|
2307 | <front> |
---|
2308 | <title abbrev="multipart/form-data">Returning Values from Forms: multipart/form-data</title> |
---|
2309 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
2310 | <organization>Xerox Palo Alto Research Center</organization> |
---|
2311 | <address><email>masinter@parc.xerox.com</email></address> |
---|
2312 | </author> |
---|
2313 | <date year="1998" month="August"/> |
---|
2314 | </front> |
---|
2315 | <seriesInfo name="RFC" value="2388"/> |
---|
2316 | </reference> |
---|
2317 | |
---|
2318 | <reference anchor="RFC2557"> |
---|
2319 | <front> |
---|
2320 | <title abbrev="MIME Encapsulation of Aggregate Documents">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</title> |
---|
2321 | <author initials="F." surname="Palme" fullname="Jacob Palme"> |
---|
2322 | <organization>Stockholm University and KTH</organization> |
---|
2323 | <address><email>jpalme@dsv.su.se</email></address> |
---|
2324 | </author> |
---|
2325 | <author initials="A." surname="Hopmann" fullname="Alex Hopmann"> |
---|
2326 | <organization>Microsoft Corporation</organization> |
---|
2327 | <address><email>alexhop@microsoft.com</email></address> |
---|
2328 | </author> |
---|
2329 | <author initials="N." surname="Shelness" fullname="Nick Shelness"> |
---|
2330 | <organization>Lotus Development Corporation</organization> |
---|
2331 | <address><email>Shelness@lotus.com</email></address> |
---|
2332 | </author> |
---|
2333 | <author initials="E." surname="Stefferud" fullname="Einar Stefferud"> |
---|
2334 | <address><email>stef@nma.com</email></address> |
---|
2335 | </author> |
---|
2336 | <date year="1999" month="March"/> |
---|
2337 | </front> |
---|
2338 | <seriesInfo name="RFC" value="2557"/> |
---|
2339 | </reference> |
---|
2340 | |
---|
2341 | <reference anchor="RFC2616"> |
---|
2342 | <front> |
---|
2343 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
2344 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
2345 | <organization>University of California, Irvine</organization> |
---|
2346 | <address><email>fielding@ics.uci.edu</email></address> |
---|
2347 | </author> |
---|
2348 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
2349 | <organization>W3C</organization> |
---|
2350 | <address><email>jg@w3.org</email></address> |
---|
2351 | </author> |
---|
2352 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
2353 | <organization>Compaq Computer Corporation</organization> |
---|
2354 | <address><email>mogul@wrl.dec.com</email></address> |
---|
2355 | </author> |
---|
2356 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
2357 | <organization>MIT Laboratory for Computer Science</organization> |
---|
2358 | <address><email>frystyk@w3.org</email></address> |
---|
2359 | </author> |
---|
2360 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
2361 | <organization>Xerox Corporation</organization> |
---|
2362 | <address><email>masinter@parc.xerox.com</email></address> |
---|
2363 | </author> |
---|
2364 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
2365 | <organization>Microsoft Corporation</organization> |
---|
2366 | <address><email>paulle@microsoft.com</email></address> |
---|
2367 | </author> |
---|
2368 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
2369 | <organization>W3C</organization> |
---|
2370 | <address><email>timbl@w3.org</email></address> |
---|
2371 | </author> |
---|
2372 | <date month="June" year="1999"/> |
---|
2373 | </front> |
---|
2374 | <seriesInfo name="RFC" value="2616"/> |
---|
2375 | </reference> |
---|
2376 | |
---|
2377 | <reference anchor="RFC3629"> |
---|
2378 | <front> |
---|
2379 | <title>UTF-8, a transformation format of ISO 10646</title> |
---|
2380 | <author initials="F." surname="Yergeau" fullname="F. Yergeau"> |
---|
2381 | <organization>Alis Technologies</organization> |
---|
2382 | <address><email>fyergeau@alis.com</email></address> |
---|
2383 | </author> |
---|
2384 | <date month="November" year="2003"/> |
---|
2385 | </front> |
---|
2386 | <seriesInfo name="RFC" value="3629"/> |
---|
2387 | <seriesInfo name="STD" value="63"/> |
---|
2388 | </reference> |
---|
2389 | |
---|
2390 | <reference anchor="RFC3864"> |
---|
2391 | <front> |
---|
2392 | <title>Registration Procedures for Message Header Fields</title> |
---|
2393 | <author initials="G." surname="Klyne" fullname="G. Klyne"> |
---|
2394 | <organization>Nine by Nine</organization> |
---|
2395 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
2396 | </author> |
---|
2397 | <author initials="M." surname="Nottingham" fullname="M. Nottingham"> |
---|
2398 | <organization>BEA Systems</organization> |
---|
2399 | <address><email>mnot@pobox.com</email></address> |
---|
2400 | </author> |
---|
2401 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
2402 | <organization>HP Labs</organization> |
---|
2403 | <address><email>JeffMogul@acm.org</email></address> |
---|
2404 | </author> |
---|
2405 | <date year="2004" month="September"/> |
---|
2406 | </front> |
---|
2407 | <seriesInfo name="BCP" value="90"/> |
---|
2408 | <seriesInfo name="RFC" value="3864"/> |
---|
2409 | </reference> |
---|
2410 | |
---|
2411 | <reference anchor="RFC4288"> |
---|
2412 | <front> |
---|
2413 | <title>Media Type Specifications and Registration Procedures</title> |
---|
2414 | <author initials="N." surname="Freed" fullname="N. Freed"> |
---|
2415 | <organization>Sun Microsystems</organization> |
---|
2416 | <address> |
---|
2417 | <email>ned.freed@mrochek.com</email> |
---|
2418 | </address> |
---|
2419 | </author> |
---|
2420 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
2421 | <address> |
---|
2422 | <email>klensin+ietf@jck.com</email> |
---|
2423 | </address> |
---|
2424 | </author> |
---|
2425 | <date year="2005" month="December"/> |
---|
2426 | </front> |
---|
2427 | <seriesInfo name="BCP" value="13"/> |
---|
2428 | <seriesInfo name="RFC" value="4288"/> |
---|
2429 | </reference> |
---|
2430 | |
---|
2431 | <reference anchor="RFC5226"> |
---|
2432 | <front> |
---|
2433 | <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> |
---|
2434 | <author initials="T." surname="Narten" fullname="T. Narten"> |
---|
2435 | <organization>IBM</organization> |
---|
2436 | <address><email>narten@us.ibm.com</email></address> |
---|
2437 | </author> |
---|
2438 | <author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> |
---|
2439 | <organization>Google</organization> |
---|
2440 | <address><email>Harald@Alvestrand.no</email></address> |
---|
2441 | </author> |
---|
2442 | <date year="2008" month="May"/> |
---|
2443 | </front> |
---|
2444 | <seriesInfo name="BCP" value="26"/> |
---|
2445 | <seriesInfo name="RFC" value="5226"/> |
---|
2446 | </reference> |
---|
2447 | |
---|
2448 | <reference anchor="RFC5322"> |
---|
2449 | <front> |
---|
2450 | <title>Internet Message Format</title> |
---|
2451 | <author initials="P." surname="Resnick" fullname="P. Resnick"> |
---|
2452 | <organization>Qualcomm Incorporated</organization> |
---|
2453 | </author> |
---|
2454 | <date year="2008" month="October"/> |
---|
2455 | </front> |
---|
2456 | <seriesInfo name="RFC" value="5322"/> |
---|
2457 | </reference> |
---|
2458 | |
---|
2459 | <reference anchor="BCP97"> |
---|
2460 | <front> |
---|
2461 | <title>Handling Normative References to Standards-Track Documents</title> |
---|
2462 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
2463 | <address> |
---|
2464 | <email>klensin+ietf@jck.com</email> |
---|
2465 | </address> |
---|
2466 | </author> |
---|
2467 | <author initials="S." surname="Hartman" fullname="S. Hartman"> |
---|
2468 | <organization>MIT</organization> |
---|
2469 | <address> |
---|
2470 | <email>hartmans-ietf@mit.edu</email> |
---|
2471 | </address> |
---|
2472 | </author> |
---|
2473 | <date year="2007" month="June"/> |
---|
2474 | </front> |
---|
2475 | <seriesInfo name="BCP" value="97"/> |
---|
2476 | <seriesInfo name="RFC" value="4897"/> |
---|
2477 | </reference> |
---|
2478 | |
---|
2479 | |
---|
2480 | </references> |
---|
2481 | |
---|
2482 | <section title="Differences Between HTTP Entities and RFC 2045 Entities" anchor="differences.between.http.entities.and.rfc.2045.entities"> |
---|
2483 | <t> |
---|
2484 | HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to |
---|
2485 | allow entities to be transmitted in an open variety of |
---|
2486 | representations and with extensible mechanisms. However, RFC 2045 |
---|
2487 | discusses mail, and HTTP has a few features that are different from |
---|
2488 | those described in RFC 2045. These differences were carefully chosen |
---|
2489 | to optimize performance over binary connections, to allow greater |
---|
2490 | freedom in the use of new media types, to make date comparisons |
---|
2491 | easier, and to acknowledge the practice of some early HTTP servers |
---|
2492 | and clients. |
---|
2493 | </t> |
---|
2494 | <t> |
---|
2495 | This appendix describes specific areas where HTTP differs from RFC |
---|
2496 | 2045. Proxies and gateways to strict MIME environments SHOULD be |
---|
2497 | aware of these differences and provide the appropriate conversions |
---|
2498 | where necessary. Proxies and gateways from MIME environments to HTTP |
---|
2499 | also need to be aware of the differences because some conversions |
---|
2500 | might be required. |
---|
2501 | </t> |
---|
2502 | |
---|
2503 | <section title="MIME-Version" anchor="mime-version"> |
---|
2504 | <iref primary="true" item="MIME-Version header"/> |
---|
2505 | <iref primary="true" item="Headers" subitem="MIME-Version"/> |
---|
2506 | |
---|
2507 | |
---|
2508 | <t> |
---|
2509 | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY |
---|
2510 | include a single MIME-Version general-header field to indicate what |
---|
2511 | version of the MIME protocol was used to construct the message. Use |
---|
2512 | of the MIME-Version header field indicates that the message is in |
---|
2513 | full compliance with the MIME protocol (as defined in <xref target="RFC2045"/>). |
---|
2514 | Proxies/gateways are responsible for ensuring full compliance (where |
---|
2515 | possible) when exporting HTTP messages to strict MIME environments. |
---|
2516 | </t> |
---|
2517 | <figure><iref primary="true" item="Grammar" subitem="MIME-Version"/><iref primary="true" item="Grammar" subitem="MIME-Version-v"/><artwork type="abnf2616"><![CDATA[ |
---|
2518 | MIME-Version = "MIME-Version" ":" OWS MIME-Version-v |
---|
2519 | MIME-Version-v = 1*DIGIT "." 1*DIGIT |
---|
2520 | ]]></artwork></figure> |
---|
2521 | <t> |
---|
2522 | MIME version "1.0" is the default for use in HTTP/1.1. However, |
---|
2523 | HTTP/1.1 message parsing and semantics are defined by this document |
---|
2524 | and not the MIME specification. |
---|
2525 | </t> |
---|
2526 | </section> |
---|
2527 | |
---|
2528 | <section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form"> |
---|
2529 | <t> |
---|
2530 | <xref target="RFC2045"/> requires that an Internet mail entity be converted to |
---|
2531 | canonical form prior to being transferred, as described in Section 4 of <xref target="RFC2049"/>. |
---|
2532 | <xref target="canonicalization.and.text.defaults"/> of this document describes the forms |
---|
2533 | allowed for subtypes of the "text" media type when transmitted over |
---|
2534 | HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent |
---|
2535 | line breaks as CRLF and forbids the use of CR or LF outside of line |
---|
2536 | break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a |
---|
2537 | line break within text content when a message is transmitted over |
---|
2538 | HTTP. |
---|
2539 | </t> |
---|
2540 | <t> |
---|
2541 | Where it is possible, a proxy or gateway from HTTP to a strict MIME |
---|
2542 | environment SHOULD translate all line breaks within the text media |
---|
2543 | types described in <xref target="canonicalization.and.text.defaults"/> of this document to the RFC 2049 |
---|
2544 | canonical form of CRLF. Note, however, that this might be complicated |
---|
2545 | by the presence of a Content-Encoding and by the fact that HTTP |
---|
2546 | allows the use of some character sets which do not use octets 13 and |
---|
2547 | 10 to represent CR and LF, as is the case for some multi-byte |
---|
2548 | character sets. |
---|
2549 | </t> |
---|
2550 | <t> |
---|
2551 | Implementors should note that conversion will break any cryptographic |
---|
2552 | checksums applied to the original content unless the original content |
---|
2553 | is already in canonical form. Therefore, the canonical form is |
---|
2554 | recommended for any content that uses such checksums in HTTP. |
---|
2555 | </t> |
---|
2556 | </section> |
---|
2557 | |
---|
2558 | |
---|
2559 | <section title="Conversion of Date Formats" anchor="conversion.of.date.formats"> |
---|
2560 | <t> |
---|
2561 | HTTP/1.1 uses a restricted set of date formats (Section 6.1 of <xref target="Part1"/>) to |
---|
2562 | simplify the process of date comparison. Proxies and gateways from |
---|
2563 | other protocols SHOULD ensure that any Date header field present in a |
---|
2564 | message conforms to one of the HTTP/1.1 formats and rewrite the date |
---|
2565 | if necessary. |
---|
2566 | </t> |
---|
2567 | </section> |
---|
2568 | |
---|
2569 | <section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding"> |
---|
2570 | <t> |
---|
2571 | RFC 2045 does not include any concept equivalent to HTTP/1.1's |
---|
2572 | Content-Encoding header field. Since this acts as a modifier on the |
---|
2573 | media type, proxies and gateways from HTTP to MIME-compliant |
---|
2574 | protocols MUST either change the value of the Content-Type header |
---|
2575 | field or decode the entity-body before forwarding the message. (Some |
---|
2576 | experimental applications of Content-Type for Internet mail have used |
---|
2577 | a media-type parameter of ";conversions=<content-coding>" to perform |
---|
2578 | a function equivalent to Content-Encoding. However, this parameter is |
---|
2579 | not part of RFC 2045). |
---|
2580 | </t> |
---|
2581 | </section> |
---|
2582 | |
---|
2583 | <section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding"> |
---|
2584 | <t> |
---|
2585 | HTTP does not use the Content-Transfer-Encoding field of RFC |
---|
2586 | 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST |
---|
2587 | remove any Content-Transfer-Encoding |
---|
2588 | prior to delivering the response message to an HTTP client. |
---|
2589 | </t> |
---|
2590 | <t> |
---|
2591 | Proxies and gateways from HTTP to MIME-compliant protocols are |
---|
2592 | responsible for ensuring that the message is in the correct format |
---|
2593 | and encoding for safe transport on that protocol, where "safe |
---|
2594 | transport" is defined by the limitations of the protocol being used. |
---|
2595 | Such a proxy or gateway SHOULD label the data with an appropriate |
---|
2596 | Content-Transfer-Encoding if doing so will improve the likelihood of |
---|
2597 | safe transport over the destination protocol. |
---|
2598 | </t> |
---|
2599 | </section> |
---|
2600 | |
---|
2601 | <section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding"> |
---|
2602 | <t> |
---|
2603 | HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 of <xref target="Part1"/>). |
---|
2604 | Proxies/gateways MUST remove any transfer-coding prior to |
---|
2605 | forwarding a message via a MIME-compliant protocol. |
---|
2606 | </t> |
---|
2607 | </section> |
---|
2608 | |
---|
2609 | <section title="MHTML and Line Length Limitations" anchor="mhtml.line.length"> |
---|
2610 | <t> |
---|
2611 | HTTP implementations which share code with MHTML <xref target="RFC2557"/> implementations |
---|
2612 | need to be aware of MIME line length limitations. Since HTTP does not |
---|
2613 | have this limitation, HTTP does not fold long lines. MHTML messages |
---|
2614 | being transported by HTTP follow all conventions of MHTML, including |
---|
2615 | line length limitations and folding, canonicalization, etc., since |
---|
2616 | HTTP transports all message-bodies as payload (see <xref target="multipart.types"/>) and |
---|
2617 | does not interpret the content or any MIME header lines that might be |
---|
2618 | contained therein. |
---|
2619 | </t> |
---|
2620 | </section> |
---|
2621 | </section> |
---|
2622 | |
---|
2623 | <section title="Additional Features" anchor="additional.features"> |
---|
2624 | <t> |
---|
2625 | <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some |
---|
2626 | existing HTTP implementations, but not consistently and correctly |
---|
2627 | across most HTTP/1.1 applications. Implementors are advised to be |
---|
2628 | aware of these features, but cannot rely upon their presence in, or |
---|
2629 | interoperability with, other HTTP/1.1 applications. Some of these |
---|
2630 | describe proposed experimental features, and some describe features |
---|
2631 | that experimental deployment found lacking that are now addressed in |
---|
2632 | the base HTTP/1.1 specification. |
---|
2633 | </t> |
---|
2634 | <t> |
---|
2635 | A number of other headers, such as Content-Disposition and Title, |
---|
2636 | from SMTP and MIME are also often implemented (see <xref target="RFC2076"/>). |
---|
2637 | </t> |
---|
2638 | |
---|
2639 | <section title="Content-Disposition" anchor="content-disposition"> |
---|
2640 | <iref item="Headers" subitem="Content-Disposition" primary="true"/> |
---|
2641 | <iref item="Content-Disposition header" primary="true"/> |
---|
2642 | |
---|
2643 | |
---|
2644 | |
---|
2645 | |
---|
2646 | |
---|
2647 | |
---|
2648 | |
---|
2649 | <t> |
---|
2650 | The "Content-Disposition" response-header field has been proposed as a |
---|
2651 | means for the origin server to suggest a default filename if the user |
---|
2652 | requests that the content is saved to a file. This usage is derived |
---|
2653 | from the definition of Content-Disposition in <xref target="RFC2183"/>. |
---|
2654 | </t> |
---|
2655 | <figure><iref primary="true" item="Grammar" subitem="content-disposition"/><iref primary="true" item="Grammar" subitem="content-disposition-v"/><iref primary="true" item="Grammar" subitem="disposition-type"/><iref primary="true" item="Grammar" subitem="disposition-parm"/><iref primary="true" item="Grammar" subitem="filename-parm"/><iref primary="true" item="Grammar" subitem="disp-extension-token"/><iref primary="true" item="Grammar" subitem="disp-extension-parm"/><artwork type="abnf2616"><![CDATA[ |
---|
2656 | content-disposition = "Content-Disposition" ":" OWS |
---|
2657 | content-disposition-v |
---|
2658 | content-disposition-v = disposition-type |
---|
2659 | *( OWS ";" OWS disposition-parm ) |
---|
2660 | disposition-type = "attachment" / disp-extension-token |
---|
2661 | disposition-parm = filename-parm / disp-extension-parm |
---|
2662 | filename-parm = "filename" "=" quoted-string |
---|
2663 | disp-extension-token = token |
---|
2664 | disp-extension-parm = token "=" word |
---|
2665 | ]]></artwork></figure> |
---|
2666 | <t> |
---|
2667 | An example is |
---|
2668 | </t> |
---|
2669 | <figure><artwork type="example"><![CDATA[ |
---|
2670 | Content-Disposition: attachment; filename="fname.ext" |
---|
2671 | ]]></artwork></figure> |
---|
2672 | <t> |
---|
2673 | The receiving user agent SHOULD NOT respect any directory path |
---|
2674 | information present in the filename-parm parameter, which is the only |
---|
2675 | parameter believed to apply to HTTP implementations at this time. The |
---|
2676 | filename SHOULD be treated as a terminal component only. |
---|
2677 | </t> |
---|
2678 | <t> |
---|
2679 | If this header is used in a response with the application/octet-stream |
---|
2680 | content-type, the implied suggestion is that the user agent |
---|
2681 | should not display the response, but directly enter a "save response |
---|
2682 | as..." dialog. |
---|
2683 | </t> |
---|
2684 | <t> |
---|
2685 | See <xref target="content-disposition.issues"/> for Content-Disposition security issues. |
---|
2686 | </t> |
---|
2687 | </section> |
---|
2688 | </section> |
---|
2689 | |
---|
2690 | <section title="Compatibility with Previous Versions" anchor="compatibility"> |
---|
2691 | <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> |
---|
2692 | <t> |
---|
2693 | Transfer-coding and message lengths all interact in ways that |
---|
2694 | required fixing exactly when chunked encoding is used (to allow for |
---|
2695 | transfer encoding that may not be self delimiting); it was important |
---|
2696 | to straighten out exactly how message lengths are computed. |
---|
2697 | (<xref target="entity.length"/>, see also <xref target="Part1"/>, |
---|
2698 | <xref target="Part5"/> and <xref target="Part6"/>). |
---|
2699 | </t> |
---|
2700 | <t> |
---|
2701 | Charset wildcarding is introduced to avoid explosion of character set |
---|
2702 | names in accept headers. (<xref target="header.accept-charset"/>) |
---|
2703 | </t> |
---|
2704 | <t> |
---|
2705 | Content-Base was deleted from the specification: it was not |
---|
2706 | implemented widely, and there is no simple, safe way to introduce it |
---|
2707 | without a robust extension mechanism. In addition, it is used in a |
---|
2708 | similar, but not identical fashion in MHTML <xref target="RFC2557"/>. |
---|
2709 | </t> |
---|
2710 | <t> |
---|
2711 | A content-coding of "identity" was introduced, to solve problems |
---|
2712 | discovered in caching. (<xref target="content.codings"/>) |
---|
2713 | </t> |
---|
2714 | <t> |
---|
2715 | The Alternates<iref item="Alternates header" primary="true"/><iref item="Headers" subitem="Alternate" primary="true"/>, Content-Version<iref item="Content-Version header" primary="true"/><iref item="Headers" subitem="Content-Version" primary="true"/>, Derived-From<iref item="Derived-From header" primary="true"/><iref item="Headers" subitem="Derived-From" primary="true"/>, Link<iref item="Link header" primary="true"/><iref item="Headers" subitem="Link" primary="true"/>, URI<iref item="URI header" primary="true"/><iref item="Headers" subitem="URI" primary="true"/>, Public<iref item="Public header" primary="true"/><iref item="Headers" subitem="Public" primary="true"/> and |
---|
2716 | Content-Base<iref item="Content-Base header" primary="true"/><iref item="Headers" subitem="Content-Base" primary="true"/> header fields were defined in previous versions of this |
---|
2717 | specification, but not commonly implemented. See Section 19.6.2 of <xref target="RFC2068"/>. |
---|
2718 | </t> |
---|
2719 | </section> |
---|
2720 | |
---|
2721 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
2722 | <t> |
---|
2723 | Clarify contexts that charset is used in. |
---|
2724 | (<xref target="character.sets"/>) |
---|
2725 | </t> |
---|
2726 | <t> |
---|
2727 | Remove base URI setting semantics for Content-Location due to poor |
---|
2728 | implementation support, which was caused by too many broken servers emitting |
---|
2729 | bogus Content-Location headers, and also the potentially undesirable effect |
---|
2730 | of potentially breaking relative links in content-negotiated resources. |
---|
2731 | (<xref target="header.content-location"/>) |
---|
2732 | </t> |
---|
2733 | <t> |
---|
2734 | Remove reference to non-existant identity transfer-coding value tokens. |
---|
2735 | (<xref target="no.content-transfer-encoding"/>) |
---|
2736 | </t> |
---|
2737 | </section> |
---|
2738 | |
---|
2739 | </section> |
---|
2740 | |
---|
2741 | |
---|
2742 | <section title="Collected ABNF" anchor="collected.abnf"> |
---|
2743 | <figure> |
---|
2744 | <artwork type="abnf" name="p3-payload.parsed-abnf"><![CDATA[ |
---|
2745 | Accept = "Accept:" OWS Accept-v |
---|
2746 | Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v |
---|
2747 | Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" |
---|
2748 | qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" |
---|
2749 | qvalue ] ] ) |
---|
2750 | Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v |
---|
2751 | Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) |
---|
2752 | ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] |
---|
2753 | Accept-Language = "Accept-Language:" OWS Accept-Language-v |
---|
2754 | Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q=" |
---|
2755 | qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] |
---|
2756 | ] ) |
---|
2757 | Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
---|
2758 | OWS media-range [ accept-params ] ] ) ] |
---|
2759 | |
---|
2760 | Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v |
---|
2761 | Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS |
---|
2762 | content-coding ] ) |
---|
2763 | Content-Language = "Content-Language:" OWS Content-Language-v |
---|
2764 | Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS |
---|
2765 | language-tag ] ) |
---|
2766 | Content-Length = <Content-Length, defined in [Part1], Section 9.2> |
---|
2767 | Content-Location = "Content-Location:" OWS Content-Location-v |
---|
2768 | Content-Location-v = absolute-URI / partial-URI |
---|
2769 | Content-MD5 = "Content-MD5:" OWS Content-MD5-v |
---|
2770 | Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> |
---|
2771 | Content-Range = <Content-Range, defined in [Part5], Section 5.2> |
---|
2772 | Content-Type = "Content-Type:" OWS Content-Type-v |
---|
2773 | Content-Type-v = media-type |
---|
2774 | |
---|
2775 | Expires = <Expires, defined in [Part6], Section 3.3> |
---|
2776 | |
---|
2777 | Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> |
---|
2778 | |
---|
2779 | MIME-Version = "MIME-Version:" OWS MIME-Version-v |
---|
2780 | MIME-Version-v = 1*DIGIT "." 1*DIGIT |
---|
2781 | |
---|
2782 | OWS = <OWS, defined in [Part1], Section 1.2.2> |
---|
2783 | |
---|
2784 | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
---|
2785 | accept-ext = OWS ";" OWS token [ "=" word ] |
---|
2786 | accept-params = OWS ";" OWS "q=" qvalue *accept-ext |
---|
2787 | attribute = token |
---|
2788 | |
---|
2789 | charset = token |
---|
2790 | codings = ( content-coding / "*" ) |
---|
2791 | content-coding = token |
---|
2792 | content-disposition = "Content-Disposition:" OWS |
---|
2793 | content-disposition-v |
---|
2794 | content-disposition-v = disposition-type *( OWS ";" OWS |
---|
2795 | disposition-parm ) |
---|
2796 | |
---|
2797 | disp-extension-parm = token "=" word |
---|
2798 | disp-extension-token = token |
---|
2799 | disposition-parm = filename-parm / disp-extension-parm |
---|
2800 | disposition-type = "attachment" / disp-extension-token |
---|
2801 | |
---|
2802 | entity-body = *OCTET |
---|
2803 | entity-header = Content-Encoding / Content-Language / Content-Length |
---|
2804 | / Content-Location / Content-MD5 / Content-Range / Content-Type / |
---|
2805 | Expires / Last-Modified / extension-header |
---|
2806 | extension-header = header-field |
---|
2807 | |
---|
2808 | filename-parm = "filename=" quoted-string |
---|
2809 | |
---|
2810 | header-field = <header-field, defined in [Part1], Section 3.2> |
---|
2811 | |
---|
2812 | language-range = <language-range, defined in [RFC4647], Section 2.1> |
---|
2813 | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
---|
2814 | |
---|
2815 | media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |
---|
2816 | ";" OWS parameter ) |
---|
2817 | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
---|
2818 | |
---|
2819 | parameter = attribute "=" value |
---|
2820 | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
---|
2821 | |
---|
2822 | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
---|
2823 | qvalue = <qvalue, defined in [Part1], Section 6.4> |
---|
2824 | |
---|
2825 | subtype = token |
---|
2826 | |
---|
2827 | token = <token, defined in [Part1], Section 1.2.2> |
---|
2828 | type = token |
---|
2829 | |
---|
2830 | value = word |
---|
2831 | |
---|
2832 | word = <word, defined in [Part1], Section 1.2.2> |
---|
2833 | ]]></artwork> |
---|
2834 | </figure> |
---|
2835 | <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[ |
---|
2836 | ; Accept defined but not used |
---|
2837 | ; Accept-Charset defined but not used |
---|
2838 | ; Accept-Encoding defined but not used |
---|
2839 | ; Accept-Language defined but not used |
---|
2840 | ; MIME-Version defined but not used |
---|
2841 | ; content-disposition defined but not used |
---|
2842 | ; entity-body defined but not used |
---|
2843 | ; entity-header defined but not used |
---|
2844 | ]]></artwork></figure></section> |
---|
2845 | |
---|
2846 | |
---|
2847 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
2848 | |
---|
2849 | <section title="Since RFC2616"> |
---|
2850 | <t> |
---|
2851 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
2852 | </t> |
---|
2853 | </section> |
---|
2854 | |
---|
2855 | <section title="Since draft-ietf-httpbis-p3-payload-00"> |
---|
2856 | <t> |
---|
2857 | Closed issues: |
---|
2858 | <list style="symbols"> |
---|
2859 | <t> |
---|
2860 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/8"/>: |
---|
2861 | "Media Type Registrations" |
---|
2862 | (<eref target="http://purl.org/NET/http-errata#media-reg"/>) |
---|
2863 | </t> |
---|
2864 | <t> |
---|
2865 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/14"/>: |
---|
2866 | "Clarification regarding quoting of charset values" |
---|
2867 | (<eref target="http://purl.org/NET/http-errata#charactersets"/>) |
---|
2868 | </t> |
---|
2869 | <t> |
---|
2870 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/16"/>: |
---|
2871 | "Remove 'identity' token references" |
---|
2872 | (<eref target="http://purl.org/NET/http-errata#identity"/>) |
---|
2873 | </t> |
---|
2874 | <t> |
---|
2875 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/25"/>: |
---|
2876 | "Accept-Encoding BNF" |
---|
2877 | </t> |
---|
2878 | <t> |
---|
2879 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
2880 | "Normative and Informative references" |
---|
2881 | </t> |
---|
2882 | <t> |
---|
2883 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/46"/>: |
---|
2884 | "RFC1700 references" |
---|
2885 | </t> |
---|
2886 | <t> |
---|
2887 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/55"/>: |
---|
2888 | "Updating to RFC4288" |
---|
2889 | </t> |
---|
2890 | <t> |
---|
2891 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>: |
---|
2892 | "Informative references" |
---|
2893 | </t> |
---|
2894 | <t> |
---|
2895 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/66"/>: |
---|
2896 | "ISO-8859-1 Reference" |
---|
2897 | </t> |
---|
2898 | <t> |
---|
2899 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/68"/>: |
---|
2900 | "Encoding References Normative" |
---|
2901 | </t> |
---|
2902 | <t> |
---|
2903 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86"/>: |
---|
2904 | "Normative up-to-date references" |
---|
2905 | </t> |
---|
2906 | </list> |
---|
2907 | </t> |
---|
2908 | </section> |
---|
2909 | |
---|
2910 | <section title="Since draft-ietf-httpbis-p3-payload-01"> |
---|
2911 | <t> |
---|
2912 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
2913 | <list style="symbols"> |
---|
2914 | <t> |
---|
2915 | Add explicit references to BNF syntax and rules imported from other parts of the specification. |
---|
2916 | </t> |
---|
2917 | </list> |
---|
2918 | </t> |
---|
2919 | </section> |
---|
2920 | |
---|
2921 | <section title="Since draft-ietf-httpbis-p3-payload-02" anchor="changes.since.02"> |
---|
2922 | <t> |
---|
2923 | Closed issues: |
---|
2924 | <list style="symbols"> |
---|
2925 | <t> |
---|
2926 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/67"/>: |
---|
2927 | "Quoting Charsets" |
---|
2928 | </t> |
---|
2929 | <t> |
---|
2930 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>: |
---|
2931 | "Classification for Allow header" |
---|
2932 | </t> |
---|
2933 | <t> |
---|
2934 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/115"/>: |
---|
2935 | "missing default for qvalue in description of Accept-Encoding" |
---|
2936 | </t> |
---|
2937 | </list> |
---|
2938 | </t> |
---|
2939 | <t> |
---|
2940 | Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): |
---|
2941 | <list style="symbols"> |
---|
2942 | <t> |
---|
2943 | Reference RFC 3984, and update header registrations for headers defined |
---|
2944 | in this document. |
---|
2945 | </t> |
---|
2946 | </list> |
---|
2947 | </t> |
---|
2948 | </section> |
---|
2949 | |
---|
2950 | <section title="Since draft-ietf-httpbis-p3-payload-03" anchor="changes.since.03"> |
---|
2951 | <t> |
---|
2952 | Closed issues: |
---|
2953 | <list style="symbols"> |
---|
2954 | <t> |
---|
2955 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/67"/>: |
---|
2956 | "Quoting Charsets" |
---|
2957 | </t> |
---|
2958 | <t> |
---|
2959 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/113"/>: |
---|
2960 | "language tag matching (Accept-Language) vs RFC4647" |
---|
2961 | </t> |
---|
2962 | <t> |
---|
2963 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/121"/>: |
---|
2964 | "RFC 1806 has been replaced by RFC2183" |
---|
2965 | </t> |
---|
2966 | </list> |
---|
2967 | </t> |
---|
2968 | <t> |
---|
2969 | Other changes: |
---|
2970 | <list style="symbols"> |
---|
2971 | <t> |
---|
2972 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/68"/>: |
---|
2973 | "Encoding References Normative" -- rephrase the annotation and reference |
---|
2974 | <xref target="BCP97"/>. |
---|
2975 | </t> |
---|
2976 | </list> |
---|
2977 | </t> |
---|
2978 | </section> |
---|
2979 | |
---|
2980 | <section title="Since draft-ietf-httpbis-p3-payload-04" anchor="changes.since.04"> |
---|
2981 | <t> |
---|
2982 | Closed issues: |
---|
2983 | <list style="symbols"> |
---|
2984 | <t> |
---|
2985 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>: |
---|
2986 | "RFC 2822 is updated by RFC 5322" |
---|
2987 | </t> |
---|
2988 | </list> |
---|
2989 | </t> |
---|
2990 | <t> |
---|
2991 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
2992 | <list style="symbols"> |
---|
2993 | <t> |
---|
2994 | Use "/" instead of "|" for alternatives. |
---|
2995 | </t> |
---|
2996 | <t> |
---|
2997 | Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
2998 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
2999 | </t> |
---|
3000 | <t> |
---|
3001 | Rewrite ABNFs to spell out whitespace rules, factor out |
---|
3002 | header value format definitions. |
---|
3003 | </t> |
---|
3004 | </list> |
---|
3005 | </t> |
---|
3006 | </section> |
---|
3007 | |
---|
3008 | <section title="Since draft-ietf-httpbis-p3-payload-05" anchor="changes.since.05"> |
---|
3009 | <t> |
---|
3010 | Closed issues: |
---|
3011 | <list style="symbols"> |
---|
3012 | <t> |
---|
3013 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/118"/>: |
---|
3014 | "Join "Differences Between HTTP Entities and RFC 2045 Entities"?" |
---|
3015 | </t> |
---|
3016 | </list> |
---|
3017 | </t> |
---|
3018 | <t> |
---|
3019 | Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
3020 | <list style="symbols"> |
---|
3021 | <t> |
---|
3022 | Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. |
---|
3023 | </t> |
---|
3024 | </list> |
---|
3025 | </t> |
---|
3026 | <t> |
---|
3027 | Other changes: |
---|
3028 | <list style="symbols"> |
---|
3029 | <t> |
---|
3030 | Move definition of quality values into Part 1. |
---|
3031 | </t> |
---|
3032 | </list> |
---|
3033 | </t> |
---|
3034 | </section> |
---|
3035 | |
---|
3036 | <section title="Since draft-ietf-httpbis-p3-payload-06" anchor="changes.since.06"> |
---|
3037 | <t> |
---|
3038 | Closed issues: |
---|
3039 | <list style="symbols"> |
---|
3040 | <t> |
---|
3041 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/80"/>: |
---|
3042 | "Content-Location isn't special" |
---|
3043 | </t> |
---|
3044 | <t> |
---|
3045 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>: |
---|
3046 | "Content Sniffing" |
---|
3047 | </t> |
---|
3048 | </list> |
---|
3049 | </t> |
---|
3050 | </section> |
---|
3051 | |
---|
3052 | <section title="Since draft-ietf-httpbis-p3-payload-07" anchor="changes.since.07"> |
---|
3053 | <t> |
---|
3054 | Closed issues: |
---|
3055 | <list style="symbols"> |
---|
3056 | <t> |
---|
3057 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/13"/>: |
---|
3058 | "Updated reference for language tags" |
---|
3059 | </t> |
---|
3060 | <t> |
---|
3061 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>: |
---|
3062 | "Clarify rules for determining what entities a response carries" |
---|
3063 | </t> |
---|
3064 | <t> |
---|
3065 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/154"/>: |
---|
3066 | "Content-Location base-setting problems" |
---|
3067 | </t> |
---|
3068 | <t> |
---|
3069 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>: |
---|
3070 | "Content Sniffing" |
---|
3071 | </t> |
---|
3072 | <t> |
---|
3073 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/188"/>: |
---|
3074 | "pick IANA policy (RFC5226) for Transfer Coding / Content Coding" |
---|
3075 | </t> |
---|
3076 | <t> |
---|
3077 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/189"/>: |
---|
3078 | "move definitions of gzip/deflate/compress to part 1" |
---|
3079 | </t> |
---|
3080 | </list> |
---|
3081 | </t> |
---|
3082 | <t> |
---|
3083 | Partly resolved issues: |
---|
3084 | <list style="symbols"> |
---|
3085 | <t> |
---|
3086 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/148"/>: |
---|
3087 | "update IANA requirements wrt Transfer-Coding values" (add the |
---|
3088 | IANA Considerations subsection) |
---|
3089 | </t> |
---|
3090 | <t> |
---|
3091 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/149"/>: |
---|
3092 | "update IANA requirements wrt Content-Coding values" (add the |
---|
3093 | IANA Considerations subsection) |
---|
3094 | </t> |
---|
3095 | </list> |
---|
3096 | </t> |
---|
3097 | </section> |
---|
3098 | |
---|
3099 | <section title="Since draft-ietf-httpbis-p3-payload-08" anchor="changes.since.08"> |
---|
3100 | <t> |
---|
3101 | Closed issues: |
---|
3102 | <list style="symbols"> |
---|
3103 | <t> |
---|
3104 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/81"/>: |
---|
3105 | "Content Negotiation for media types" |
---|
3106 | </t> |
---|
3107 | <t> |
---|
3108 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/181"/>: |
---|
3109 | "Accept-Language: which RFC4647 filtering?" |
---|
3110 | </t> |
---|
3111 | </list> |
---|
3112 | </t> |
---|
3113 | </section> |
---|
3114 | |
---|
3115 | <section title="Since draft-ietf-httpbis-p3-payload-09" anchor="changes.since.09"> |
---|
3116 | <t> |
---|
3117 | Closed issues: |
---|
3118 | <list style="symbols"> |
---|
3119 | <t> |
---|
3120 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/143"/>: |
---|
3121 | "IANA registry for content/transfer encodings" |
---|
3122 | </t> |
---|
3123 | <t> |
---|
3124 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/155"/>: |
---|
3125 | "Content Sniffing" |
---|
3126 | </t> |
---|
3127 | <t> |
---|
3128 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>: |
---|
3129 | "use of term "word" when talking about header structure" |
---|
3130 | </t> |
---|
3131 | </list> |
---|
3132 | </t> |
---|
3133 | <t> |
---|
3134 | Partly resolved issues: |
---|
3135 | <list style="symbols"> |
---|
3136 | <t> |
---|
3137 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: |
---|
3138 | "Term for the requested resource's URI" |
---|
3139 | </t> |
---|
3140 | </list> |
---|
3141 | </t> |
---|
3142 | </section> |
---|
3143 | |
---|
3144 | </section> |
---|
3145 | |
---|
3146 | </back> |
---|
3147 | </rfc> |
---|