> Yes, and irritating it is too. I wish I could get more browsers to > ignore the gratuitous no-cache pragmas that some sites send.
They are typically invalid and largely ineffective as well. As far as I know, HTTP/1.1 only define Pragma: no-cache in the client to server direction. At a HTTP/1.0 compatibility level, I think Expires is what they should use. I suspect that big 2 browsers ignore the standard in this respect, although it is also possible that Pragma: no-cache from server to client is totally apocryphal. Moreover, shared caches totally ignore the payload of the HTTP response, so don't see them (they are probably more likely to not cache because of Cookies in the request, or the lack of a correlator (Last-Modified, or ETag) in the response). I think the basic reason that starting web designers always ask how to frustrate caching is that it avoids the need to think, including learning more than one technology (HTTP as well as HTML) and choosing exactly which cache control directives are needed to maintain function, but maximise performance. Thinking, and employing people that can think costs businesses money. A secondary reason is probably the desire to get cookies back, even on static pages, for market research purposes. (I can't remember whether HTTP/1.1 caches are supposed to infer a Vary: Cookie header, when there is a cookie in the request, or actually require it to be present, to be effective. Either way, that's a two technology situation in a one technology world. (If you just want to track with HTTP/1.1, you should use cache-control: must-revalidate, so that only If-Modified requests go end to end.)) ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
