W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Possible optimization to State-Info proposal

From: Dave Kristol <dmk@allegra.att.com>
Date: Fri, 25 Aug 95 18:14:05 EDT
Message-Id: <199508252216.AA204908989@hplb.hpl.hp.com>
To: koen@win.tue.nl
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
koen@win.tue.nl (Koen Holtman) wrote:
  > [...]
  > Let me try to summarize the state-info/caching requirements we seem to
  > have converged at, in the form of modifications to
  > draft-kristol-http-state-info-00.txt.  Dave, feel free to cut and
  > paste from the text below if you can use it.
[...]
  > 4.1  Origin Server Role
  > [...]
  > An origin server may only include State-Info headers in responses to
  > non-idempotent requests.  (Non-idempotent requests are all request
  > that do not use the GET and HEAD methods)
Sorry, I don't agree with this.  I can imagine GETs that should not be
cached.  (Are all gets idempotent by definition?)  Consider my favorite
"Show me my shopping basket" link that, when selected, sends a "GET
/cgi-bin/shopping-basket HTTP/1.x" to the origin server, along with
State-Info.  This is one request that the proxy MUST pass along to the
origin server.  Perhaps to provoke the proxy not to cache the result,
the origin server must send back the same State-Info header.
  > 
  > [...]
  > 
  > 4.2  User Agent Role
  > 
  > [...]
  > 
  > For reasons of privacy protection (see Section 6), a user agent should
  > ignore State-Info headers contained in responses to idempotent (GET
  > and HEAD) requests.
I don't understand the connection between privacy protection and
idempotent methods.  The only State-Info headers that the user agent
should be getting are its own.  My (new) rule was that caching proxies
could only cache responses that have no State-Info response header.
So, if you're worried about State-Info coming from a cache, there
shouldn't be any.

  > 
  > A user agent in the state ``have state-info'' should include a
  > State-info request header in all requests to the origin server, whether
  > these are idempotent or not.
Yes.
  > 
  > Caches in user agents should be careful to implement the caching
  > semantics defined in the HTTP protocol, especially when handling
  > requests or responses containing State-Info headers.
I think it's safe for a user agent to cache responses that contain
State-Info headers, though I haven't thought it through carefully.
  > 
  > If the user agent allows the user to configure the its cache to
  > 
  >   `check the for validity of document (i.e. issue conditional get if
  >    expired) only once per session',
  > 
  > this configuration option (which makes the user agent violate the HTTP
  > specification anyway) should not override HTTP cache semantics for
  > transactions where requests or responses containing State-Info headers
  > are involved, as this will make stateful dialogs impossible or, worse,
  > dangerously unreliable.
  > 
  > [...]
  > 
  > 4.3  Caching Proxy Role
  > 
  > Caches that conform completely to the (draft) HTTP 1.0 or 1.1
  > specification need not be changed to support State-Info.
  > 
  > As per the requirements in the HTTP 1.0 and 1.1 drafts, caching
  > proxies
  > 
  >   + must never cache responses to non-idempotent requests
  >     (note that the drafts probably need to make this requirement
  >     more explicit)
Note my comments above about State-Info and GET.
  > 
  >   + must not cache a response to an idempotent request if the response
  >     contains a Pragma or Expires header with a value that disallows
  >     caching
  > 
  > Thus, origin servers can expect that proxies forward to them:
  > 
  >  - all non-idempotent requests (which may be carrying State-Info
  >    headers) issued by user agents
  > 
  >  - all idempotent requests (which may be carrying State-Info headers)
  >    for every `dynamic' URI D issued by user agents.  An URI D is
  >    `dynamic' if the server has consistently put Pragma or Expires
  >    headers disallowing caching in every response message to
  >    non-idempotent requests for URI D.  Proxies may `downgrade' normal
  >    GET requests to conditional GET request when doing the forwarding.
  > 
  > An example of a `dynamic', idempotent URI is a `shopping basket
  > contents URI' will typically be accessed with the GET method: the link
  > to the shopping basket page will be a normal HTML <A HREF=...> link,
  > it need not be a form submit button.
Well, hello there!  Ummm, this GET is idempotent only when the
State-Info is the same in a second request.  So let's see, are you
saying that State-Info is part of the cache state and therefore won't
match the request unless State-Info matches, too?
  > 
[... more cache stuff...]
  > Proxy caches that, for whatever reason, are unwilling or unable *not*
Ummm, double negatives give me headaches.  Are you saying what you meant
to say.  It sounds like 501 gets returned only when the proxy understands
what's going on.
  > to cache a `dynamic' entity belonging to an URI D should, if
  > State-Info headers were present in the request or response for D,
  > return a HTTP error code 501 (Not Implemented) to the requesting
  > client.
[...]
  > 5.  IMPLEMENTATION CONSIDERATIONS
[...]
  > The state-info facilities only allow origin servers to track user
  > access to non-idempotent and `dynamic' idempotent URI's.  A `library'
  > or `magazine browsing' server may want to track all URI's accessed by
  > the user, allowing it to show a list of articles looked at already.
  > This tracking could be accomplished by making all pages `dynamic', or
  > by including a small `dynamic' inline picture on every page.  However,
  > if neither the user agent nor any proxy close to the user agent has
  > conditional GET capability, this technique may cause an unacceptably
  > large amount of web traffic to be generated.
This is (to me) an unwelcome consequence of my agreeing that proxies
don't have to pass through State-Info for cached items.
  > 
  > 
  > 6. PRIVACY
  > 
  > [...]
  > 
  > The requirement on user agents to ignore all State-Info headers
  > contained in responses to idempotent requests (GET, HEAD) helps to
  > protect the privacy of the user.
I don't understand why.
  > 
[...]
  > [Note: the following addition addresses the privacy problems I
  > discussed in my previous message in this thread.  The non-idempotent
  > requests rule discussed above makes solving these problems relatively
  > straightforward.]
  > 
  >    + It is recommended that a user agent should, as a configuration
  >      option, be able to pop up a dialog box when receiving a
  >      State-Info response header, like this:
  > 
  >         ---------------------------------------------------------
  >           Start a session with server foo.bar? 
  >            [ Yes ]
  >            [ Yes, always ]
  >            [ No ]
  >           (Help information: Starting a session will allow foo.bar
  >           to gather accurate statistics of your actions)
Actually, not, since requests using idempotent methods might not get
passed along.
  >         ----------------------------------------------------------
  > 
[...]

Sorry, it's been a long day, Koen's message was a long one, and I may
have spewed nonsense up there.  And caching is not my strong point (as
has probably been obvious before).

Dave Kristol
Received on Friday, 25 August 1995 15:17:48 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:26 EDT