Re: On transparency

Roy T. Fielding:
>[Koen Holtman:]
>> Only "never check" would be non-compliant.  And the state management
>> subgroup _needs_ it to be non-compliant with HTTP/1.1, because you
>> can't reliably use cookies to build stateful services under the `never
>> check' behavior.
>
>It is certainly true that cookies may get messed up when any recipient
>is in "never check" mode.  However, making "never check" non-compliant
>would not make cookies any more reliable, because the "never check" mode
>is more important than HTTP compliance.  

If you think that having `never check' is that important, we have to
make a HTTP/1.1 that allows users to `never check' without being
non-compliant.

>The only thing we can do is
>make it clear to the user when semantic transparency is necessary for
>correct behavior.

This is not the only thing we can do, we can also require that servers
are warned if semantic transparency is absent.

>> Actually, you _can_ reliably use cookies under the `never check'
>> behavior, by using various `cache busting' techniques that have a
>> disastrous impact on the efficiency of all caches.  Anyway, I've said
>> this many times before.
>
>Assuming the server is still using cache-control, this has no more
>impact on "all caches" than does using cookies.

No, `cache busting' does not rely on cache-control.  Cache busting
means dynamically generating all link URLs the user can click, to make
sure that he can never click on the same URL (which may have been
cached without you wanting it) twice.  This has a considerable impact,
and it is current practice.

>> As someone who implements stateful services, I could live with `never
>> check' being allowed under HTTP/1.1, _but only_ if the user agent
>> signals this to my server, so that I can give the user an appropriate
>> warning message:
>>
>>  `Please enable document verification in your browser caching setup,
>>   as the correct working of this service depends on it'.
>
>So you want something from the client, like max-stale.

Yes.  Else I will be forced to keep using cache busting techniques,
because I am making dynamic services that try to never confuse users
who are not protocol designers.

>> OK, now for a constructive proposal.
>> 
>> If you insist that HTTP/1.1 must make it legal for user agents and
>> proxy caches to ignore a Cache-Control response header, then I insist
>> that user agents and proxies always warn origin servers about doing so
>> by including a particular header in every request:
>
>Nope -- it would just be abused by service providers.

I don't see how this could be abused.  Please give an example.

>  Besides, the user
>may change settings after the request is made.

My "may-not-refresh" directive accounts for this: if the user goes to
`never check' mode in the middle of a stateful session, I can pop up a
warning the first time I get a new request (e.g. a POST request).

>  Why not just send a
>Warning header in a response to any request containing max-stale?

My proposed header is basically a refined version of max-stale.  
I would be happy with max-stale

 1) if it can express any kind of `never check' mode we can imagine
    now
 2) if clients are required to send it if they may be planning to 
    weaken caching rules.

I don't know if both these requirements are met by max-stale, that is
why I made a new header definition.

Let me repeat:

|Authors of stateful services have the need to protect users who use
|software with weakened caching restrictions from shooting themselves
|in the foot.  For commercial stateful services, both the law and the
|marketplace demand that this protection is provided by service
|authors.

You seem to be saying that the end user's need for control is so
important that it prevents us from satisfying any other needs.  This
is a ridiculous position.

Elsewhere in this thread, you write:

>Browser authors will try to do whatever they can to ensure that the
>user can do what they want, regardless of what the HTTP specification
>says.  After that has been achieved, they will (hopefully) try to do
>what is wanted in the most interoperable way, which is (hopefully) the
>way described in the HTTP specification.

I can assure you that commercial stateful service authors will try to
do whatever they can to ensure that they won't be sued by users who
inadvertently bought 123423 pizza's because of a `semantically
intransparent' browser caching stategy thought up by some browser
author who decided that the users needed it, or because of a proxy
cache maintainer thinking that it won't hurt to cache everything at
least 1 minute.  After that has been achieved, they may try to make
their applications more cache-friendly.

I can also assure you that I, as the author of a non-commercial
stateful service, will keep using cache busting techniques as long as
these will significantly reduce the chance of user confusion, because
I value lack of user confusion higher than performance.

If HTTP/1.1 does not allow both browser authors and stateful service
authors to do what they need to do while still being compliant, then
the http-wg will have failed to produce a protocol that can guide us
out of the current mess.  I won't let that happen if I can help it.

So again: If you insist that HTTP/1.1 must make it legal for user
agents and proxy caches to ignore a Cache-Control response header,
then I insist that HTTP/1.1 requires user agents and proxies to always
warn origin servers if they may do so.

> ...Roy T. Fielding

Koen.

Received on Sunday, 25 February 1996 18:34:55 UTC