Re: Variant-ID proposal

This is a followup to my own message.  When I wrote the reply below, I
was tired and under time pressure, so I wrote some things that were
wrong or confusing.  I'll correct them here.

Koen Holtman:
>
>Roy T. Fielding:
>>[Jeff Mogul:]
>>> It might also be nice if someone could explain how an
>>> origin server decides whether to use opaque negotiation or transparent
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>>> negotiation.  However, I think from the point of view of caching, I
    ^^^^^^^^^^^
>>> don't need to know.

Oops, I read `preemptive negotiation or reactive negotiation' above,
not `opaque or transparent'.  Roy's response:

>>It would normally be done via server configuration (in practice,
>>on a directory-by-directory basis or using .meta/.multi files).

Was 100% right.  I wrote

>No.

and this was 100% wrong, because I misread the question.

    [Jeff:]
>>> I would rephrase that as: The variant-ID is used as part of the cache
>>> key only if the Request-URI is not sufficient to determine a specific
>>> entity.  (And then only for conditional requests and for replacing 
>>> existing cache entries.)
>>
  [Roy:]
>>Yep.
>
>No, change that to `the request URI and the contents of a
>Content-Location header (if present)'.

This also needs some clarification.  In principle, for transparent
negotiation, the specific entity returned can be identified with a
single URI, but this will not be the URI of the request, but the URI
in the Content-Location header.

If you get a 200 (OK) response from a transparently negotiated
resource (which sends an Alternates and a Content-Location header in
the response), the Content-Location header contains the URI under
which the entity returned is available.

For example, after a request:

GET /blah HTTP/1.1
Accept-Language: en, nl

you will get back, from a transparently negotiated resource, the
response:

HTTP/1.1 200 OK
Content-Location: http://x.com/blah.en.html
Alternates: { "http://x.com/blah.en.html" 1 {language "en"}}
            { "http://x.com/blah.fr.html" 1 {language "fr"}}
Date: ..
Content-Language: en
Cval: "3212419"
...

..English text about blah..

IF you do a direct GET on http://x.com/blah.en.html, you will get the
same English text entity, but a plain 1.1 cache does not have to know
that.

A plain 1.1 client will not know how to parse the Alternates header,
and won't be able to interpret the Content-Location header, because
the syntax of Alternates and the meaning of Content-Location will be
defined later, in the content negotiation draft.  What the 1.1 client
can do (according to the text I wrote for the 1.1 draft):

- for answering requests on behalf of the origin server:
  Alternates can be interpreted as Vary: {accept-headers}. So the
  cache can store the response as a variant and return it for new
  requests if request headers match in a certain way.

- for cache refreshing: the contents of the Cval header (in this case
  "3212419" can be put in the If-Invalid header sent to
  the origin server.  A typical if-Invalid header sent, if 3 variants
  are caches, would be
     If-Invalid: "3212419", "453232", "756456"
  (Note that the origin server must ensure that all opaque validators
  for the three variants are indeed different, because there is no
  variant-id attached to disambiguate them.)

- for cache replacement: The contents of the Content-Location header
  can be used as a replacement key.  See the cache replacement text I
  wrote for the 1.1 draft.

I hope this clears up some of the confusion I generated with my
previous reply.

Koen.

Received on Thursday, 18 April 1996 08:51:13 UTC