- From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
- Date: Mon, 26 Feb 96 10:40:56 CST
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> > > Jeff Mogul summarized the sense of the subgroup as: > > > > Applications in which HTTP is used span a wide space > > > > of interaction styles. For some of those applications, > > > > the origin server needs to impose strict controls on ^^^^^^^^^^^^^^^^^^^^^^ > > > > when and where values are cached, or else the application > > > > simply fails to work properly. > On Sun, 25 Feb 1996, Daniel LaLiberte wrote: > > It simply can't be done, unless you want signatures on client > > applications to verify they are approved software that obey the strict > > controls. Until then, clients can and will do whatever they please. David W. Morris writes: > Based on that assumption, there is no point in any of our work. That would be going too far. While what I said is true, it is also true that clients that don't work well with servers, as far as users are concerned, will not survive in the marketplace. > Those of us who disagree with Roy are not so naive as to believe > the we can force compliance, Imposing strict controls sounds like forcing compliance to me. That's what I was reacting to. > only that we should define failure to follow the server's direction > as a non-conforming implementation. In general, drawing the line is OK, but for some features it is the wrong thing to do. Regarding the no-cache directive, it should always be possible for a client to actually keep and use a copy of anything it gets, unless you want to impose legal restrictions (e.g. copyright). The *behavior* we want is that a user should not naively use a document the server has declared as obsolete, unless the user *wants* to use it. We don't have to declare non-conformance to get this kind of behavior. (i.e. it's not necessary) We can simply recommend reasonable default behavior and signals to the user if something else is being done. If a server really wants to require that a form is never submitted twice, for example, it really ought to be verifying that fact (e.g. using hidden data) rather than depending on clients, which may in fact be non-compliant. In other words, declaring clients non-compliant doesn't really help stop the behavior. (i.e. it's not sufficient) Although it is not necessary and not sufficient, it won't hurt too bad - it would be mostly meaningless. Say, this sounds like "URN:". Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/
Received on Monday, 26 February 1996 08:45:32 UTC