Re: 13.1.2 Warnings

>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

Received on Thursday, 17 October 1996 13:27:16 UTC