Re: Variant IDs

Jeffrey Mogul:
>
>    Step 1:
>    
>    Cache sends request:
>      GET blah HTTP/1.1
>      User-Agent: Blebber1.1
>      ...
>    
>    Origin server sends response:
>      HTTP/1.1 200 OK
>      Variant-ID: 5
>      Cache-control: max-age=1000
>      Length: 3000
>      Validator: pppp
       Vary: user-agent
   [Note: I made an editing error and put the above vary header in the
    request of step 2 in my original message]

>      ....
>      [3000 byte body]
>    
>    Step 2:
>    
>    Cache sends request:
>      GET blah HTTP/1.1
>      User-Agent: Blebber2.2
>      Variant-Set: 5;pppp
[..misplaced vary header deleted..]
>      ...
>    
>    Origin server sends response:
>      HTTP/1.1 3xx Variant response not included
>      Variant-ID: 5
>      Vary: user-agent
>      ...
>    
>    Now, the cache knows that the origin server maps User-Agent:
>    Blebber2.2 to variant 5.  Now for how long may the cache serve variant
>    5 for requests with User-Agent: Blebber2.2 without validation?  Is
>    this determined by the Cache-control: max-age=1000 header in the first
>    response?  Or is it determined by any caching related header in the
>    step 2 response?
>    
>    Both approaches would work, but defining semantics for all possible
>    cases will be tricky.
>
>I think this apparently complexity w.r.t. freshness times can be
>simplified if we think of HTTP caches as storing values rather than
>responses.  I.e., if the cache stores the value of "URL blah, variant 5"
>then the first response says that "this value is fresh for the next
>1000 seconds" and the second response, if it carries any freshness
>info (such as an Expires: or max-age) updates the freshness lifetime
>for that cached value, just as it would if there were no content
                                                          ^^^^^^^
>negotiation involved.
 ^^^^^^^^^^^

`Content negotiation' should be `variant selection', for the rest I
agree.

>A more subtle point: after these two responses, the cache knows
>that the value "URL blah, variant 5" is variant with respect
>to user-agent (because of the vary header), but can be returned
>for requests that say either "User-agent: Blebber1.1" OR
>"User-agent: Blebber2.2".

Yes, but now for my original subtle question: what is the freshness of
the two pieces of information

 "return variant 5 for User-agent: Blebber1.1"
and
 "return variant 5 for User-agent: Blebber2.2"

that are stored by the cache?

Presumably it is 1000 seconds for the first piece, but what about the
second piece?  You can't just store such information forever, because
if new bugs are found in Blebber2.2, the service provider may want to
start mapping it to variant 6 instead.

>  In other words, the cache is building
>up a set of match values for the User-agent: field, rather than
>storing two different entity values for the "URL blah, variant 5,
>User-agent: blebber1.1" and "URL blah, variant 5, User-agent: blebber2.2"
>request/response pairs.
>
>Larry Masinter might disagree with me, since he favored the
>model that an HTTP cache holds request/response pairs.

I also have a preference for this request/response model.  In
particular, I think that caching can best be defined in terms of old
requests and responses, not in terms of (compact) representations of
these requests and responses stored currently by the cache.  But this
is besides the lifetime issue I am raising above.

[....]
>At 2400 baud, the difference between 925 bytes and 350 bytes is
>1.9 seconds.

This is assuming a 925 byte URI header with 20 variants, and these
will be rare.  Typical URI headers would be 150 bytes long.

Also, how many people really use a web browser for general web surfing
over a 2400 baud SLIP connection?  Use for access to short web pages
specially designed for some 2400 baud application I can imagine, but
the authors of these pages would presumably take care not to make
large URI headers.

>Also note that the choice to send (or not send) the Variant-set:
>header rests with the cache or client, which is probably more
>aware of the existence of a low-bandwidth last-hop link than the
>origin server (which would be sending the URI header).  While
>the URI header may indeed be useful for other stuff, it might
>be prudent to consider ways in which the client side of the
>interaction can ask the origin server not to send it.

Defining such a mechanism would not be very hard.  Use of such a
mechanism would make request headers longer, of course, so whether it
would actually save time is questionable.

I think it is appropriate not to engage in prudent considerations
about this kind of optimization for HTTP/1.1.  There are plenty of
more important issues that we have not yet addressed.  We can always
define such a mechanism for HTTP/1.2 if statistics show that it would
yield real savings.

>-Jeff

Koen.

Received on Tuesday, 13 February 1996 21:50:54 UTC