Re: HTTP Caching Model?

In message <9412150046.aa28029@paris.ics.uci.edu>, "Roy T. Fielding" writes:
>and Dan replied:
>
>> This is kinda humorous... the answer has been in the spec all along:
>> ...
>> 
>> URI-header      =       "URI" ":" 1#( URI [";" vary] )
>> vary            =       "vary" "=" <"> 1#vary-param <">
>> vary-param      =       "type" / "language" / "version" / "encoding"
>>                 /       extension-vary
>> extension-vary  =       token
>> 
>
>No, that isn't enough information to allow a proxy to decide
>what is available.

Why is that such a bad thing? The server can give a lot of information
about what's available by giving several URI: headers.

Perhaps some way for the server to indicate "these URI: headers
specify _all_ representations of this resource" would be useful.

>  For instance, let's say
[ ... ]
>and he's going to be very upset when he gets the English version
>instead.  But, as far as the proxy can tell, that is the only acceptable
>version available.

The proxy had better not jump to conclusions like this. It had better
go to the original server and get the real answer, if it doesn't have
enough information locally.

>  There are
>only three solutions that preserve transparent behavior:
>
>1) Have the proxy revert to the source if it receives a request which
>   includes a variant category that has not already been cached;
>
>2) Tell the proxy about all the possible variants so that it can make
>   the decision itself;
>
>3) Use URCs so that the decision can be made within the client and not
>   as part of the request.
>
>I think we can live with (1) for HTTP/1.0,

Bingo. I agree.

> but we should change to (3)
>for the next version.

The whole purpose of the HTTP format negociation algorithm is to so
that it only takes one round trip to get a document, even if there are
variants.

Having the server tell the client what all the options are, and then
having the client choose is just like:

	"Click _here_ for postscript"
	"Click _here_ for text"

There's a time and a place for that, but we should avoid it whenever
possible. The thing you call a URC can just be an HTML document that
explains in human-readable terms what the options are.

On the other hand, there seems to be a lot of interest in creating a
machine-readable representation of this information. The Harvest SOIF
format[1] is the best I've seen so far.


[1] The Harvest Summary Object Interchange Format (SOIF)
http://harvest.cs.colorado.edu/brokers/soifhelp.html
Fri Nov 25 17:34:20 1994

Received on Thursday, 15 December 1994 15:50:48 UTC