Re: Warning: header, need origin

Jeffrey Mogul:
>
>Thanks for explaining that with an example.  I think I finally understand
>what you need, now.

Good!

>However, I think there is a much simpler and more robust way of
>providing it.
>
>The basic problem is that we have already come to a consensus that
>caches may be configured to ignore max-age (on responses) if that
>is deemed necessary for performance.  Not recommended, but allowed.
>
>The protocol also already allows an origin server to say "don't
>cache this response," but we all agree that this is too restrictive
>to use in all cases.
>
>You write:
>    So what we don't want is caches which are configured to give stale
>    responses instead of doing a conditional GETs when the max-age is
>    exceeded: this leads to the showing of the old basket, which is
>    unacceptable.
>
>I.e., you need an unavoidable mechanism to require at least conditional
>validations on every access.

Basically, yes.

>There are two ways to accomplish this:
>
>        (1) somehow the origin server detects when a client cache
>        is not observing max-age, and in such cases, the origin
>        server forces non-caching of responses to such requests.

For the record, I have been arguing for:

        (1b) somehow the origin server detects when a client cache
        is not observing max-age, and in such cases, the origin
        server tells the user to reconfigure his cache in order to
        use the server.

>
>        (2) We provide a mandatory mechanism in the protocol that
>        allows the origin server to mark a response as "cachable
>        but you must always revalidate, no exceptions allowed".
>
>I've tried to argue that using method (1) is complex, may hurt
>performance in unrelated contexts (violating the rule that Roy
>proposed "place the burdens where the benefits lie"), and may not
>be robust.  We could argue more about that, but time is short.
>
>But method #2 seems to be quite simple and foolproof: We add a
>new
>        Cache-control: must-revalidate
>for responses.  The origin server sets this on any response that
>it requires revalidations (e.g., conditional GETs).  No HTTP/1.1
>cache is allowed to ignore it.  It has the same meaning as
>        Cache-control: max-age=0
>on responses, but MUST be obeyed.
>
>Any problems with that?

My problem is that I suspect that Roy may have problems: from previous
discussions, I concluded that he is against any MUST for things like
this because a MUST on must-revalidate means that anti-social sites
can abuse must-revalidate to get accurate hitcounts or somesuch,
wasting bandwidth for frivolous reasons.

However, we may be able to solve Roy's abuse problem be requiring
that

 1) if a (user agent) cache is configured to ignore even
 must-revalidate, or if it cannot fulfill the revalidation requirement
 for some reason (because of network problems), then it _must_ send a
 PQ Warning code;

 2) all user agents must, on receiving a PQ Warning code (from a proxy
 or from their internal cache), pop up a dialog box (or text-mode
 equivalent) with a warning about unreliability of the session (text
 TBS, let me think about it), with <reload>, <give up>, and possibly
 <reconfigure cache> buttons, _requiring_ manual action by the user
 each time, without there being an option to turn this dialog box off.

This requirement for manual action would make use of
must-revalidate completely uninteresting for sites that want to
disable caching for frivolous reasons like higher hitcounts.  The
mechanism would only be used by (cookie-using) servers that
desperately need it.

I would still rather have a detectability requirement, but am willing
to gamble on a must-revalidate with requirements 1) and 2) also
solving my cookie problem.  The risk of course it that user agent
authors could ignore the spec and provide configuration options to
turn these annoying PQ warning dialog boxes off.

>-Jeff

Koen.

Received on Monday, 8 April 1996 21:52:26 UTC