Re: Vary VS URI with an eye towards caching

[First, a note on distribution.

 This thread started out on the content negotiation list
 conneg@organic.com, and at some point moved to the caching list
 http-caching@pa.dec.com.  I believe this move was unintentional.

 I have included both conneg@organic.com and http-caching@pa.dec.com in
 the cc: of this message, please restrict followups to
 conneg@organic.com.

 Note for conneg people not on the http-caching list: you can find the
 messages you missed in the the http-caching archive:
 <URL:http://www.roads.lut.ac.uk/lists/http-caching/>.  
]

Daniel DuBois:
 [Koen Holtman:]
>>  varying = field-name | "external-factor"
>
>I was thinking just "Vary:" with an empty value would indicate that it
>varied but not on any header.  A special tag would work too, but obviously
>it would have to be a tag that could never be a header.

I agree.  I prefer a special tag, because think that a special tag is
less confusing than an empty Vary header.  An empty Vary header could
to easily be interpreted as `does not vary' (varies on nothing).

>>200.3) No URI, a Vary, no Location:
>>
>>    - opaque negotiation
>>    - response body varies on things in the Vary header,
>>    - but no `send-no-body-for' possible
>
>'Send-no-body-for' might still be possible if we adopt a content-id opaque
>validator scheme in addition to the Location scheme.

Yes.  Something like Variant-ID: <opaque value> and
Send-no-body-for-variant-ID: 1#<opaque value> seems entirely
reasonable to me.

>So basically I'm advocating a 2^4 combination.  Just great...

>>200.8) A URI, a Vary, a Location:
>>    - partly opaque, partly transparent negotiation:
>>    - URI header varies on the things in the Vary header
>>    - Location and response body are a variant given by preemptive
>>      negotiation using the variants in the URI header
>>    - `send-no-body-for' possible
>>300.7) A URI, a Vary, no Location:
>>    - do transparent reactive negotiation using the URI header
>>    - URI header varies on the things in the Vary header
>>300.8) A URI, a Vary, a Location:
>>    - as 300.7.
>>    - If not capable of reactive negotiation, use the URI in the Location
>>      header.
>
>I'm a little fuzzy on the behavior in these cases (especailly the 300s), so
>let's make sure if we allow this, what it mean gets explained in great
>detail.  

Yes.  The basic idea behind 200.8 and 300.[78] is a two-step scheme:

 1) opaque negotiation is used to produce an URI header
 2) the URI header produced is used in transparent
    negotiation, which can be either preemptive or reactive

A custom variant rating algorithm can only be applied in step 1.  In
particular,

    Location and response body are a variant given by preemptive
    negotiation using the variants in the URI header

The Location-URI --> body mapping is _not_ supposed to map to
different bodies for different request header combinations.  The only
variance is in step 1), in the selection of the Location-URIs to go
into the URI header.

Note that we need such a two-step scheme if we want to allow use of
both user-agent negotiation and reactive negotiation on the same
negotiable resource.

>It's not clear to me that a proxy can do anything with 200.8 except
>call the server, unless it takes on the responsibility of saving previous
>request headers to compare on the Vary: header.

Yes, It would have to save request headers.

>  I suppose that's a proxy
>implementation choice, but I'd like it to be explicit.

A proxy that wants to do elaborate caching for the `a URI, a vary'
cases in which (according my model) the

    URI header varies on the things in the Vary header

would have to store, for each response:

   - The request headers listed in the Vary header
   - The URI header 

in such a way that it can look up the URI header when given the
request URI and the varying request headers as a key.

If the response includes a request body, it would also have to store

 - the Location (variant-URI) of the response
 - the response body
 - the response headers that apply to the response body
   (Content-type would be saved, URI would not)

in such a way that it can look up the response headers and body when
given the Location (variant-URI) as a key.

When getting a new request on the same URI, the proxy could then
perform a 3-step algorithm:

1) Using the request URI and the varying request headers as a key,
look up the matching URI header U (if no URI header U is cached for
the given combination of varying request headers, relay the request to
the origin server (*))

(*) Send-no-body-for is possible here.  The storing of information
that allows the cache to make a good send-no-body-for header is not
covered above.

2) Using the URI header U found, do preemptive negotiation to
determine the best variant-URI V (if preemptive negotiation cannot
determine the best variant, send a `do reactive negotiation' response
to the client with the URI header U)

3) Using the variant-URI V found, look up the variant response headers
and body, and send these to the client (if no headers and body are
cached for the variant-URI V, request the variant from the origin
server).  

This scheme is a bit complicated, but remember that proxies are not
required to do all the things above, they can do less and still be
correct, though less as efficient.

>We might also need to explore in more detail whether or not Vary:
>Authentication needs to be sent, and if it actually indicates anything in
>terms of behavior.  [Personally, I think I'd like to see "Vary:
>Authentication" safely ignore-able, and WWW-Authenticate'd responses not
>proxy-cached unless there was a Cache-Control: public directive (for
>needlessly Authenticaiton:'ed imagaes and the like).]

I agree here.  Basically, responses vary by default on the
Authentication header, so there is no need to ever include this header
name in a list of Vary headers.  The same is true for the Host header.

>Dan DuBois, Software Animal             http://www.spyglass.com/~ddubois/

Koen.

Received on Saturday, 13 January 1996 18:28:51 UTC