Re: an idempotent idea (think it twice - see what happens)

Balint Nagy Endre:
>
>Shel Kaphan writes:
>>  I do not believe we have decided that Cache-control:
>> no-cache is exactly equivalent to Expires: yesterday.  The difference
>> is that Expires is expressly not supposed to affect history mechanisms
>> ("document stacks"), whereas at least Netscape's implementation of
>> Cache-control: no-cache will affect them, according to Lou Montulli.
>Not yet, as I understood Lou's words.
[...]
>> Can this please be resolved unambiguously?

I too would like to see this resolved.  Else we will see the
development of mutually incompatible ad-hoc substandards outside of
the HTTP spec.  As a service author, I hate it when that happens.

>>  I would like to see it
>> specified that Cache-control: no-cache either must or must not affect
>> history mechanisms as well as caches.  As we already have Expires:
>> yesterday to cause one effect, I suggest we use the directive for the
>> other effect.

Let my try so summarize the issues:

- The `does not affect history by default' rule for Expires was
introduced to allow people like the authors of search engines working
on dynamic databases to use Expires: <yesterday> to express the
dynamism of the database, without this having adverse performance
effects.  See http://www.amazon.com/expires-report.html for a complete
discussion.

- This means that it would be OK to let Cache-control affect history,
Expires would offer an escape hatch.

- However, this would mean that I, as a service author who does not
want to affect history lists, still need to use the counter-intuitive 
Expires: <yesterday> instead of the nice Cache-Control: no-cache.

- Also, many browser users want their browser history lists to contain
the _real_ history, not pages that can be 'updated' by (orwellian)
servers.

- But many service authors (including me) would like to be able to
update history lists sometimes, and most users would not mind a
service doing this as long as it is done in a tasteful way.

- Thus, the most that would be achievable in the area of affecting
history lists would be for Cache-control (or something else) to affect
history lists as a user-configurable option, an option that is switched on by
default.

My own conclusion is that the least controversial thing to do would be
to put in the spec that
 - Neither Cache-control nor Expires affect history list contents (by
   default)
 - browser authors may not introduce features that behave differently
   for Expires and Cache-control headers with equivalent cacheing
   semantics.

[...]
>> In any case, I repeat that using Expires: yesterday for this type of
>> thing seems somewhat twisted to me. 

I agree.

>>We're stuck with it at least for
>> backward compatibility, but the semantics it has acquired seems
>> overloaded.  Another directive would be better.
>But the Expires: <yesterday> doesn't mean, that the entity-body in the
>response isn't cacheable, as John Franks <john@math.nwu.edu> on 16th Aug wrote: 
>"There are also reasons that a request not to cache should be orthogonal to
>the Expires: header." (And I haven't see any arguments, disproving
>this statement.)

I think I did see such arguments disproving this statement.  Anyway,
the most valid counter-argument is that the spec already defines
Expires as a cache control mechanism.  Redefining it as orthogonal to
cacheing would introduce severe compatibility problems.

>The "Expires" header affects cache fetch actions,

I don't understand what you mean by this.

>while the "Cache-control" header affects cache store actions!

I believe the current draft allows it to affect both.

>but:
>The meaning of expires is not enough clear now:
>For a request after the expiry time of a response the client (and intervening
>proxies) shall issue a conditional (maybe unconditional, too) GET toward the
>origin server.
>If the response contains a new entity-body, that replaces the previous one.
>If the response doesn't contain a new entity body:
>1) it may contain a new expiry time, which is an update (replacement)
>for the previous one.
>2) may contain the same expiry time,
>and we don't know, what happened. (update in progress?, update postponed? )

I don't see any problems in a cache handling 2), it just means that
the time at which the entity should be considered stale has not
changed.  In the words of the spec, 2) does not update the status of
the cached entity.

There is no need for a cache to figure out whether an update of the
server-side URI contents has happened, is in progress, or is
postponed.

>3) may not contain an expiry time. Unspecified again. Is it a violation of the
>protocol?  Means cancellation of the original expires header?

Interesting question, the spec is indeed not entirely clear about this
case.  By the way, conditional gets to refresh URI's that used
cache-control response headers have the same problem.

I think it would be best to standardize that a 304 (not modified)
response with no Expires and Cache-control headers implies
cancellation of previous Expires and Cache-control headers.
This would make the headers on 304 most resemble the headers on normal
200 responses to conditional gets.

>Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Koen.

Received on Tuesday, 5 September 1995 07:12:12 UTC