Re: Conneg: Vary VS URI with an eye towards caching

Daniel DuBois:
>
>The following verbiage is my idea of what the content negotiation scheme now
>looks like, based on 1) my opinions, 2) my opinions of the HTTP 1.1 draft,
>3) my opinions of Koen's posts, 4) my opinions of the recent content
>negotiation meeting.
>
>The short version: We want to add a Vary: header.
>
>The long version:  (Anyone who reads this deserves a virtual cookie.  God
>this is long.)
>

[...]

>5) Other proposals:
>Koen Holtman introduced a "Send-No-Body-For:" header for the purpose of
>negotiation on URI headers, but he was under the influence of User-Agent
>negotiation which I contend can't be easily done under the
>transparent-proxy-has-all-data-and- algorithms-URI scheme.

I proposed "Send-No-Body-For:" for the `vary' negotiation case.
User-agent negotiation (_not_ html feature negotiation) is a subset of
`vary' negotiation.

>  It should be
>done under the Vary: scheme.  As he intended it to work under some URI
>scheme, 

The thing is that I do _not_ assume, as you do, that an URI header
would contain all necessary data for a proxy to replicate the
negotiation.  I believe that in Roy's 1.1 draft design, the
`user-agent' keyword, if present in an URI header, tells the proxy
`no, you cannot replicate negotiation for this negotiation port'.

>he sought "Send-No-Body-For: URL".  Under my thoughts on transparent
>negotiation, one would never make a request with "Send-No-Body-For: URL".
>It would be redundant, if the proxy had that variant, it would be serving
>it.  Under transparent negotiation, the proxy knows that variant is
>servable, it doesn't need approval from the origin server.

Yes.  But in my mind, URI header != transparent negotiation.

The bottom line is that we seem to agree on mechanisms, we are just
using terminology in a different way.


[...easy, hard, impossible replication of negotiation...]

> It mimics what Koen was trying to do with
>Send-No-Body-For.  I see Vary: as the method for the 'impossible' case, and
>URI: as the method for the 'hard' case.

I see things that way too.  With the note that in my `known range
negotiation', I am building the `vary' header into the `URI' header
using the `qvary' field (though I have not put in something to express
that the server has 200 variants (yet)).  Let me quote the relevant
part from the `known range negotiation' draft:

||After having computed the variant set, the URI header representing it
||may look like this.  [I am using a verbose syntax for clarity, we can
||shorten keywords later.]
||
||    URI: { variant "http://blah.com/some/report.html.1" 
||                   0.7 
||                   { type "text/html" } }
||         { variant "http://blah.com/some/report.html.2" 
||                   0.8 { qvary 0-0.8 fixed-for-agents }
||                   { type "text/html" } }
||         { variant "http://blah.com/some/report.html.3" 
||                   0 { qvary 0-0.9 fixed-for-agents }
||                   { type "text/html" } }
||         { variant "http://blah.com/some/report.dvi"
||                   1
||         { type "application/x-dvi" } }
||      
||This URI header follows the syntax of the HTTP 1.1 URI header, except
||that the `qvary' field is new.
||
||The intended interpretation of this URI header (this variant set) is
||as follows:
||
||  - there are 4 different variants in the variant set for this
||    particular request, with quality factors 0.7, 0,8, 0, and 1 and
||    MIME types ..... .
||

Here is the vary-like part:

||  - the computed (source) quality factors of the second and third
||    variants can change (vary) from request to request.  The variation
||    of the quality factors is in the ranges 0-0.8, and 0-0.9.
||    A user agent (or proxy cache) receiving the URI header does not
||    know the algorithm used for the computation of the factors, but
||    the `fixed-for-agents' identifier does indicate that the result of
||    the computation does not vary as long as the same user agent is
||    used.

Note that my qvary mechanism does _not_ tell proxies for exactly which
request headers the response varies.  I don't think this information
is particularly relevant.  Also, in my scheme, the response could vary
on the phase of the moon, not on something in a request header.

The most important thing to send in vary negotiation would be the bit
saying `don't try this yourself, contact the origin server'.  On top
of that, information like `I will not give a different answer for the
same user agent/client IP address/whatever' would be nice.

>---
>OK, everything from here is flakey and needs to be worked out:
>---
>
>7) Problem
>Larry doesn't think a "Send-No-Body-For" construct should have URLs as
>parameters; it should have some other unique content-id value.  This concern
>stems from the idea that not all variants are nameable.  Separately, I have
>come to the conclusion that if all variants are nameable, and the algorithm
>is exposed properly, "Send-No-Body-For: URL" is unnecessary. (See #5).

But if all variants are nameable, and the algorithm is _not_ exposed,
the "Send-No-Body-For: URL" is necessary (if there is no other
known-to-be-reliable variant identifier scheme).

>8) Solution - Maybe?
>The Cache-Validator: header as I understand it could be sent on subsequent
>requests for an opaquely negotiated resource.  Now instead of asking "Is my
>copy of the resource still good?" it is effectively asking "Is my copy of
>the variant of the resource still good AND the variant you would give me?"

Such a scheme could work, with some care.  A requirement would be that
no two variants could ever have the same cache validator.

[...]
> c1) Do we need to give the server a way of saying "clear all your
variants"?

No. 

> c2) Do we need to give the serve a way of saying "clear these particular
> variants"?  (Presumably they'll clear eventually anyway as the proxy runs
>      out of space and/or pushes them out of their working set.)

They will be cleared if they expire, or sooner.

> d) Do cache-control messages (or ANY headers on the response for that
>matter) on
>      the opaquely negotiated response apply to all variants, just the
>      server-chosen variant, or just the base resource 'negotiation port'?

This is one of the issues we need to resolve, I mentioned it already
in my notes on content negotiation.  Currently, my opinion on this is
that the URI header (and possibly a future vary: header) applies to the
negotiation port, and that everything else applies to the variant.

This is the only way we can avoid speccing the semantics of many
response headers twice: once for negotiated, and once for
un-negotiated responses.

> e) What about renegade proxies who serve variants willy-nilly without
>contacting
>      the server?  etc...

We can't spec for renegade proxies.  Leave it to market forces, or
something.

> f) Are we getting too complicated to hope for consistant implementations?

Good question.  I for one would greatly prefer having a scheme in
which each variant has an URI as its name, not some opaque thing.  The
reason is that I want to avoid caches having to store variants under
keys like (port-URI, opaque thing) instead of just (variant-URI), that
I want to avoid speccing and implementing a

 GET variant-called-X-of-negotiation-port-Y

access mechanism for reactive negotiation, etc.

Also, if we use cache validators as variant IDs, it will be much
harder to make a mechanism for reliably replacing old variant copies
in a cache with new variant copies.  Eek, the more I think about it,
the nastier use of cache validators for variant IDs gets.  Maybe a
`variant ID = opaque string, not necessarily an URI, but quaranteed to
stay the same even if the variant content changes' scheme would be
best.

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

Koen.

Received on Sunday, 7 January 1996 11:47:23 UTC