W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: Variant IDs

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 10 Feb 1996 22:37:57 +0100 (MET)
Message-Id: <199602102137.WAA08191@wsooti04.win.tue.nl>
To: http-caching@pa.dec.com
Cc: koen@win.tue.nl (Koen Holtman)

I've been away for a few days, so I'll reply to several remarks in the
Variant IDs thread at once in this message.  Here are my current views
on a number of Variant ID issues.

1) About the `is unwillingness to list all variants in an URI header a
frequently occuring case' issue: I'm convinced by the

   21 languages * (1 zipped + 1 unzipped) * 3 MIME types * 3 charsets

example by Paul Leach that there are indeed cases where you do not
want to list every available version in the URI header.

I'm not yet sure if this case will occur often enough to require
optimizations in the protocol beyond the optimizations (302 (See
other) redirection, URI headers that vary) that would are already be
possible under 1.1.

2) About Variant-ID/Variant-set duplicating the
Variant-If-modified-since (and variant-if-validator-valid) mechanism
in (URI header based) content negotiation: I think now that I
previously overestimated the amount of duplication that would happen.

My content negotiation definitions are big, but the parts devoted to
the Variant-IMS mechanism are not.  The main complexity generators in
URI based content negotiation are elsewhere.

I suspect it would be possible to define the semantics of Variant-ID
and Variant-Set in a page or half a page of text.

3) Putting 1) and 2) together, 
  - I see no good reason anymore to oppose putting Variant-ID and
    Variant-set in the 1.1 spec as optional optimizations
  - But I am also not convinced yet that they should go in.

4) A side issue: I'd rather not solve charset problems by building
charset converters into servers.  With server side conversion, a lot
of bandwidth and proxy cache memory is used to transmit and cache all
the different versions.

Charset conversion intelligence should be at the user agent side as
much as possible.

5) A note for Jeffrey Mogul and Paul Leach who are (I believe) writing
up 1.1 spec language for Variant-ID and Variant-Set:

The addition of Variant-IDs does add some subtle issues that will be
tricky to define: suppose that a response varies only on user-agent.
Consider the following scenario:

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.

6) About 925 byte URI headers vs. 350 byte Variant-Set headers:

- With some work (allowing "l" to stand for "language", "v" for
"variant", etc), the URI header can be made a lot shorter.

- Also, as Roy Fielding pointed out, the URI header says something
that is useful, it is not just there to optimize caching.

- I don't expect 925 URI headers to be used that often.  Most
resources will not be negotiable, and most negotiable resources will
only have a few variants.

- 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.

Received on Saturday, 10 February 1996 21:52:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC