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