- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 10 Dec 98 11:54:03 PST
- To: "Nottingham, Mark (Australia)" <mark_nottingham@exchange.au.ml.com>
- Cc: http-wg@hplb.hpl.hp.com
I can't find anything in the Draft that addresses the situation when both Cache-Control and Pragma: no-cache headers are set, and they are in conflict. For instance, if I use Cache-Control: must-revalidate Pragma: no-cache on a HTTP response, it would be desireable to have it cached (and always revalidated) by HTTP 1.1 caches, and not cached by HTTP 1.0 caches. However, I can see nothing in the Draft about this, and some implementations, upon reading 14.32 Pragma, might never cache the object. While the action is safe, it's not ideal. Am I missing something somewhere? Thanks. Larry Masinter (who writes that this is "not specified") and Koen (who points out that what you probably want to do is to send an Expires header) are both right. However, there is a subtle point that you and they both missed: the formal specification for "Pragma: no-cache" applies ONLY to request messages (in both HTTP/1.1 and in RFC1945); it has no formal definition for response messages. While it is possible that some caches do look at "Pragma" headers in responses, I don't know of any specific proxy software that does. I checked both Squid 1.1.20 and an ancient copy of the CERN server/proxy code; both would ignore "Pragma" headers in responses. So sending "Pragma: no-cache" in a response would probably be pointless, regardless of what the HTTP/1.1 specification says about its interaction with other headers. In retrospect, I think the wording of the specification of Pragma should have included a Note to this effect, because lots of people seem to be confused by this (even me, at times). But let's not delay the standardization process over this (non)issue! -Jeff
Received on Thursday, 10 December 1998 11:59:03 UTC