Ignore:
Timestamp:
18/02/12 10:29:16 (9 years ago)
Author:
fielding@…
Message:

Move definitions of Transfer-Encoding and Content-Length to where
they are first used. Move other transfer encoding stuff (codings,
TE, and Trailers) to its own section. Moved text is unchanged.
Make Upgrade use protocol tokens instead of product tokens (WTF?)
and move product tokens to p2. Reduce protocol registry requirements.
Removed now-empty section on protocol parameters.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1537 r1538  
    15591559   The message-body differs from the payload body only when a transfer-coding
    15601560   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
    15621619   Transfer-Encoding header field is present in a message, the multiple
    15631620   field-values &MUST; be combined into one field-value, according to the
    … …  
    15721629   any implementation along the request/response chain under the constraints
    15731630   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.
    15741673</t>
    15751674<t>
    … …  
    15851684   length.
    15861685</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">
    16101689<t>
    16111690   The length of the message-body is determined by one of the following
    … …  
    17171796</t>
    17181797</section>
     1798</section>
    17191799
    17201800<section anchor="incomplete.messages" title="Handling Incomplete Messages">
    … …  
    20512131</section>
    20522132
    2053 
    2054 <section title="Protocol Parameters" anchor="protocol.parameters">
    2055 
    20562133<section title="Transfer Codings" anchor="transfer.codings">
    20572134  <x:anchor-alias value="transfer-coding"/>
    … …  
    23132390</t>
    23142391</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> ]
    23312415</artwork></figure>
    23322416<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:
    23342425</t>
    23352426<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
    23382430</artwork></figure>
    23392431<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>
    23482473
    23492474<section title="Quality Values" anchor="quality.values">
    … …  
    23722497</x:note>
    23732498</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>
    23752534</section>
    23762535
    … …  
    29983157</section>
    29993158
    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 the
    3006    message-body, in decimal number of octets, for any message other than
    3007    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 indicates
    3009    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 including
    3013    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 is
    3021 </t>
    3022 <figure><artwork type="example">
    3023   Content-Length: 3495
    3024 </artwork></figure>
    3025 <t>
    3026    Implementations &SHOULD; use this field to indicate the message-body
    3027    length when no transfer-coding is being applied and the
    3028    payload's body length can be determined prior to being transferred.
    3029    <xref target="message.body"/> describes how recipients determine the length
    3030    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 from
    3037    the corresponding definition in MIME, where it is an optional field
    3038    used within the "message/external-body" content-type.
    3039 </t>
    3040 </section>
    3041 
    30423159<section title="Host" anchor="header.host">
    30433160  <iref primary="true" item="Host header field" x:for-anchor=""/>
    … …  
    31093226</section>
    31103227
    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-codings
    3120    the client is willing to accept in the response, and whether or not it is
    3121    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-separated
    3125    list of extension transfer-coding names with optional accept
    3126    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 is
    3136    willing to accept trailer fields in a chunked transfer-coding, as
    3137    defined in <xref target="chunked.encoding"/>. This keyword is reserved for use with
    3138    transfer-coding values even though it does not itself represent a
    3139    transfer-coding.
    3140 </t>
    3141 <t>
    3142    Examples of its use are:
    3143 </t>
    3144 <figure><artwork type="example">
    3145   TE: deflate
    3146   TE:
    3147   TE: trailers, deflate;q=0.5
    3148 </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 header
    3152    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 to
    3156    a TE field, using these rules:
    3157   <list style="numbers">
    3158     <x:lt>
    3159       <t>The "chunked" transfer-coding is always acceptable. If the
    3160          keyword "trailers" is listed, the client indicates that it is
    3161          willing to accept trailer fields in the chunked response on
    3162          behalf of itself and any downstream clients. The implication is
    3163          that, if given, the client is stating that either all
    3164          downstream clients are willing to accept trailer fields in the
    3165          forwarded response, or that it will attempt to buffer the
    3166          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 a
    3169          chunked response such that a client can be assured of buffering
    3170          the entire response.</t>
    3171     </x:lt>
    3172     <x:lt>
    3173       <t>If the transfer-coding being tested is one of the transfer-codings
    3174          listed in the TE field, then it is acceptable unless it
    3175          is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a
    3176          qvalue of 0 means "not acceptable".)</t>
    3177     </x:lt>
    3178     <x:lt>
    3179       <t>If multiple transfer-codings are acceptable, then the
    3180          acceptable transfer-coding with the highest non-zero qvalue is
    3181          preferred.  The "chunked" transfer-coding always has a qvalue
    3182          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 only
    3188    acceptable transfer-coding is "chunked". A message with no transfer-coding is
    3189    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 of
    3199    header fields is present in the trailer of a message encoded with
    3200    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 a
    3207    message using chunked transfer-coding with a non-empty trailer. Doing
    3208    so allows the recipient to know which header fields to expect in the
    3209    trailer.
    3210 </t>
    3211 <t>
    3212    If no Trailer header field is present, the trailer &SHOULD-NOT;  include
    3213    any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of
    3214    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-codings
    3233    (if any) have been applied to the message body. It differs from
    3234    Content-Encoding (&content-codings;) in that transfer-codings are a property
    3235    of the message (and therefore are removed by intermediaries), whereas
    3236    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: chunked
    3246 </artwork></figure>
    3247 <t>
    3248    If multiple encodings have been applied to a representation, the transfer-codings
    3249    &MUST; be listed in the order in which they were applied.
    3250    Additional information about the encoding parameters &MAY; be provided
    3251    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-Encoding
    3255    header field.
    3256 </t>
    3257 </section>
    3258 
    32593228<section title="Upgrade" anchor="header.upgrade">
    32603229  <iref primary="true" item="Upgrade header field" x:for-anchor=""/>
    32613230  <iref primary="true" item="Header Fields" subitem="Upgrade" x:for-anchor=""/>
    32623231  <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"/>
    32633235<t>
    32643236   The "Upgrade" header field allows the client to specify what
    … …  
    32683240</t>
    32693241<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>
    32713247</artwork></figure>
    32723248<t>
    … …  
    33283304<section title="Upgrade Token Registry" anchor="upgrade.token.registry">
    33293305<t>
    3330    The HTTP Upgrade Token Registry defines the name space for product
     3306   The HTTP Upgrade Token Registry defines the name space for protocol-name
    33313307   tokens used to identify protocols in the Upgrade header field.
    3332    Each registered token is associated with contact information and
     3308   Each registered protocol-name is associated with contact information and
    33333309   an optional set of specifications that details how the connection
    33343310   will be processed after it has been upgraded.
    … …  
    33403316   Registrations are subject to the following rules:
    33413317  <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>
    33433319    <t>The registration &MUST; name a responsible party for the
    33443320       registration.</t>
    33453321    <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>
    33483326    <t>The responsible party &MAY; change the registration at any time.
    33493327       The IANA will keep a record of all such changes, and make them
    33503328       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
    33563331       responsible party cannot be contacted.</t>
    33573332  </list>
    … …  
    33653340  <iref primary="true" item="Via header field" x:for-anchor=""/>
    33663341  <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"/>
    33693342  <x:anchor-alias value="pseudonym"/>
    33703343  <x:anchor-alias value="received-by"/>
    … …  
    33853358                          [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
    33863359  <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>
    33893360  <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
    33903361  <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
    … …  
    50825053
    50835054<x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in [RFC3986], Section 4.1&gt;
    5084 <x:ref>Upgrade</x:ref> = *( "," OWS ) product *( OWS "," [ OWS product ] )
     5055<x:ref>Upgrade</x:ref> = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
    50855056
    50865057<x:ref>Via</x:ref> = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
    … …  
    51245095<x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in [RFC3986], Section 3.3&gt;
    51255096<x:ref>port</x:ref> = &lt;port, defined in [RFC3986], Section 3.2.3&gt;
    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 ]
    51285098<x:ref>protocol-name</x:ref> = token
    51295099<x:ref>protocol-version</x:ref> = token
Note: See TracChangeset for help on using the changeset viewer.