Re: HTTP Caching Model?

At 11:37 AM 12/12/94, Marc H. wrote:
>+--- On Mon, 12 Dec 1994, Daniel W. Connolly wrote:
>| [...] some information providers are using, of all things, the
>| User-Agent field to customize their documents: they server up
>| different stuff for MacMosaic, WinMosaic, Netscape, etc.
>[...]
>| 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.

At times there have been serious lags between browsers, so for example it
was neccessary to advise users of EINet's browser to upgrade to a browser
that supported authorisation, during the considerable period when their's
did not.

Windows Mosaic has a serious bug related to caching images by relative URLs
- same advise had to be given,

Something out there has a serious bug with truncating the last (or is it
the first) field of forms. If I'd ever tracked down which, then I'd have
written code to put a dummy hidden field at the beginning and end of forms.

There were a number of cases during the development of the Techweb site
where the best HTML for some browsers was dramatically different from that
for others - for example some browsers handle <br> correctly, while others
treat it as <p>
ideally I'd have presented this file in two different ways.

Now, we have the situation where Netscape has a lot of really usefull
features, which the SGML-Purists dont want to put in HTML because they
allow people to specify presentation (shock, horror). I can see lots of
cases where the best presentation on a good browser is going to be
different that that for a lousy browser.

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.

- Mitra (raising flame-guard).


=======================================================================
Mitra                                                    mitra@path.net
Internet Consulting                                       (415)488-0944
<http://www.path.net/mitra>                           fax (415)488-0988

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