W3C home > Mailing lists > Public > http-caching-historical@w3.org > March 1996

Re: On transparency

From: Koen Holtman <koen@win.tue.nl>
Date: Sun, 3 Mar 1996 23:40:26 +0100 (MET)
Message-Id: <199603032240.XAA05353@wsooti04.win.tue.nl>
To: fielding@avron.ICS.UCI.EDU (Roy T. Fielding)
Cc: koen@win.tue.nl, http-caching@pa.dec.com
Roy T. Fielding:
>
>> |Authors of stateful services have the need to protect users who use
>> |software with weakened caching restrictions from shooting themselves
>> |in the foot.
[...]
>Any commercial service which depends upon
>Cookies in order to ensure such protection is already broken, since
>cookies will still be cached by HTTP/1.0 clients and proxies.

Sure, such a service is broken _now_, because many 1.0 clients and
proxies don't care about Expires headers.  

What I am aiming at with cookies and max-stale/local-max-stale is to
get out of the current mess, but of course this won't happen
overnight.  I am well aware that stateful web services that provide
adequate levels of robustness can only be written for web software in
general use once all semantically intransparent 1.0 software is not
generally used anymore.

>Cookies are a poor design for implementing market-basket functionality
>in an HTTP client/server environment.  The correct design is to maintain
>the market basket within the client state, and to simply POST that
>basket to the cashier's URI when the user wishes to perform the actual
>purchase transaction.

Cookies do far more than just provide market basket functionality,
they are a general mechanism for building stateful services.  I myself
see stateful shopping services as one of the least interesting
stateful applications.

[...]
>There does not exist any complete solution to the unreliability of
>state in the header fields, since any stateful interaction across the
>wire is contrary to the original design of HTTP as a stateless protocol,
>and thus contrary to the way applications want to behave.

Nonsense, you are confusing network layers here.  As far as stateful
services are concerned, the stateless core of HTTP is just the layer
that delivers the events and the data.  The stateful part sits on top
of that.

> ...Roy T. Fielding

Koen.

 From mogul@pa.dec.com  Tue Mar  5 02:35:20 1996
Return-Path: mogul@pa.dec.com
Received: from gizmo.lut.ac.uk (exim@gizmo.lut.ac.uk [158.125.96.46]) by weeble.lut.ac.uk (8.7.4/8.6.9) with SMTP id CAA04500 for <http-caching-archive@weeble.lut.ac.uk>; Tue, 5 Mar 1996 02:35:20 GMT
Received: from mail2.digital.com [204.123.2.56] 
	by gizmo.lut.ac.uk with smtp (Exim 0.42 #1)
	id E0ttmaj-0002Qy-00; Tue, 5 Mar 1996 02:35:09 +0000
Received: from pobox1.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA16339; Mon, 4 Mar 1996 18:19:36 -0800
Received: by pobox1.pa.dec.com; id AA08607; Mon, 4 Mar 96 18:16:24 -0800
Received: from acetes.pa.dec.com by thera.pa.dec.com; (5.65v3.2/1.1.8.2/13Jul94-0558PM)
	id AA28352; Mon, 4 Mar 1996 18:15:07 -0800
Received: by acetes.pa.dec.com; id AA07372; Mon, 4 Mar 96 18:15:05 -0800
Message-Id: <9603050215.AA07372@acetes.pa.dec.com>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: http-caching@pa.dec.com
Subject: Roy's NOTE TO JEFF (regarding Cache-control syntax)
In-Reply-To: Your message of "Sun, 25 Feb 96 03:09:10 PST."             <9602250309.aa14050@paris.ics.uci.edu> 
Date: Mon, 04 Mar 96 18:15:05 PST
From: Jeffrey Mogul <mogul@pa.dec.com>

Due to poor weather and incompetent airlines (up, up, and away!) I am
back from my vacation a day later than I intended, with over 500
email messages to read before leaving for LA tomorrow.  So it's
somewhat a matter of luck that I found Roy's NOTE TO JEFF buried
in an only partly related message.

Please try to use separate Subject: lines for separate topics,
especially when you are addressing an individual.

Anyway, Roy writes.
   I do not believe that any change to the name "max-age" is acceptable,
   given that it DOES mean the exact same thing on both request and response.
   That means that "fresh-min", "fresh-life", whatever is NOT acceptable
   to me.

Frankly, I don't think it makes much difference how these names
are spelled, as long as they don't take too many bytes.  After all,
not everyone speaks English anyway.  Although some people would
prefer to use different directive names in different directions,
and some people would not, it's not worth fighting over.

However, "fresh-min" has an entirely different meaning than
"max-age", and unless you can come up with a coherent argument
about why the client should not be given the choice between
the two kinds of constraint (an argument consistent with your
position that the user's "needs" are paramount, of course), we
need both "max-age" and "fresh-min".

   Likewise, "stale-max" is backwards -- it should be "max-stale",

Spelling.  Does this really matter to you?  If so, I'll change it.

   with no =NN meaning infinity (i.e., "never check").

OK, although "max-stale=2147483648" is probably close enough
for most practical purposes, and would result in simpler parsing
rules.

   That would meet my criteria for not requiring HTTP applications
   to be non-compliant.

You seem to have gotten extremely confused about something, so
let me clarify it before this goes any further: I have NEVER intended
that an HTTP client should be prohibited from asking to see stale data,
simply that this shouldn't be done as the default and stale results
used without warning. This also applies to proxy caches.

Is this clear?  I'm willing to keep restating it until everyone
understands it.

-Jeff

 From mogul@pa.dec.com  Tue Mar  5 02:56:35 1996
Return-Path: mogul@pa.dec.com
Received: from gizmo.lut.ac.uk (exim@gizmo.lut.ac.uk [158.125.96.46]) by weeble.lut.ac.uk (8.7.4/8.6.9) with SMTP id CAA04563 for <http-caching-archive@weeble.lut.ac.uk>; Tue, 5 Mar 1996 02:56:35 GMT
Received: from mail1.digital.com [204.123.2.50] 
	by gizmo.lut.ac.uk with smtp (Exim 0.42 #1)
	id E0ttmvS-0002SJ-00; Tue, 5 Mar 1996 02:56:34 +0000
Received: from pobox1.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA05593; Mon, 4 Mar 1996 18:30:14 -0800
Received: by pobox1.pa.dec.com; id AA09103; Mon, 4 Mar 96 18:27:15 -0800
Received: from acetes.pa.dec.com by thera.pa.dec.com; (5.65v3.2/1.1.8.2/13Jul94-0558PM)
	id AA30276; Mon, 4 Mar 1996 18:26:38 -0800
Received: by acetes.pa.dec.com; id AA07440; Mon, 4 Mar 96 18:26:38 -0800
Message-Id: <9603050226.AA07440@acetes.pa.dec.com>
To: "David W. Morris" <dwm@shell.portal.com>
Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
Subject: Re: On transparency 
In-Reply-To: Your message of "Sun, 25 Feb 96 15:57:28 PST."             <Pine.SUN.3.90.960225151353.26725F-100000@jobe.shell.portal.com> 
Date: Mon, 04 Mar 96 18:26:37 PST
From: Jeffrey Mogul <mogul@pa.dec.com>

Just to clarify something:

David Morris wrote:
    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.

I didn't write that paragraph; Roy did.

-Jeff

 From paulle@microsoft.com Mon Mar 11 23:59:00 +0000 1996
Return-path: <paulle@microsoft.com>
Received: from gizmo.lut.ac.uk [158.125.96.46] (exim)
	by weeble.lut.ac.uk with smtp (Exim 0.42 #1)
	id E0twHUR-0005Fx-00; Mon, 11 Mar 1996 23:58:59 +0000
Received: from mail2.digital.com [204.123.2.56] 
	by gizmo.lut.ac.uk with smtp (Exim 0.42 #1)
	id E0twHUP-000465-00; Mon, 11 Mar 1996 23:58:57 +0000
Received: from pobox1.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA27659; Mon, 11 Mar 1996 15:35:53 -0800
Received: by pobox1.pa.dec.com; id AA17229; Mon, 11 Mar 96 15:35:21 -0800
Received: from pobox1.pa.dec.com by thera.pa.dec.com; (5.65v3.2/1.1.8.2/13Jul94-0558PM)
	id AA01653; Mon, 11 Mar 1996 15:34:38 -0800
Received: by pobox1.pa.dec.com; id AA17191; Mon, 11 Mar 96 15:34:14 -0800
Received: from tide10.microsoft.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA25157; Mon, 11 Mar 1996 15:26:28 -0800
Received: by tide10.microsoft.com; id PAA12949; Mon, 11 Mar 1996 15:26:35 -0800
Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3)
	id xma012941; Mon, 11 Mar 96 15:26:31 -0800
Received: from xnet1 (xnet1.microsoft.com [157.54.17.204]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id PAA13275; Mon, 11 Mar 1996 15:29:01 -0800 (PST)
X-Received: from red-16-msg by xnet1 with receive; Mon, 11 Mar 1996 15:24:34 -0800
X-Msmail-Message-Id:  437C10F8
X-Msmail-Conversation-Id:  437C10F8
From: Paul Leach <paulle@microsoft.com>
To: dwm@shell.portal.com, mogul@pa.dec.com
Date: Mon, 11 Mar 96 15:31:01 PST
Subject: Re: "Cache-control: no-cache", "Cache-control: private", and , extensibility
Cc: http-caching@pa.dec.com
X-Msxmtid: red-16-msg960311232403MTP[01.52.00]000000b1-140558
Message-Id: red-16-msg960311232403MTP[01.52.00]000000b1-140558

I think there is reason for no-store, even with evesdropping: the 
connection might be secure (encrypted with SSL/PCT, e.g.), but internal 
to receivers the content would likely be in the clear (especially at 
the user-agent :-) If the information were kept on long-term storage, 
it would expose it to unecessary risk of disclosure.

This is the same kind of consideration as erasing passwords from memory 
as soon as they are finished being used.
----------
] From: Jeffrey Mogul  <mogul@pa.dec.com>
] To: "David W. Morris"  <dwm@shell.portal.com>
] Cc: HTTP Caching Subgroup  <http-caching@pa.dec.com>
] Subject: Re: "Cache-control: no-cache", "Cache-control: private", and 
, extensibility
] Date: Tuesday, February 20, 1996 11:56AM
]
] Oh dear, I'm afraid I've confused matters by assuming that we had
] shared definition for the term "to store".
]
] I was trying to make a distinction between two things a cache might
] do with a data item (response or part thereof):
] 	(1) return it in response to some request other than the
] 	one that cause the cache to receive the data in the first place.
] 	(2) save it in some storage medium (disk, RAM, etc.)
]
] The reason I was making this distinction is that some people
] (specifically Dave Morris) had insisted on the ability to specify that
] caches NOT do #2 for some resources.  Not that I necessarily think this
] is a good thing to put into the protocol, but apparently some customers
] insist on this sort of nonsense (not to bias the discussion or
] anything :-).
]
] I had thought that Roy was using the word "store" in this more specific
] meaning, and apparently he was.  I.e., his clarification today that
] "must not be stored unless the user explicitly requests it through a
] separate action" means "must not be stored by a cache but the user
] may explicitly save the value to a file outside the control of the
] application" (or something close to that).  I'm not quite sure if this
] applies to history buffers, either.
]
] Roy then managed to confuse me again by objecting to my proposal
] for "Cache-control: no-store" because it doesn't solve the
] eavesdropping problem, but I think this is an inconsistent position.
] Either the protocol spec says nothing about "storing" values, but
] confines itself to specifying when they may be "returned" from a
] cache ... or the spec DOES talk about when they can be stored, in
] which case it seems appropriate to give servers and users some
] control over this.
Received on Sunday, 3 March 1996 23:03:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 November 2008 20:51:42 GMT