Re: Warning: header, need origin

    >    In private e-mail, Roy, Jeff, and I agreed that HTTP could require
    >    this ignoring of Cache-control to be _detectable_ by the origin
    >    server.  If a cache is operating under a situation where it is
    >    ignoring caching header, it should include a
    >    
    >     Cache-control: max-stale=<something>
    >    
    >    header in the request.  Origin servers could, on detecting this
    >    header, deny service if caching would violate law.
    >    
    >For the record, I never agreed to this, and will never agree to it.
    
    I believe you did, though you told me at the time that you would need
    reminding of the details.  I'll forward you the message I was talking
    about.
    
Looking over the messages you forwarded to me, I can see how you
might have mistakenly decided that I had agreed with you on this
point (when I was in fact referring to other issues).

    If I misunderstood you then, and if you do not agree to detectability
    requirements, then we have a huge problem: many members of the state
    management group, including me, won't settle for a 1.1 protocol that
    allows caches to be non-transparent without the origin server being
    able to detect it, because such a protocol will not allow safe
    deployment of cookies.  If you think these detectability requirements
    are unacceptable, this could block easily consensus about http 1.1.

My understanding was that the proper way for servers to use
cookies was to send

	Vary: Cookie

in any response whose request depends on the Cookie: header.

Note that if we can mandate that user-agent caches send
	Cache-control: max-stale=NNNN
then we can certainly mandate that all caches obey the Vary header.

One big problem with having clients send max-stale=NNN is that
a multi-user cache would have to have an extremely odd interpretation
of this.

Consider the following sequence (assuming that we were to adopt your
suggestion):

	client A sends

		GET /home.html HTTP/1.1
		Cookie: Customer="Koen"

	via proxy cache C

	server S responds

		HTTP/1.1 200 OK
		Expires: Thu, 02 Dec 1999 16:00:00 GMT
		(etc.)

	which is stored in C and forwarded to A.

Note that since client A is obeying all cache-control rules,
it didn't need to send a max-stale.

Then client B, which does not obey cache-control rules, sends

		GET /home.html HTTP/1.1
		Cache-control: max-stale=60

because it's willing to accept responses that are up to 1 minute
up to date.  And let's assume this happens prior to Thu, 02 Dec 1999.

The normal interpretation of max-stale=60 is that the cache
can respond to this request without contacting the origin server.
In fact, it would be pointless to have this in the protocol
if it did require the cache to contact the origin server.

But this means that the origin server doesn't see the signal
you are expecting to make the world safe for cookie deployment,
and as far as I understand things, the Wrong Thing happens.

On the other hand, if the origin server's original response had
been
		HTTP/1.1 200 OK
		Expires: Thu, 02 Dec 1999 16:00:00 GMT
		Vary: Cookie
		(etc.)

then the cache would have been forced to forward any request from client
B, whether or not it had a Cache-control: max-stale=NNN header, unless
it sent the exact same Cookie header as client A.

Please explain what is wrong with this reasoning, if you are still
convinced that the max-stale= mechanism is at all useful as a signal.

-Jeff

Received on Saturday, 6 April 1996 03:00:11 UTC