- From: Daniel DuBois <dan@spyglass.com>
- Date: Thu, 17 Oct 1996 13:23:10 -0700
- To: ben@algroup.co.uk, Daniel DuBois <dan@rafiki.spyglass.com>
- Cc: luotonen@netscape.com, masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Perhaps we have different ideas of what "transparency" means, but it seems to >me that receiving an entity with an erroneous header is not transparent. It OK, you are right. I was thinking about transparancy of the entity body. But in the HTTP spec, semantic transparency is defined as 'exactly the same response (except for hop-by-hop headers)'. Warning, although added in a middle hop, I dont believe can be considered a hop-by-hop header. Seems clear the authors of that section of the spec must have meant transparency of the entity body, since it's impossible to have a Warning:stale header originate from an origin server. By definition, a Warning:stale header means its not transparent. Hmmmm.... Can we really guarantee semantic transparency of headers? Certainly there must be some headers that can change without the resource changing, and that won't be reported on the 304 response. If I reconfigure my server to start adding "Cache-control: private" to all responses, but dont modify foobar.txt, my If-Modifed-Since might still return 304 despite the fact that truly semantic transparent headers would be different than the downstream cache has. Oh well - implementation issue. (Keep last-restart date of server and compare additionally compare that date against IMS times.) >could certainly lead to undesirable behaviour on the part of downstream 1.1 >caches, such as periodically trying to refetch the "stale" entity (and, of >course, getting another stale one). Well, 'undesirable behavior' is a different beast (and one that's often at odds with semantic tranparency). ----- Daniel DuBois I travel, I code, I'm a Traveling Coderman http://www.spyglass.com/~ddubois/
Received on Thursday, 17 October 1996 13:27:16 UTC