Re: HTTP Caching Model?
Daniel W. Connolly (connolly@hal.com)
Tue, 13 Dec 1994 14:32:43 -0600
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