RE: Label header vs PROPFIND depth 1

Julian wrote:

> My position is that if you don't consider the version selected by
> the LABEL header to be a variant (representation) of the VCR,

which, as I stated, I don't.

> then it MUST NOT be returned by a GET on the VCR URI.

I assume this is because of the definition of GET, and not ...

> RFC2616, section 1.3:
>
> variant
>
> A resource may have one, or more than one, representation(s)
> associated with it at any given instant. Each of these
> representations is termed a `varriant'. Use of the term
> `variant' does not necessarily imply that the resource is
> subject to content negotiation.

This definition is fine for a variant -- and has nothing to do with the
situation we are discussing, which is two different resources (a
version-controlled resource and a version resource).

This is the definition of the vary: header (RFC2616 section 14.44):

"The Vary field value indicates the set of request-header fields that fully
determines, while the response is fresh, whether a cache is permitted to use
the response to reply to a subsequent request without revalidation. For
uncacheable or stale responses, the Vary field value advises the user agent
about the criteria that were used to select the representation. A Vary field
value of "*" implies that a cache cannot determine from the request headers
of a subsequent request whether this response is the appropriate
representation. See section 13.6 for use of the Vary header field by caches.

       Vary  = "Vary" ":" ( "*" | 1#field-name )"


It is therefore reasonable to include 'label' in the vary header to indicate
that a cache should consider the value of the label header when determining
the correct response.  Indeed, from the same section:

"The field-names given are not limited to the set of standard request-header
fields defined by this specification."

I cannot see anything that says a 'variant' is defined by the 'vary' header.

Regards,
Tim

Received on Wednesday, 24 April 2002 11:40:05 UTC