Re: HTTP Caching Model?

In message <ab139bf30702100468c7@[192.190.111.98]>, Mitra writes:
>At 11:37 AM 12/12/94, Marc H. wrote:
>>+--- On Mon, 12 Dec 1994, Daniel W. Connolly wrote:
>>[...]
>>| User-Agent shouldn't affect the retuned data. (The fact that it
>>| does is a wart that we'll have to deal with somehow.)
>>|
>>| It means that introducing new headers that can affect the returned
>>| data (like the recently proposed Accept-Charset: header) can't be done
>>| with correct backwards compatibility. It might be wise to say that all
>>| headers matching Accept-*: are allowed to affect the returned data.
>>+---
>
>This doesnt surprise me at all, I've either used, or considered using this
>field in the following ways.
>
[creative hacks deleted...]
>

I'm not sure what you're suggesting here.

I can see that real world nasty problems require real world nasty
solutions.

But as far as a spec, shouldn't we use the categorical imperative?
i.e. what if everybody did that?

If everybody customized their documents on a per-user-agent basis, and
caching proxies don't take the User-Agent: header into account in
their cache keys, then things will be broken.

The question is: where do we assign the fault?

If we say that the proxy was broken for not using User-Agent as a
cache key, then we're saying that cached objects can never be shared
accross clients with different user agents. I don't think we want
that.

So I'm suggesting that serving up different documents for different
User-Agents should be a protocol violation.

>Of course .... if none of the browsers had bugs, and all did a good job of
>presentation, then designers wouldnt need to server up multiple versions of
>files.

A spec tells you what happens when everybody plays by the rules. When
there are bugs, all bets are off, and you do what you must.

Dan

Received on Tuesday, 13 December 1994 12:41:05 UTC