Ignore:
Timestamp:
15/12/12 21:54:13 (8 years ago)
Author:
fielding@…
Message:

Move product tokens into UA and clean User-Agent and Server definitions; Retitle Context and Informative sections; partly addresses #419

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2050 r2051  
    10381038</section>
    10391039
    1040 <section title="Product Tokens" anchor="product.tokens">
    1041   <x:anchor-alias value="product"/>
    1042   <x:anchor-alias value="product-version"/>
    1043 <t>
    1044    Product tokens are used to allow communicating applications to
    1045    identify themselves by software name and version. Most fields using
    1046    product tokens also allow sub-products which form a significant part
    1047    of the application to be listed, separated by whitespace. By
    1048    convention, the products are listed in order of their significance
    1049    for identifying the application.
    1050 </t>
    1051 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
    1052   <x:ref>product</x:ref>         = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>]
    1053   <x:ref>product-version</x:ref> = <x:ref>token</x:ref>
    1054 </artwork></figure>
    1055 <t>
    1056    Examples:
    1057 </t>
    1058 <figure><artwork type="example">
    1059   User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    1060   Server: Apache/0.8.4
    1061 </artwork></figure>
    1062 <t>
    1063    Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be
    1064    used for advertising or other non-essential information. Although any
    1065    token octet &MAY; appear in a product-version, this token &SHOULD;
    1066    only be used for a version identifier (i.e., successive versions of
    1067    the same product &SHOULD; only differ in the product-version portion of
    1068    the product value).
    1069 </t>
    1070 </section>
    1071 
    10721040<section title="Request Methods" anchor="methods">
    10731041
     
    23372305</section>
    23382306
    2339 <section title="Context" anchor="request.context">
     2307<section title="Request Context" anchor="request.context">
    23402308<texttable align="left">
    23412309  <ttcol>Header Field Name</ttcol>
     
    24352403  <iref primary="true" item="User-Agent header field" x:for-anchor=""/>
    24362404  <x:anchor-alias value="User-Agent"/>
    2437 <t>
    2438    The "User-Agent" header field contains information about the user
    2439    agent originating the request. User agents &SHOULD; include this field with
    2440    requests.
    2441 </t>
    2442 <t>
    2443    Typically, it is used for statistical purposes, the tracing of protocol
    2444    violations, and tailoring responses to avoid particular user agent
    2445    limitations.
    2446 </t>
    2447 <t>
    2448    The field can contain multiple
    2449    product tokens (<xref target="product.tokens"/>)
    2450    and comments (&header-fields;) identifying the agent and its
    2451    significant subproducts. By convention, the product tokens are listed in
    2452    order of their significance for identifying the application.
    2453 </t>
    2454 <t>
    2455    Because this field is usually sent on every request a user agent makes,
    2456    implementations are encouraged not to include needlessly fine-grained
    2457    detail, and to limit (or even prohibit) the addition of subproducts by third
    2458    parties. Overly long and detailed User-Agent field values make requests
    2459    larger and can also be used to identify ("fingerprint") the user against
    2460    their wishes.
    2461 </t>
    2462 <t>
    2463    Likewise, implementations are encouraged not to use the product tokens of
    2464    other implementations in order to declare compatibility with them, as this
    2465    circumvents the purpose of the field. Finally, they are encouraged not to
    2466    use comments to identify products; doing so makes the field value more
    2467    difficult to parse.
     2405  <x:anchor-alias value="product"/>
     2406  <x:anchor-alias value="product-version"/>
     2407<t>
     2408   The "User-Agent" header field contains information about the user agent
     2409   originating the request, which is often used by servers to help identify
     2410   the scope of reported interoperability problems, to work around or tailor
     2411   responses to avoid particular user agent limitations, and for analytics
     2412   regarding browser or operating system use. A user agent &SHOULD; include
     2413   a User-Agent field in each request unless specifically configured not
     2414   to do so.
    24682415</t>
    24692416<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/>
     
    24712418</artwork></figure>
    24722419<t>
     2420   The User-Agent field-value consists of one or more product identifiers,
     2421   each followed by zero or more comments (&header-fields;), which together
     2422   identify the user agent software and its significant subproducts.
     2423   By convention, the product identifiers are listed in order of their
     2424   significance for identifying the user agent software. Each product
     2425   identifier consists of a name and optional version.
     2426</t>
     2427<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
     2428  <x:ref>product</x:ref>         = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>]
     2429  <x:ref>product-version</x:ref> = <x:ref>token</x:ref>
     2430</artwork></figure>
     2431<t>
     2432   Senders &SHOULD; limit generated product identifiers to what is necessary
     2433   to identify the product; senders &MUST-NOT; generate advertising or other
     2434   non-essential information within the product identifier.
     2435   Senders &SHOULD-NOT; generate information in <x:ref>product-version</x:ref>
     2436   that is not a version identifier (i.e., successive versions of the same
     2437   product name ought to only differ in the product-version portion of the
     2438   product identifier).
     2439</t>
     2440<t>
    24732441   Example:
    24742442</t>
     
    24762444  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    24772445</artwork></figure>
     2446<t>
     2447   A user agent &SHOULD-NOT; generate a User-Agent field containing needlessly
     2448   fine-grained detail and &SHOULD; limit the addition of subproducts by third
     2449   parties. Overly long and detailed User-Agent field values increase request
     2450   latency and the risk of a user being identified against their wishes
     2451   ("fingerprinting").
     2452</t>
     2453<t>
     2454   Likewise, implementations are encouraged not to use the product tokens of
     2455   other implementations in order to declare compatibility with them, as this
     2456   circumvents the purpose of the field. If a user agent masquerades as a
     2457   different user agent, recipients can assume that the user intentionally
     2458   desires to see responses tailored for that identified user agent, even
     2459   if they might not work as well for the actual user agent being used.
     2460</t>
    24782461</section>
    24792462</section>
     
    38583841</section>
    38593842
    3860 <section title="Informative" anchor="response.inform">
     3843<section title="Response Context" anchor="response.context">
    38613844<t>
    38623845   The remaining response header fields provide more information about
     
    39043887<t>
    39053888   The "Server" header field contains information about the
    3906    software used by the origin server to handle the request.
    3907 </t>
    3908 <t>
    3909    The field can contain multiple
    3910    product tokens (<xref target="product.tokens"/>) and
    3911    comments (&header-fields;) identifying the server and any significant
    3912    subproducts. The product tokens are listed in order of their significance
    3913    for identifying the application.
     3889   software used by the origin server to handle the request, which is often
     3890   used by clients to help identify the scope of reported interoperability
     3891   problems, to work around or tailor requests to avoid particular server
     3892   limitations, and for analytics regarding server or operating system use.
     3893   An origin server &MAY; generate a Server field in its responses.
    39143894</t>
    39153895<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/>
     
    39173897</artwork></figure>
    39183898<t>
     3899   The Server field-value consists of one or more product identifiers, each
     3900   followed by zero or more comments (&header-fields;), which together
     3901   identify the origin server software and its significant subproducts.
     3902   By convention, the product identifiers are listed in order of their
     3903   significance for identifying the origin server software. Each product
     3904   identifier consists of a name and optional version, as defined in
     3905   <xref target="header.user-agent"/>.
     3906</t>
     3907<t>
    39193908   Example:
    39203909</t>
     
    39233912</artwork></figure>
    39243913<t>
    3925    If the response is being forwarded through a proxy, the proxy application
    3926    &MUST-NOT; modify the <x:ref>Server</x:ref> header field. Instead, it
    3927    &MUST; include a <x:ref>Via</x:ref> field (as described in &header-via;).
    3928 </t>
    3929 <x:note>
    3930   <t>
    3931     &Note; Revealing the specific software version of the server might
    3932     allow the server machine to become more vulnerable to attacks
    3933     against software that is known to contain security holes. Server
    3934     implementers are encouraged to make this field a configurable
    3935     option.
    3936   </t>
    3937 </x:note>
     3914   An origin server &SHOULD-NOT; generate a Server field containing needlessly
     3915   fine-grained detail and &SHOULD; limit the addition of subproducts by third
     3916   parties. Overly long and detailed Server field values increase response
     3917   latency and potentially reveal internal implementation details that might
     3918   make it (slightly) easier for attackers to find and exploit known security
     3919   holes.
     3920</t>
    39383921</section>
    39393922</section>
Note: See TracChangeset for help on using the changeset viewer.