- From: David W. Morris <dwm@shell.portal.com>
- Date: Sun, 25 Feb 1996 15:57:28 -0800 (PST)
- To: HTTP Caching Subgroup <http-caching@pa.dec.com>
On Wed, 21 Feb 1996, Roy T. Fielding wrote:
> Jeff wrote:
> You do see, on EVERY caching browser known to me, the options
> to "check once per session" and "never check". Your summary of the
> meeting consensus would make both those options non-compliant with HTTP/1.1.
If I recall and understand Ari's explanation correctly, this browser option
for Netscape at least deals with the default behavior when expires, etc.
information isn't provided.
Yup, making those options, non-compliant when activated is the point to
the extent that they a UA to ignore caching controls specified by the
owner.
[...]
>
> > I defy you to explain, for example, how Shel Kaphan can make his
> > book-ordering server work in your user-wins model.
>
> That's easy -- give the user an option at the outset regarding how
> they would like to proceed.
You are wrong on this one Roy. There are a class of applications for
which any alternative other than strict obediance to the server's
intent would cause sever breakage. The PROTOCOL *MUST* support
such applications. Any choices are in the domain of the User Agent
such as ... your configuration specifies that you want HTTP caching
rules to be ignored but this page specifies no-cache/no-store you may
1. Termporarily suspend your configuration and allow no-cache
2. Procede at your own risk understanding that the server will be
notified and may choose to reject your request.
To complete this, we add "Cache-control: will-cache" as a required
header/operand when the client cache will cache no matter what the
server indicates.
The server OWNS the data and has the full right to control how it is
used. The user has the choice to not interact with the server or
to accept the terms of the owner. To assert any other right on behalf
of the user is to ignore all existing intellectual property and
copyright law.
How clever a browser is in helping a user remember which sites to
reject is outside the scope of the HTTP protocol. In the protocol,
we must insure that server requirements can be conveyed to the
clients (user and proxy). We must require that clients obey the
server (or as my new proposal suggests, state their refusal).
Secondly, we must insure that the existing more relaxed expires style
protocol work for the vast bulk of transactions where the server
is less concerned.
As Shel has pointed out, failure of the protocol and clients to
conform simply forces server/application implementors to be
conservative and continuously generate unique URLs to completely
bypass any possibility of caching. A lot like forcing users to use
machine assigned long passwords with a view to increasing security.
The resulst is often less security because the users simply write
the passwords down and post them on their displays. The end result
of failure to recognize the server as the ultimate owner of the data
with the ability to control the legal implications of the presentation
of its application/content will result in less caching rather than more.
Dave Morris
Received on Monday, 26 February 1996 00:15:49 UTC