- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 9 Jan 1996 18:57:07 +0100 (MET)
- To: mogul@pa.dec.com (Jeffrey Mogul)
- Cc: koen@win.tue.nl, http-caching@pa.dec.com
Jeffrey Mogul:
>
>And my replies:
>
[Koen Holtman:]
> - I'd rather not require servers to generate opaque validators, though
> I do want to require clients and proxies to use them if present.
>
>I currently have this as
> An HTTP/1.1 server MUST [XXX SHOULD?] return a cache-validator
> value, which could be null, with every response.
>(Actually, this should probably be "with every response to a cachable
>method", which requires some additional definition.) In other words,
>I'm keeping it open as an item for discussion.
My point in this discussion is that the MUST should be a SHOULD.
>Could you provide some discussion of why servers should not be required
>to generate opaque values?
Opaque validators only improve on the use of Last-Modified times as
validators in a small number of cases. If the service author knows
that the 1-second accuracy that the date provides is more than enough
resolution, he should not be required to go through the trouble of
generating a header with an opaque validator.
This boils down to what Roy has been saying: if you want to require
the service author to do extra work, there should be some extra
benefit involved.
> And some indication of what a client should
>do if a server doesn't provide one? (Revert to GET I-M-S?)
Yes.
> - In section 2.3, it says that there needs to be a clear definition of
> `correct' (I agree to that), but the section fails to give a clear
> definition.
>
>I do give a definition; please explain what is unclear about it, or
>suggest your own.
The definition is not unclear, it is _absent_. Qouting:
| This depends on a clear definition of what it is to be ``correct.''
| I will start with this definition:
Now comes indeed a clear definition:
|
| A response returned by a cache in request to a request is
| correct if and only if it is exactly the same response that
| would be returned by the origin server to the same client
| making the same request at the same time.
No problems so far, but:
| This is somewhat of a simplification. For example, it is neither
| necessary nor desirable if the cache's response includes the same
| fresh-until time that would come from the origin server.
So the above clear definition is wrong. OK, I'm waiting for a
better version.
|
| Another way to look at correctness is that:
|
| A user should never have to take explicit action to see exactly
| the version of an entity that the server wants the user to see.
The above not an improved definition of correctness of responses.
| Users should not have to use ``Reload'' buttons to simply assure
| themselves that they are seeing valid copies. One will still have to
| use ``Reload'' to refresh the page currently on your screen, but only
| to indicate to the user agent that you have finished reading it and
| are willing to see a new copy, if any.
The above not an improved definition of correctness of responses.
| With this (somewhat informal) definition of correctness
^^^^^^^^^^^^^^^^^
I can't find a definition, even one that is somewhat informal.
> - I have no big problem with clients using `stale-max=...' to override
> a lifetime set by the server, as long as the addition of stale-max
> does not mean that service authors loose their ability say that a
> response must really _never_ be served from a cache without
> validation (interactive web services often generate such responses,
> and no, they cannot do without them).
>
>Here's my dilemma: we can specify ways for the server to override
>the client's choice, and for the client to override the server's
>choice. When they disagree, who wins?
The server always wins.
The server is able to generate pages in which the link URIs always
have a freshly made random component. Such links will simply make the
caching of old link contents irrelevant, because these contents will
never be re-linked to. I currently use this `cache buster' technique
to deal with the Lynx cache, which won't listen to Expires headers.
Note that `cache busting' is not exactly what you would call nice on
bandwidth requirements. Therefore, the 1.1 spec needs to give service
authors a way to win using less wasteful techniques, techniques that
at least allow conditional GETs.
> One could argue that since
>the server is where the "application" is defined, if the server
>absolutely insists on something, then the client must yield. Or
>one could argue that since this is all ultimately meant to keep
>the users happy, that they need to remain in control. I have
>a slight leaning to one side of this argument, but I don't have
>a strong justification for my leaning so I'd like to see what
>other people think.
If we decide on having stale-max, I think we can provide an optimal
answer to this issue by speccing `stale-max' in such a way that it
overrides `max-age=0' response headers, but does not override
`no-cache' response headers. This allows the service provider to
express whether he really means it.
> - (2.11) If the warnings are in a response header, they should not use
> numbers from the Status-Codes space.
>
>Why not?
Because it will make the spec harder to read. It is a bad idea to
give the same name to numbers that are not used in the same place.
> - In `2.14 Side effects of GET and HEAD':
> | Section 14.2 (``Safe Methods'') of the draft HTTP/1.1
> | specification [1] implies that GET and HEAD methods should not have
> | any side effects that would prevent caching the results of these
> | methods.
> This interpretation of 14.2 is completely incorrect. Ever heard of
> page counters?
>
>Good point about page counters. And yet, it's quite clear that
>the draft 1.1 specification allows caching of GET and HEAD methods
>unless the server specifies otherwise.
Yes. It also clearly allows servers to produce side effects when
processing a GET or HEAD.
>Is it OK if I change this
>to be:
> Section 14.2 (``Safe Methods'') of the draft HTTP/1.1
> specification [1] implies that GET and HEAD methods should not have
> any side effects that would prevent caching
Side-effects never prevent caching, response headers do.
> the results of these
> methods, unless the origin server explicitly prohibits caching.
This would still mean that most page counters in use today are in
violation of your interpretation, because these counters to not
generally produce Expires headers.
>Anyway, the point of this paragraph (especially the last sentence)
>was to try to make things more explicit. Do you disagree with
>that statement:
> We make this explicit: normally, GET and HEAD methods SHOULD NOT
> have side effects.
Yes, I disagree with that statement. Side effects may be present on
GET and HEAD, and should be considered a feature if they are. The
presence of side effects does not mean that the response will change!
Updating of a log file, from which an access graph is produced at a
later time, is a side effect.
>Should I replace "normally" with "unless the server explicitly
>disables caching"?
No, you should make it clear that the side effects talked about in
14.2 are orthogonal to the question whether a response can be cached.
>-Jeff
Koen.
Received on Tuesday, 9 January 1996 18:34:14 UTC