Changeset 1538 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 18/02/12 10:29:16 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1537 r1538 1559 1559 The message-body differs from the payload body only when a transfer-coding 1560 1560 has been applied, as indicated by the Transfer-Encoding header field 1561 (<xref target="header.transfer-encoding"/>). If more than one 1561 (<xref target="header.transfer-encoding"/>). 1562 </t> 1563 <t> 1564 The rules for when a message-body is allowed in a message differ for 1565 requests and responses. 1566 </t> 1567 <t> 1568 The presence of a message-body in a request is signaled by the 1569 inclusion of a Content-Length or Transfer-Encoding header field in 1570 the request's header fields, even if the request method does not 1571 define any use for a message-body. This allows the request 1572 message framing algorithm to be independent of method semantics. 1573 </t> 1574 <t> 1575 For response messages, whether or not a message-body is included with 1576 a message is dependent on both the request method and the response 1577 status code (<xref target="status.code"/>). 1578 Responses to the HEAD request method never include a message-body 1579 because the associated response header fields (e.g., Transfer-Encoding, 1580 Content-Length, etc.) only indicate what their values would have been 1581 if the request method had been GET. All 1xx (Informational), 204 (No Content), 1582 and 304 (Not Modified) responses &MUST-NOT; include a message-body. 1583 All other responses do include a message-body, although the body 1584 &MAY; be of zero length. 1585 </t> 1586 1587 <section title="Transfer-Encoding" anchor="header.transfer-encoding"> 1588 <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/> 1589 <iref primary="true" item="Header Fields" subitem="Transfer-Encoding" x:for-anchor=""/> 1590 <x:anchor-alias value="Transfer-Encoding"/> 1591 <t> 1592 The "Transfer-Encoding" header field indicates what transfer-codings 1593 (if any) have been applied to the message body. It differs from 1594 Content-Encoding (&content-codings;) in that transfer-codings are a property 1595 of the message (and therefore are removed by intermediaries), whereas 1596 content-codings are not. 1597 </t> 1598 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/> 1599 <x:ref>Transfer-Encoding</x:ref> = 1#<x:ref>transfer-coding</x:ref> 1600 </artwork></figure> 1601 <t> 1602 Transfer-codings are defined in <xref target="transfer.codings"/>. An example is: 1603 </t> 1604 <figure><artwork type="example"> 1605 Transfer-Encoding: chunked 1606 </artwork></figure> 1607 <t> 1608 If multiple encodings have been applied to a representation, the transfer-codings 1609 &MUST; be listed in the order in which they were applied. 1610 Additional information about the encoding parameters &MAY; be provided 1611 by other header fields not defined by this specification. 1612 </t> 1613 <t> 1614 Many older HTTP/1.0 applications do not understand the Transfer-Encoding 1615 header field. 1616 </t> 1617 <t> 1618 If more than one 1562 1619 Transfer-Encoding header field is present in a message, the multiple 1563 1620 field-values &MUST; be combined into one field-value, according to the … … 1572 1629 any implementation along the request/response chain under the constraints 1573 1630 found in <xref target="transfer.codings"/>. 1631 </t> 1632 </section> 1633 1634 <section title="Content-Length" anchor="header.content-length"> 1635 <iref primary="true" item="Content-Length header field" x:for-anchor=""/> 1636 <iref primary="true" item="Header Fields" subitem="Content-Length" x:for-anchor=""/> 1637 <x:anchor-alias value="Content-Length"/> 1638 <t> 1639 The "Content-Length" header field indicates the size of the 1640 message-body, in decimal number of octets, for any message other than 1641 a response to a HEAD request or a response with a status code of 304. 1642 In the case of a response to a HEAD request, Content-Length indicates 1643 the size of the payload body (not including any potential transfer-coding) 1644 that would have been sent had the request been a GET. 1645 In the case of a 304 (Not Modified) response to a GET request, 1646 Content-Length indicates the size of the payload body (not including 1647 any potential transfer-coding) that would have been sent in a 200 (OK) 1648 response. 1649 </t> 1650 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/> 1651 <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref> 1652 </artwork></figure> 1653 <t> 1654 An example is 1655 </t> 1656 <figure><artwork type="example"> 1657 Content-Length: 3495 1658 </artwork></figure> 1659 <t> 1660 Implementations &SHOULD; use this field to indicate the message-body 1661 length when no transfer-coding is being applied and the 1662 payload's body length can be determined prior to being transferred. 1663 <xref target="message.body"/> describes how recipients determine the length 1664 of a message-body. 1665 </t> 1666 <t> 1667 Any Content-Length greater than or equal to zero is a valid value. 1668 </t> 1669 <t> 1670 Note that the use of this field in HTTP is significantly different from 1671 the corresponding definition in MIME, where it is an optional field 1672 used within the "message/external-body" content-type. 1574 1673 </t> 1575 1674 <t> … … 1585 1684 length. 1586 1685 </t> 1587 <t> 1588 The rules for when a message-body is allowed in a message differ for 1589 requests and responses. 1590 </t> 1591 <t> 1592 The presence of a message-body in a request is signaled by the 1593 inclusion of a Content-Length or Transfer-Encoding header field in 1594 the request's header fields, even if the request method does not 1595 define any use for a message-body. This allows the request 1596 message framing algorithm to be independent of method semantics. 1597 </t> 1598 <t> 1599 For response messages, whether or not a message-body is included with 1600 a message is dependent on both the request method and the response 1601 status code (<xref target="status.code"/>). 1602 Responses to the HEAD request method never include a message-body 1603 because the associated response header fields (e.g., Transfer-Encoding, 1604 Content-Length, etc.) only indicate what their values would have been 1605 if the request method had been GET. All 1xx (Informational), 204 (No Content), 1606 and 304 (Not Modified) responses &MUST-NOT; include a message-body. 1607 All other responses do include a message-body, although the body 1608 &MAY; be of zero length. 1609 </t> 1686 </section> 1687 1688 <section title="Message Body Length" anchor="message.body.length"> 1610 1689 <t> 1611 1690 The length of the message-body is determined by one of the following … … 1717 1796 </t> 1718 1797 </section> 1798 </section> 1719 1799 1720 1800 <section anchor="incomplete.messages" title="Handling Incomplete Messages"> … … 2051 2131 </section> 2052 2132 2053 2054 <section title="Protocol Parameters" anchor="protocol.parameters">2055 2056 2133 <section title="Transfer Codings" anchor="transfer.codings"> 2057 2134 <x:anchor-alias value="transfer-coding"/> … … 2313 2390 </t> 2314 2391 </section> 2315 </section> 2316 2317 <section title="Product Tokens" anchor="product.tokens"> 2318 <x:anchor-alias value="product"/> 2319 <x:anchor-alias value="product-version"/> 2320 <t> 2321 Product tokens are used to allow communicating applications to 2322 identify themselves by software name and version. Most fields using 2323 product tokens also allow sub-products which form a significant part 2324 of the application to be listed, separated by whitespace. By 2325 convention, the products are listed in order of their significance 2326 for identifying the application. 2327 </t> 2328 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/> 2329 <x:ref>product</x:ref> = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>] 2330 <x:ref>product-version</x:ref> = <x:ref>token</x:ref> 2392 2393 <section title="TE" anchor="header.te"> 2394 <iref primary="true" item="TE header field" x:for-anchor=""/> 2395 <iref primary="true" item="Header Fields" subitem="TE" x:for-anchor=""/> 2396 <x:anchor-alias value="TE"/> 2397 <x:anchor-alias value="t-codings"/> 2398 <x:anchor-alias value="te-params"/> 2399 <x:anchor-alias value="te-ext"/> 2400 <t> 2401 The "TE" header field indicates what extension transfer-codings 2402 the client is willing to accept in the response, and whether or not it is 2403 willing to accept trailer fields in a chunked transfer-coding. 2404 </t> 2405 <t> 2406 Its value consists of the keyword "trailers" and/or a comma-separated 2407 list of extension transfer-coding names with optional accept 2408 parameters (as described in <xref target="transfer.codings"/>). 2409 </t> 2410 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/> 2411 <x:ref>TE</x:ref> = #<x:ref>t-codings</x:ref> 2412 <x:ref>t-codings</x:ref> = "trailers" / ( <x:ref>transfer-extension</x:ref> [ <x:ref>te-params</x:ref> ] ) 2413 <x:ref>te-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>te-ext</x:ref> ) 2414 <x:ref>te-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ] 2331 2415 </artwork></figure> 2332 2416 <t> 2333 Examples: 2417 The presence of the keyword "trailers" indicates that the client is 2418 willing to accept trailer fields in a chunked transfer-coding, as 2419 defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with 2420 transfer-coding values even though it does not itself represent a 2421 transfer-coding. 2422 </t> 2423 <t> 2424 Examples of its use are: 2334 2425 </t> 2335 2426 <figure><artwork type="example"> 2336 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2337 Server: Apache/0.8.4 2427 TE: deflate 2428 TE: 2429 TE: trailers, deflate;q=0.5 2338 2430 </artwork></figure> 2339 2431 <t> 2340 Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be 2341 used for advertising or other non-essential information. Although any 2342 token octet &MAY; appear in a product-version, this token &SHOULD; 2343 only be used for a version identifier (i.e., successive versions of 2344 the same product &SHOULD; only differ in the product-version portion of 2345 the product value). 2346 </t> 2347 </section> 2432 The TE header field only applies to the immediate connection. 2433 Therefore, the keyword &MUST; be supplied within a Connection header 2434 field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message. 2435 </t> 2436 <t> 2437 A server tests whether a transfer-coding is acceptable, according to 2438 a TE field, using these rules: 2439 <list style="numbers"> 2440 <x:lt> 2441 <t>The "chunked" transfer-coding is always acceptable. If the 2442 keyword "trailers" is listed, the client indicates that it is 2443 willing to accept trailer fields in the chunked response on 2444 behalf of itself and any downstream clients. The implication is 2445 that, if given, the client is stating that either all 2446 downstream clients are willing to accept trailer fields in the 2447 forwarded response, or that it will attempt to buffer the 2448 response on behalf of downstream recipients. 2449 </t><t> 2450 <x:h>Note:</x:h> HTTP/1.1 does not define any means to limit the size of a 2451 chunked response such that a client can be assured of buffering 2452 the entire response.</t> 2453 </x:lt> 2454 <x:lt> 2455 <t>If the transfer-coding being tested is one of the transfer-codings 2456 listed in the TE field, then it is acceptable unless it 2457 is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a 2458 qvalue of 0 means "not acceptable".)</t> 2459 </x:lt> 2460 <x:lt> 2461 <t>If multiple transfer-codings are acceptable, then the 2462 acceptable transfer-coding with the highest non-zero qvalue is 2463 preferred. The "chunked" transfer-coding always has a qvalue 2464 of 1.</t> 2465 </x:lt> 2466 </list> 2467 </t> 2468 <t> 2469 If the TE field-value is empty or if no TE field is present, the only 2470 acceptable transfer-coding is "chunked". A message with no transfer-coding is 2471 always acceptable. 2472 </t> 2348 2473 2349 2474 <section title="Quality Values" anchor="quality.values"> … … 2372 2497 </x:note> 2373 2498 </section> 2374 2499 </section> 2500 2501 <section title="Trailer" anchor="header.trailer"> 2502 <iref primary="true" item="Trailer header field" x:for-anchor=""/> 2503 <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/> 2504 <x:anchor-alias value="Trailer"/> 2505 <t> 2506 The "Trailer" header field indicates that the given set of 2507 header fields is present in the trailer of a message encoded with 2508 chunked transfer-coding. 2509 </t> 2510 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/> 2511 <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref> 2512 </artwork></figure> 2513 <t> 2514 An HTTP/1.1 message &SHOULD; include a Trailer header field in a 2515 message using chunked transfer-coding with a non-empty trailer. Doing 2516 so allows the recipient to know which header fields to expect in the 2517 trailer. 2518 </t> 2519 <t> 2520 If no Trailer header field is present, the trailer &SHOULD-NOT; include 2521 any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of 2522 trailer fields in a "chunked" transfer-coding. 2523 </t> 2524 <t> 2525 Message header fields listed in the Trailer header field &MUST-NOT; 2526 include the following header fields: 2527 <list style="symbols"> 2528 <t>Transfer-Encoding</t> 2529 <t>Content-Length</t> 2530 <t>Trailer</t> 2531 </list> 2532 </t> 2533 </section> 2375 2534 </section> 2376 2535 … … 2998 3157 </section> 2999 3158 3000 <section title="Content-Length" anchor="header.content-length">3001 <iref primary="true" item="Content-Length header field" x:for-anchor=""/>3002 <iref primary="true" item="Header Fields" subitem="Content-Length" x:for-anchor=""/>3003 <x:anchor-alias value="Content-Length"/>3004 <t>3005 The "Content-Length" header field indicates the size of the3006 message-body, in decimal number of octets, for any message other than3007 a response to a HEAD request or a response with a status code of 304.3008 In the case of a response to a HEAD request, Content-Length indicates3009 the size of the payload body (not including any potential transfer-coding)3010 that would have been sent had the request been a GET.3011 In the case of a 304 (Not Modified) response to a GET request,3012 Content-Length indicates the size of the payload body (not including3013 any potential transfer-coding) that would have been sent in a 200 (OK)3014 response.3015 </t>3016 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>3017 <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref>3018 </artwork></figure>3019 <t>3020 An example is3021 </t>3022 <figure><artwork type="example">3023 Content-Length: 34953024 </artwork></figure>3025 <t>3026 Implementations &SHOULD; use this field to indicate the message-body3027 length when no transfer-coding is being applied and the3028 payload's body length can be determined prior to being transferred.3029 <xref target="message.body"/> describes how recipients determine the length3030 of a message-body.3031 </t>3032 <t>3033 Any Content-Length greater than or equal to zero is a valid value.3034 </t>3035 <t>3036 Note that the use of this field in HTTP is significantly different from3037 the corresponding definition in MIME, where it is an optional field3038 used within the "message/external-body" content-type.3039 </t>3040 </section>3041 3042 3159 <section title="Host" anchor="header.host"> 3043 3160 <iref primary="true" item="Host header field" x:for-anchor=""/> … … 3109 3226 </section> 3110 3227 3111 <section title="TE" anchor="header.te">3112 <iref primary="true" item="TE header field" x:for-anchor=""/>3113 <iref primary="true" item="Header Fields" subitem="TE" x:for-anchor=""/>3114 <x:anchor-alias value="TE"/>3115 <x:anchor-alias value="t-codings"/>3116 <x:anchor-alias value="te-params"/>3117 <x:anchor-alias value="te-ext"/>3118 <t>3119 The "TE" header field indicates what extension transfer-codings3120 the client is willing to accept in the response, and whether or not it is3121 willing to accept trailer fields in a chunked transfer-coding.3122 </t>3123 <t>3124 Its value consists of the keyword "trailers" and/or a comma-separated3125 list of extension transfer-coding names with optional accept3126 parameters (as described in <xref target="transfer.codings"/>).3127 </t>3128 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/>3129 <x:ref>TE</x:ref> = #<x:ref>t-codings</x:ref>3130 <x:ref>t-codings</x:ref> = "trailers" / ( <x:ref>transfer-extension</x:ref> [ <x:ref>te-params</x:ref> ] )3131 <x:ref>te-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>te-ext</x:ref> )3132 <x:ref>te-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]3133 </artwork></figure>3134 <t>3135 The presence of the keyword "trailers" indicates that the client is3136 willing to accept trailer fields in a chunked transfer-coding, as3137 defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with3138 transfer-coding values even though it does not itself represent a3139 transfer-coding.3140 </t>3141 <t>3142 Examples of its use are:3143 </t>3144 <figure><artwork type="example">3145 TE: deflate3146 TE:3147 TE: trailers, deflate;q=0.53148 </artwork></figure>3149 <t>3150 The TE header field only applies to the immediate connection.3151 Therefore, the keyword &MUST; be supplied within a Connection header3152 field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.3153 </t>3154 <t>3155 A server tests whether a transfer-coding is acceptable, according to3156 a TE field, using these rules:3157 <list style="numbers">3158 <x:lt>3159 <t>The "chunked" transfer-coding is always acceptable. If the3160 keyword "trailers" is listed, the client indicates that it is3161 willing to accept trailer fields in the chunked response on3162 behalf of itself and any downstream clients. The implication is3163 that, if given, the client is stating that either all3164 downstream clients are willing to accept trailer fields in the3165 forwarded response, or that it will attempt to buffer the3166 response on behalf of downstream recipients.3167 </t><t>3168 <x:h>Note:</x:h> HTTP/1.1 does not define any means to limit the size of a3169 chunked response such that a client can be assured of buffering3170 the entire response.</t>3171 </x:lt>3172 <x:lt>3173 <t>If the transfer-coding being tested is one of the transfer-codings3174 listed in the TE field, then it is acceptable unless it3175 is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a3176 qvalue of 0 means "not acceptable".)</t>3177 </x:lt>3178 <x:lt>3179 <t>If multiple transfer-codings are acceptable, then the3180 acceptable transfer-coding with the highest non-zero qvalue is3181 preferred. The "chunked" transfer-coding always has a qvalue3182 of 1.</t>3183 </x:lt>3184 </list>3185 </t>3186 <t>3187 If the TE field-value is empty or if no TE field is present, the only3188 acceptable transfer-coding is "chunked". A message with no transfer-coding is3189 always acceptable.3190 </t>3191 </section>3192 3193 <section title="Trailer" anchor="header.trailer">3194 <iref primary="true" item="Trailer header field" x:for-anchor=""/>3195 <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/>3196 <x:anchor-alias value="Trailer"/>3197 <t>3198 The "Trailer" header field indicates that the given set of3199 header fields is present in the trailer of a message encoded with3200 chunked transfer-coding.3201 </t>3202 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>3203 <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>3204 </artwork></figure>3205 <t>3206 An HTTP/1.1 message &SHOULD; include a Trailer header field in a3207 message using chunked transfer-coding with a non-empty trailer. Doing3208 so allows the recipient to know which header fields to expect in the3209 trailer.3210 </t>3211 <t>3212 If no Trailer header field is present, the trailer &SHOULD-NOT; include3213 any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of3214 trailer fields in a "chunked" transfer-coding.3215 </t>3216 <t>3217 Message header fields listed in the Trailer header field &MUST-NOT;3218 include the following header fields:3219 <list style="symbols">3220 <t>Transfer-Encoding</t>3221 <t>Content-Length</t>3222 <t>Trailer</t>3223 </list>3224 </t>3225 </section>3226 3227 <section title="Transfer-Encoding" anchor="header.transfer-encoding">3228 <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/>3229 <iref primary="true" item="Header Fields" subitem="Transfer-Encoding" x:for-anchor=""/>3230 <x:anchor-alias value="Transfer-Encoding"/>3231 <t>3232 The "Transfer-Encoding" header field indicates what transfer-codings3233 (if any) have been applied to the message body. It differs from3234 Content-Encoding (&content-codings;) in that transfer-codings are a property3235 of the message (and therefore are removed by intermediaries), whereas3236 content-codings are not.3237 </t>3238 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>3239 <x:ref>Transfer-Encoding</x:ref> = 1#<x:ref>transfer-coding</x:ref>3240 </artwork></figure>3241 <t>3242 Transfer-codings are defined in <xref target="transfer.codings"/>. An example is:3243 </t>3244 <figure><artwork type="example">3245 Transfer-Encoding: chunked3246 </artwork></figure>3247 <t>3248 If multiple encodings have been applied to a representation, the transfer-codings3249 &MUST; be listed in the order in which they were applied.3250 Additional information about the encoding parameters &MAY; be provided3251 by other header fields not defined by this specification.3252 </t>3253 <t>3254 Many older HTTP/1.0 applications do not understand the Transfer-Encoding3255 header field.3256 </t>3257 </section>3258 3259 3228 <section title="Upgrade" anchor="header.upgrade"> 3260 3229 <iref primary="true" item="Upgrade header field" x:for-anchor=""/> 3261 3230 <iref primary="true" item="Header Fields" subitem="Upgrade" x:for-anchor=""/> 3262 3231 <x:anchor-alias value="Upgrade"/> 3232 <x:anchor-alias value="protocol"/> 3233 <x:anchor-alias value="protocol-name"/> 3234 <x:anchor-alias value="protocol-version"/> 3263 3235 <t> 3264 3236 The "Upgrade" header field allows the client to specify what … … 3268 3240 </t> 3269 3241 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/> 3270 <x:ref>Upgrade</x:ref> = 1#<x:ref>product</x:ref> 3242 <x:ref>Upgrade</x:ref> = 1#<x:ref>protocol</x:ref> 3243 3244 <x:ref>protocol</x:ref> = <x:ref>protocol-name</x:ref> ["/" <x:ref>protocol-version</x:ref>] 3245 <x:ref>protocol-name</x:ref> = <x:ref>token</x:ref> 3246 <x:ref>protocol-version</x:ref> = <x:ref>token</x:ref> 3271 3247 </artwork></figure> 3272 3248 <t> … … 3328 3304 <section title="Upgrade Token Registry" anchor="upgrade.token.registry"> 3329 3305 <t> 3330 The HTTP Upgrade Token Registry defines the name space for pro duct3306 The HTTP Upgrade Token Registry defines the name space for protocol-name 3331 3307 tokens used to identify protocols in the Upgrade header field. 3332 Each registered tokenis associated with contact information and3308 Each registered protocol-name is associated with contact information and 3333 3309 an optional set of specifications that details how the connection 3334 3310 will be processed after it has been upgraded. … … 3340 3316 Registrations are subject to the following rules: 3341 3317 <list style="numbers"> 3342 <t>A token, once registered, stays registered forever.</t>3318 <t>A protocol-name token, once registered, stays registered forever.</t> 3343 3319 <t>The registration &MUST; name a responsible party for the 3344 3320 registration.</t> 3345 3321 <t>The registration &MUST; name a point of contact.</t> 3346 <t>The registration &MAY; name a set of specifications associated with that 3347 token. Such specifications need not be publicly available.</t> 3322 <t>The registration &MAY; name a set of specifications associated with 3323 that token. Such specifications need not be publicly available.</t> 3324 <t>The registration &SHOULD; name a set of expected "protocol-version" 3325 tokens associated with that token at the time of registration.</t> 3348 3326 <t>The responsible party &MAY; change the registration at any time. 3349 3327 The IANA will keep a record of all such changes, and make them 3350 3328 available upon request.</t> 3351 <t>The responsible party for the first registration of a "product" 3352 token &MUST; approve later registrations of a "version" token 3353 together with that "product" token before they can be registered.</t> 3354 <t>If absolutely required, the IESG &MAY; reassign the responsibility 3355 for a token. This will normally only be used in the case when a 3329 <t>The IESG &MAY; reassign responsibility for a protocol token. 3330 This will normally only be used in the case when a 3356 3331 responsible party cannot be contacted.</t> 3357 3332 </list> … … 3365 3340 <iref primary="true" item="Via header field" x:for-anchor=""/> 3366 3341 <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/> 3367 <x:anchor-alias value="protocol-name"/>3368 <x:anchor-alias value="protocol-version"/>3369 3342 <x:anchor-alias value="pseudonym"/> 3370 3343 <x:anchor-alias value="received-by"/> … … 3385 3358 [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] ) 3386 3359 <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref> 3387 <x:ref>protocol-name</x:ref> = <x:ref>token</x:ref>3388 <x:ref>protocol-version</x:ref> = <x:ref>token</x:ref>3389 3360 <x:ref>received-by</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref> 3390 3361 <x:ref>pseudonym</x:ref> = <x:ref>token</x:ref> … … 5082 5053 5083 5054 <x:ref>URI-reference</x:ref> = <URI-reference, defined in [RFC3986], Section 4.1> 5084 <x:ref>Upgrade</x:ref> = *( "," OWS ) pro duct *( OWS "," [ OWS product] )5055 <x:ref>Upgrade</x:ref> = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) 5085 5056 5086 5057 <x:ref>Via</x:ref> = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] … … 5124 5095 <x:ref>path-absolute</x:ref> = <path-absolute, defined in [RFC3986], Section 3.3> 5125 5096 <x:ref>port</x:ref> = <port, defined in [RFC3986], Section 3.2.3> 5126 <x:ref>product</x:ref> = token [ "/" product-version ] 5127 <x:ref>product-version</x:ref> = token 5097 <x:ref>protocol</x:ref> = protocol-name [ "/" protocol-version ] 5128 5098 <x:ref>protocol-name</x:ref> = token 5129 5099 <x:ref>protocol-version</x:ref> = token
Note: See TracChangeset
for help on using the changeset viewer.