- From: Dave Kristol <dmk@allegra.att.com>
- Date: Tue, 8 Aug 95 10:47:00 EDT
- To: koen@win.tue.nl
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.w3.org
koen@win.tue.nl (Koen Holtman) wrote (on www-talk):
> Dave Kristol:
> [....]
> > http://www.research.att.com/~dmk/session.html
>
> This proposal is not clear enough about caching. Specifically:
>
> is the session-id header in the request part of the cache key for the
> entity in the response?
No. In section 2.3 I said:
Similarly, a caching proxy must pass back to the requestor any
Session-ID response header it receives, but it must not cache that
header as part of its cache state.
>
> If it is, this means that almost no meaningful caching is possible for
> services using session-id, even if 99% if the entities in the session
> (inline pictures, product description pages) do not depend on the session
> state.
Yes, exactly.
>
> If it is not, session-id may be an unreliable mechanism (in that it cannot
> be used to build reliable statfull dialogs), depending on how pessimistic
> you are about cache administrators adhering to standards.
That's probably true short-term. As you say, the result is unreliable
stateful dialogs if caching proxies don't pass Session-IDs in both
directions.
>
> I'm busy on a session-id proposal that tries to resolve these issues.
> I expect to be posting it at the end of this week.
Excellent.
Dave Kristol
Received on Tuesday, 8 August 1995 07:53:11 UTC