Changeset 1644 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 30/03/12 15:28:57 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r1643 r1644 2164 2164 2165 2165 2166 <section title=" Common Protocol Parameters" anchor="common.protocol.parameters">2166 <section title="Protocol Parameters" anchor="protocol.parameters"> 2167 2167 <section title="Date/Time Formats" anchor="http.date"> 2168 2168 <x:anchor-alias value="HTTP-date"/> … … 2340 2340 the same product &SHOULD; only differ in the product-version portion of 2341 2341 the product value). 2342 </t> 2343 </section> 2344 2345 <section title="Character Encodings (charset)" anchor="character.sets"> 2346 <t> 2347 HTTP uses charset names to indicate the character encoding of a 2348 textual representation. 2349 </t> 2350 <t anchor="rule.charset"> 2351 <x:anchor-alias value="charset"/> 2352 A character encoding is identified by a case-insensitive token. The 2353 complete set of tokens is defined by the IANA Character Set registry 2354 (<eref target="http://www.iana.org/assignments/character-sets"/>). 2355 </t> 2356 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/> 2357 <x:ref>charset</x:ref> = <x:ref>token</x:ref> 2358 </artwork></figure> 2359 <t> 2360 Although HTTP allows an arbitrary token to be used as a charset 2361 value, any token that has a predefined value within the IANA 2362 Character Set registry &MUST; represent the character encoding defined 2363 by that registry. Applications &SHOULD; limit their use of character 2364 encodings to those defined within the IANA registry. 2365 </t> 2366 <t> 2367 HTTP uses charset in two contexts: within an Accept-Charset request 2368 header field (in which the charset value is an unquoted token) and as the 2369 value of a parameter in a Content-Type header field (within a request or 2370 response), in which case the parameter value of the charset parameter 2371 can be quoted. 2372 </t> 2373 <t> 2374 Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/> 2375 <xref target="RFC2277"/>. 2376 </t> 2377 </section> 2378 2379 <section title="Content Codings" anchor="content.codings"> 2380 <x:anchor-alias value="content-coding"/> 2381 <t> 2382 Content coding values indicate an encoding transformation that has 2383 been or can be applied to a representation. Content codings are primarily 2384 used to allow a representation to be compressed or otherwise usefully 2385 transformed without losing the identity of its underlying media type 2386 and without loss of information. Frequently, the representation is stored in 2387 coded form, transmitted directly, and only decoded by the recipient. 2388 </t> 2389 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/> 2390 <x:ref>content-coding</x:ref> = <x:ref>token</x:ref> 2391 </artwork></figure> 2392 <t> 2393 All content-coding values are case-insensitive. HTTP/1.1 uses 2394 content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and 2395 Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value 2396 describes the content-coding, what is more important is that it 2397 indicates what decoding mechanism will be required to remove the 2398 encoding. 2399 </t> 2400 <t> 2401 compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/> 2402 <list> 2403 <t> 2404 See &compress-coding;. 2405 </t> 2406 </list> 2407 </t> 2408 <t> 2409 deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/> 2410 <list> 2411 <t> 2412 See &deflate-coding;. 2413 </t> 2414 </list> 2415 </t> 2416 <t> 2417 gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/> 2418 <list> 2419 <t> 2420 See &gzip-coding;. 2421 </t> 2422 </list> 2423 </t> 2424 2425 <section title="Content Coding Registry" anchor="content.coding.registry"> 2426 <t> 2427 The HTTP Content Coding Registry defines the name space for the content 2428 coding names. 2429 </t> 2430 <t> 2431 Registrations &MUST; include the following fields: 2432 <list style="symbols"> 2433 <t>Name</t> 2434 <t>Description</t> 2435 <t>Pointer to specification text</t> 2436 </list> 2437 </t> 2438 <t> 2439 Names of content codings &MUST-NOT; overlap with names of transfer codings 2440 (&transfer-codings;), unless the encoding transformation is identical (as 2441 is the case for the compression codings defined in 2442 &compression-codings;). 2443 </t> 2444 <t> 2445 Values to be added to this name space require IETF Review 2446 (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST; 2447 conform to the purpose of content coding defined in this section. 2448 </t> 2449 <t> 2450 The registry itself is maintained at 2451 <eref target="http://www.iana.org/assignments/http-parameters"/>. 2452 </t> 2453 </section> 2454 2455 </section> 2456 2457 <section title="Media Types" anchor="media.types"> 2458 <x:anchor-alias value="media-type"/> 2459 <x:anchor-alias value="type"/> 2460 <x:anchor-alias value="subtype"/> 2461 <t> 2462 HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>) 2463 and Accept (<xref target="header.accept"/>) header fields in order to provide 2464 open and extensible data typing and type negotiation. 2465 </t> 2466 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/> 2467 <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> ) 2468 <x:ref>type</x:ref> = <x:ref>token</x:ref> 2469 <x:ref>subtype</x:ref> = <x:ref>token</x:ref> 2470 </artwork></figure> 2471 <t anchor="rule.parameter"> 2472 <x:anchor-alias value="attribute"/> 2473 <x:anchor-alias value="parameter"/> 2474 <x:anchor-alias value="value"/> 2475 The type/subtype &MAY; be followed by parameters in the form of 2476 attribute/value pairs. 2477 </t> 2478 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/> 2479 <x:ref>parameter</x:ref> = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref> 2480 <x:ref>attribute</x:ref> = <x:ref>token</x:ref> 2481 <x:ref>value</x:ref> = <x:ref>word</x:ref> 2482 </artwork></figure> 2483 <t> 2484 The type, subtype, and parameter attribute names are case-insensitive. 2485 Parameter values might or might not be case-sensitive, depending on the 2486 semantics of the parameter name. The presence or absence of a parameter might 2487 be significant to the processing of a media-type, depending on its 2488 definition within the media type registry. 2489 </t> 2490 <t> 2491 A parameter value that matches the <x:ref>token</x:ref> production can be 2492 transmitted as either a token or within a quoted-string. The quoted and 2493 unquoted values are equivalent. 2494 </t> 2495 <t> 2496 Note that some older HTTP applications do not recognize media type 2497 parameters. When sending data to older HTTP applications, 2498 implementations &SHOULD; only use media type parameters when they are 2499 required by that type/subtype definition. 2500 </t> 2501 <t> 2502 Media-type values are registered with the Internet Assigned Number 2503 Authority (IANA). The media type registration process is 2504 outlined in <xref target="RFC4288"/>. Use of non-registered media types is 2505 discouraged. 2506 </t> 2507 2508 <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults"> 2509 <t> 2510 Internet media types are registered with a canonical form. A 2511 representation transferred via HTTP messages &MUST; be in the 2512 appropriate canonical form prior to its transmission except for 2513 "text" types, as defined in the next paragraph. 2514 </t> 2515 <t> 2516 When in canonical form, media subtypes of the "text" type use CRLF as 2517 the text line break. HTTP relaxes this requirement and allows the 2518 transport of text media with plain CR or LF alone representing a line 2519 break when it is done consistently for an entire representation. HTTP 2520 applications &MUST; accept CRLF, bare CR, and bare LF as indicating 2521 a line break in text media received via HTTP. In 2522 addition, if the text is in a character encoding that does not 2523 use octets 13 and 10 for CR and LF respectively, as is the case for 2524 some multi-byte character encodings, HTTP allows the use of whatever octet 2525 sequences are defined by that character encoding to represent the 2526 equivalent of CR and LF for line breaks. This flexibility regarding 2527 line breaks applies only to text media in the payload body; a bare CR 2528 or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control 2529 structures (such as header fields and multipart boundaries). 2530 </t> 2531 <t> 2532 If a representation is encoded with a content-coding, the underlying 2533 data &MUST; be in a form defined above prior to being encoded. 2534 </t> 2535 </section> 2536 2537 <section title="Multipart Types" anchor="multipart.types"> 2538 <t> 2539 MIME provides for a number of "multipart" types — encapsulations of 2540 one or more representations within a single message body. All multipart 2541 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>, 2542 and &MUST; include a boundary parameter as part of the media type 2543 value. The message body is itself a protocol element and &MUST; 2544 therefore use only CRLF to represent line breaks between body-parts. 2545 </t> 2546 <t> 2547 In general, HTTP treats a multipart message body no differently than 2548 any other media type: strictly as payload. HTTP does not use the 2549 multipart boundary as an indicator of message body length. 2550 <!-- jre: re-insert removed text pointing to caching? --> 2551 In all other respects, an HTTP user agent &SHOULD; follow the same or similar 2552 behavior as a MIME user agent would upon receipt of a multipart type. 2553 The MIME header fields within each body-part of a multipart message body 2554 do not have any significance to HTTP beyond that defined by 2555 their MIME semantics. 2556 </t> 2557 <t> 2558 If an application receives an unrecognized multipart subtype, the 2559 application &MUST; treat it as being equivalent to "multipart/mixed". 2560 </t> 2561 <x:note> 2562 <t> 2563 <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined 2564 for carrying form data suitable for processing via the POST 2565 request method, as described in <xref target="RFC2388"/>. 2566 </t> 2567 </x:note> 2568 </section> 2569 </section> 2570 2571 <section title="Language Tags" anchor="language.tags"> 2572 <x:anchor-alias value="language-tag"/> 2573 <t> 2574 A language tag, as defined in <xref target="RFC5646"/>, identifies a 2575 natural language spoken, written, or otherwise conveyed by human beings for 2576 communication of information to other human beings. Computer languages are 2577 explicitly excluded. HTTP uses language tags within the Accept-Language and 2578 Content-Language fields. 2579 </t> 2580 <t> 2581 In summary, a language tag is composed of one or more parts: A primary 2582 language subtag followed by a possibly empty series of subtags: 2583 </t> 2584 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/> 2585 <x:ref>language-tag</x:ref> = <Language-Tag, defined in <xref target="RFC5646" x:sec="2.1"/>> 2586 </artwork></figure> 2587 <t> 2588 White space is not allowed within the tag and all tags are case-insensitive. 2589 The name space of language subtags is administered by the IANA (see 2590 <eref target="http://www.iana.org/assignments/language-subtag-registry"/>). 2591 </t> 2592 <figure> 2593 <preamble>Example tags include:</preamble> 2594 <artwork type="example"> 2595 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 2596 </artwork> 2597 </figure> 2598 <t> 2599 See <xref target="RFC5646"/> for further information. 2342 2600 </t> 2343 2601 </section> … … 4931 5189 4932 5190 <section title="THE TEXT FORMERLY KNOWN AS PART3"> 4933 <section title="Protocol Parameters" anchor="protocol.parameters">4934 4935 <section title="Character Encodings (charset)" anchor="character.sets">4936 <t>4937 HTTP uses charset names to indicate the character encoding of a4938 textual representation.4939 </t>4940 <t anchor="rule.charset">4941 <x:anchor-alias value="charset"/>4942 A character encoding is identified by a case-insensitive token. The4943 complete set of tokens is defined by the IANA Character Set registry4944 (<eref target="http://www.iana.org/assignments/character-sets"/>).4945 </t>4946 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>4947 <x:ref>charset</x:ref> = <x:ref>token</x:ref>4948 </artwork></figure>4949 <t>4950 Although HTTP allows an arbitrary token to be used as a charset4951 value, any token that has a predefined value within the IANA4952 Character Set registry &MUST; represent the character encoding defined4953 by that registry. Applications &SHOULD; limit their use of character4954 encodings to those defined within the IANA registry.4955 </t>4956 <t>4957 HTTP uses charset in two contexts: within an Accept-Charset request4958 header field (in which the charset value is an unquoted token) and as the4959 value of a parameter in a Content-Type header field (within a request or4960 response), in which case the parameter value of the charset parameter4961 can be quoted.4962 </t>4963 <t>4964 Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/>4965 <xref target="RFC2277"/>.4966 </t>4967 </section>4968 4969 <section title="Content Codings" anchor="content.codings">4970 <x:anchor-alias value="content-coding"/>4971 <t>4972 Content coding values indicate an encoding transformation that has4973 been or can be applied to a representation. Content codings are primarily4974 used to allow a representation to be compressed or otherwise usefully4975 transformed without losing the identity of its underlying media type4976 and without loss of information. Frequently, the representation is stored in4977 coded form, transmitted directly, and only decoded by the recipient.4978 </t>4979 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>4980 <x:ref>content-coding</x:ref> = <x:ref>token</x:ref>4981 </artwork></figure>4982 <t>4983 All content-coding values are case-insensitive. HTTP/1.1 uses4984 content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and4985 Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value4986 describes the content-coding, what is more important is that it4987 indicates what decoding mechanism will be required to remove the4988 encoding.4989 </t>4990 <t>4991 compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/>4992 <list>4993 <t>4994 See &compress-coding;.4995 </t>4996 </list>4997 </t>4998 <t>4999 deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/>5000 <list>5001 <t>5002 See &deflate-coding;.5003 </t>5004 </list>5005 </t>5006 <t>5007 gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/>5008 <list>5009 <t>5010 See &gzip-coding;.5011 </t>5012 </list>5013 </t>5014 5015 <section title="Content Coding Registry" anchor="content.coding.registry">5016 <t>5017 The HTTP Content Coding Registry defines the name space for the content5018 coding names.5019 </t>5020 <t>5021 Registrations &MUST; include the following fields:5022 <list style="symbols">5023 <t>Name</t>5024 <t>Description</t>5025 <t>Pointer to specification text</t>5026 </list>5027 </t>5028 <t>5029 Names of content codings &MUST-NOT; overlap with names of transfer codings5030 (&transfer-codings;), unless the encoding transformation is identical (as5031 is the case for the compression codings defined in5032 &compression-codings;).5033 </t>5034 <t>5035 Values to be added to this name space require IETF Review5036 (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;5037 conform to the purpose of content coding defined in this section.5038 </t>5039 <t>5040 The registry itself is maintained at5041 <eref target="http://www.iana.org/assignments/http-parameters"/>.5042 </t>5043 </section>5044 5045 </section>5046 5047 <section title="Media Types" anchor="media.types">5048 <x:anchor-alias value="media-type"/>5049 <x:anchor-alias value="type"/>5050 <x:anchor-alias value="subtype"/>5051 <t>5052 HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>)5053 and Accept (<xref target="header.accept"/>) header fields in order to provide5054 open and extensible data typing and type negotiation.5055 </t>5056 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>5057 <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )5058 <x:ref>type</x:ref> = <x:ref>token</x:ref>5059 <x:ref>subtype</x:ref> = <x:ref>token</x:ref>5060 </artwork></figure>5061 <t anchor="rule.parameter">5062 <x:anchor-alias value="attribute"/>5063 <x:anchor-alias value="parameter"/>5064 <x:anchor-alias value="value"/>5065 The type/subtype &MAY; be followed by parameters in the form of5066 attribute/value pairs.5067 </t>5068 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>5069 <x:ref>parameter</x:ref> = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref>5070 <x:ref>attribute</x:ref> = <x:ref>token</x:ref>5071 <x:ref>value</x:ref> = <x:ref>word</x:ref>5072 </artwork></figure>5073 <t>5074 The type, subtype, and parameter attribute names are case-insensitive.5075 Parameter values might or might not be case-sensitive, depending on the5076 semantics of the parameter name. The presence or absence of a parameter might5077 be significant to the processing of a media-type, depending on its5078 definition within the media type registry.5079 </t>5080 <t>5081 A parameter value that matches the <x:ref>token</x:ref> production can be5082 transmitted as either a token or within a quoted-string. The quoted and5083 unquoted values are equivalent.5084 </t>5085 <t>5086 Note that some older HTTP applications do not recognize media type5087 parameters. When sending data to older HTTP applications,5088 implementations &SHOULD; only use media type parameters when they are5089 required by that type/subtype definition.5090 </t>5091 <t>5092 Media-type values are registered with the Internet Assigned Number5093 Authority (IANA). The media type registration process is5094 outlined in <xref target="RFC4288"/>. Use of non-registered media types is5095 discouraged.5096 </t>5097 5098 <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">5099 <t>5100 Internet media types are registered with a canonical form. A5101 representation transferred via HTTP messages &MUST; be in the5102 appropriate canonical form prior to its transmission except for5103 "text" types, as defined in the next paragraph.5104 </t>5105 <t>5106 When in canonical form, media subtypes of the "text" type use CRLF as5107 the text line break. HTTP relaxes this requirement and allows the5108 transport of text media with plain CR or LF alone representing a line5109 break when it is done consistently for an entire representation. HTTP5110 applications &MUST; accept CRLF, bare CR, and bare LF as indicating5111 a line break in text media received via HTTP. In5112 addition, if the text is in a character encoding that does not5113 use octets 13 and 10 for CR and LF respectively, as is the case for5114 some multi-byte character encodings, HTTP allows the use of whatever octet5115 sequences are defined by that character encoding to represent the5116 equivalent of CR and LF for line breaks. This flexibility regarding5117 line breaks applies only to text media in the payload body; a bare CR5118 or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control5119 structures (such as header fields and multipart boundaries).5120 </t>5121 <t>5122 If a representation is encoded with a content-coding, the underlying5123 data &MUST; be in a form defined above prior to being encoded.5124 </t>5125 </section>5126 5127 <section title="Multipart Types" anchor="multipart.types">5128 <t>5129 MIME provides for a number of "multipart" types — encapsulations of5130 one or more representations within a single message body. All multipart5131 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,5132 and &MUST; include a boundary parameter as part of the media type5133 value. The message body is itself a protocol element and &MUST;5134 therefore use only CRLF to represent line breaks between body-parts.5135 </t>5136 <t>5137 In general, HTTP treats a multipart message body no differently than5138 any other media type: strictly as payload. HTTP does not use the5139 multipart boundary as an indicator of message body length.5140 <!-- jre: re-insert removed text pointing to caching? -->5141 In all other respects, an HTTP user agent &SHOULD; follow the same or similar5142 behavior as a MIME user agent would upon receipt of a multipart type.5143 The MIME header fields within each body-part of a multipart message body5144 do not have any significance to HTTP beyond that defined by5145 their MIME semantics.5146 </t>5147 <t>5148 If an application receives an unrecognized multipart subtype, the5149 application &MUST; treat it as being equivalent to "multipart/mixed".5150 </t>5151 <x:note>5152 <t>5153 <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined5154 for carrying form data suitable for processing via the POST5155 request method, as described in <xref target="RFC2388"/>.5156 </t>5157 </x:note>5158 </section>5159 </section>5160 5161 <section title="Language Tags" anchor="language.tags">5162 <x:anchor-alias value="language-tag"/>5163 <t>5164 A language tag, as defined in <xref target="RFC5646"/>, identifies a5165 natural language spoken, written, or otherwise conveyed by human beings for5166 communication of information to other human beings. Computer languages are5167 explicitly excluded. HTTP uses language tags within the Accept-Language and5168 Content-Language fields.5169 </t>5170 <t>5171 In summary, a language tag is composed of one or more parts: A primary5172 language subtag followed by a possibly empty series of subtags:5173 </t>5174 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/>5175 <x:ref>language-tag</x:ref> = <Language-Tag, defined in <xref target="RFC5646" x:sec="2.1"/>>5176 </artwork></figure>5177 <t>5178 White space is not allowed within the tag and all tags are case-insensitive.5179 The name space of language subtags is administered by the IANA (see5180 <eref target="http://www.iana.org/assignments/language-subtag-registry"/>).5181 </t>5182 <figure>5183 <preamble>Example tags include:</preamble>5184 <artwork type="example">5185 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN5186 </artwork>5187 </figure>5188 <t>5189 See <xref target="RFC5646"/> for further information.5190 </t>5191 </section>5192 </section>5193 5191 5194 5192 <section title="Payload" anchor="payload">
Note: See TracChangeset
for help on using the changeset viewer.