Re: Comments on cachedraft.txt

Roy T. Fielding:
>
>The cache does not exist
>on behalf of the origin server, and therefore any requirements placed
>by the origin server will always be secondary to those of the user.

I disagree: the server should always be able to prevent caching, no
matter what the user wants.  Anything else would be very bad HTTP
design.  I qoute a part of
http://weeble.lut.ac.uk/lists/http-caching/0163.html:

|>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.


>[...] The server is not capable of knowing
>the needs of the user, and it is the needs of the user that take precedence
>in the design of the WWW 

I agree that the needs of the user should be put first.  However, this
does not mean that the user should be able to override caching
restrictions made by service authors, like authors of interactive
shopping sites, who really mean it if they say that a page (e.g. a
shopping bag page) is uncachable.  The user is not served by a HTTP
protocol that encourages such service authors to circumvent caches.

>[...]

>No.  The act of validating an entity changes that entity;

This is only one possible view of what happens in a cache when an
entity is validated.  The 1.1 draft does not say anything about this
now, so you can't just claim that Jeffreys view is wrong.  This is one
area I would like to see filled in.

[...]

>>   The original proposal for ``no-cache'' and ``private'' allows them to
>>   specify particular fields of the response, but it is not clear that
>>   this is necessary or useful.  It means that a subsequent request to
>>   the cache cannot use the entire cached entity.  Does this mean that
>>   the cache should return only a partial entity (which seems relatively
>>   useless)?
>
>What is useless about it?  The requirement is for a cachable entity which
>includes private information within particular header fields for the
>purpose of maintaining state between non-cachable actions (e.g.,
>Cookie).

Oh, so _this_ is what you had in mind!

>Although that information is private, the rest of the entity is public
>and cachable.

Define how the rest of the entity can be used by the cache.  I don't
see when the rest could be usable.  Without such a definition, the
`particular fields' feature _is_ useless.

[I may post more comments on your comments later, I have to catch a
train now.]

> ...Roy T. Fielding

Koen.

Received on Friday, 2 February 1996 17:52:00 UTC