Re: Variant IDs

    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
      ....
      [3000 byte body]
    
    Step 2:
    
    Cache sends request:
      GET blah HTTP/1.1
      User-Agent: Blebber2.2
      Variant-Set: 5;pppp
      Vary: user-agent
      ...
    
    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.

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".  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 believe that a 350 byte _request_ header will usually slow
    things down more than a 925 byte _response_ header.  I understand
    that if a request is larger than one packet, sending the request
    may take several RTTs due to TCP/IP slow start/flow control
    mechanisms.  Adding 925 bytes to a response has less impact, as
    responses are too large to fit into one packet anyway.

This depends on several things.  First of all, if we are using
persistent connections, then the slow-start penalty is less likely
to be a problem.

Second, in the severely bandwidth-limited cases, the RTT penalty is not
as bad as the excess-bytes penalty.  Consider a 14400-baud line (not
nearly the worst case).  The difference between 350 bytes and 925 bytes
is 4600 bits, or about 320 msec.  This is actually several times larger
than the median short-packet RTTs that I've seen in several studies
(bear in mind that long effective RTTs can be caused by lots of bytes
in transit.

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

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.

-Jeff

Received on Monday, 12 February 1996 22:52:15 UTC