30/12/12 08:25:02 (8 years ago)

(editorial) rewrite definition of Vary; partly addresses #419

1 edited


  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2067 r2068  
    37843784<section title="Selected Representation Header Fields" anchor="selected.representation">
    3785 <t><iref primary="true" item="selected representation"/>
     3785   <iref primary="true" item="selected representation"/>
     3786   <x:anchor-alias value="selected representation"/>
    37863788   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
    37873789   the current representation of the <x:ref>target resource</x:ref> that would have been
    38093811   <x:anchor-alias value="Vary"/>
    3811    The "Vary" header field conveys the set of header fields
    3812    that were used to select the representation.
    3813 </t>
    3814 <t>
    3815    Caches use this information as part of determining whether a stored
    3816    response can be used to satisfy a given request (&caching-neg-resp;).
    3817 </t>
    3818 <t>
    3819    In uncacheable or stale responses, the Vary field value advises the user
    3820    agent about the criteria that were used to select the representation.
     3813   The "Vary" header field describes what parts of a request message, aside
     3814   from the method and request target, might influence the origin server's
     3815   process for selecting and representing the response. The value consists of
     3816   either a single asterisk ("*") or a list of header field names
     3817   (case-insensitive).
    38223819<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Vary"/>
    3826    The set of header fields named by the Vary field value is known as the
    3827    selecting header fields.
    3828 </t>
    3829 <t>
    3830    A server &SHOULD; include a Vary header field with any cacheable response
    3831    that is subject to proactive negotiation. Doing so allows a cache to
    3832    properly interpret future requests on that resource and informs the user
    3833    agent about the presence of negotiation on that resource. A server &MAY;
    3834    include a Vary header field with a non-cacheable response that is subject
    3835    to proactive negotiation, since this might provide the user agent with
    3836    useful information about the dimensions over which the response varies at
    3837    the time of the response.
    3838 </t>
    3839 <t>
    3840    A Vary field value of "*" signals that unspecified parameters not limited
    3841    to the header fields (e.g., the network address of the client), play a
    3842    role in the selection of the response representation; therefore, a cache
    3843    cannot determine whether this response is appropriate. A proxy &MUST-NOT;
    3844    generate the "*" value.
    3845 </t>
    3846 <t>
    3847    The field-names given are not limited to the set of standard header
    3848    fields defined by this specification. Field names are case-insensitive.
    3849 </t>
     3823   A Vary field value of "*" signals that anything about the request might
     3824   play a role in selecting the response representation, possibly including
     3825   elements outside the message syntax (e.g., the client's network address),
     3826   and thus a recipient will not be able to determine whether this response is
     3827   appropriate for a later request without forwarding the request to the
     3828   origin server. A proxy &MUST-NOT; generate a Vary field with a "*" value.
     3831   A Vary field value consisting of a comma-separated list of names indicates
     3832   that the named request header fields, known as the selecting header fields,
     3833   might have a role in selecting the representation. The potential selecting
     3834   header fields are not limited to those defined by this specification.
     3837   An origin server might send Vary with a list of fields for two purposes:
     3838   <list style="numbers">
     3839      <x:lt>
     3840        <t>
     3841           To inform cache recipients that they &MUST-NOT; use this response
     3842           to satisfy a later request unless the later request has the
     3843           same values for the listed fields as the original request
     3844           (&caching-neg-resp;). In other words, Vary expands the cache key
     3845           required to match a new request to the stored cache entry.
     3846        </t>
     3847      </x:lt>
     3848      <x:lt>
     3849        <t>
     3850           To inform user agent recipients that this response is subject to
     3851           content negotiation (<xref target="request.conneg"/>) and that a
     3852           different representation might be sent in a subsequent request if
     3853           additional parameters are provided in the listed header fields
     3854           (<x:ref>proactive negotiation</x:ref>).
     3855        </t>
     3856      </x:lt>
     3857   </list>
     3860   Unless it has been deliberately configured to prevent cache transparency,
     3861   an origin server &SHOULD; send a Vary header field in a cacheable
     3862   response that is subject to proactive negotiation.
     3864<figure><preamble>For example, a response that contains</preamble><artwork type="example">
     3865  Vary: accept-encoding, accept-language
     3866</artwork><postamble>indicates that the origin server might have used the
     3867   request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref>
     3868   fields (or lack thereof) as determining factors while choosing this
     3869   <x:ref>selected representation</x:ref>.</postamble></figure>
Note: See TracChangeset for help on using the changeset viewer.