Re: Possible optimization to State-Info proposal

Dave Kristol:
>
>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.

Me too.  To tell that a GET shouln not be cached, you should use a Pragma:
no-cache or Expires: <yesterday> response header.

>  (Are all gets idempotent by definition?)

Yes.  At least that is my interpretation of the draft http spec.  Note that
it is easy for a service provider to inplement a GET that is _not_
idempotent according to the `idempotent' definition that mathematicians use.
The draft spec forbids a service provider from doing this, though.

>  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.

As I said, this provoking can be done with the usual Pragma and Expires
response headers.

>  > 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.

I explained this in section 6, did you read the explanation there?  The idea
is that you are sending idempotent request most of the time.  If these
cannot cause you to be `tagged' with a state-info header, you have to worry
about getting tagged only some of the time.

>  > 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.

It definately is not: the state-info response headers gotten on an URI can
change through time.  Imagine a POST-URI working as a toggle button.

[...]
>  > 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.

No, the GET is idempotent by definition.  You are confusing non-idempotent
(URI,method) pairs with (URI,method) pairs that give dynamic results.

A (live-snapshot-of-the-coffee-pot-URI,GET) pair is idempotent, but
also dynamic.  The same is true for the (shopping basket,GET) pair.

>  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?

No, I'm saying exactly the opposite.  State-info request headers should not
be part of the cache key (like Accept headers are).  If the response
depends on the value of the State-Info request header, it should be made
dynamic by including the usual cache prevention headers.

>[... 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.

Let me try to rephrase that paragraph:

 Suppose that a response is dynamic, i.e. suppose it has a Pragma: no-cache
 or Expires: <yesterday> header.  This means that the proxy is forbidden
 from caching the response.  Suppose that the proxy, for whatever reason, is
 unwilling or unable to comply to this restriction.  If this is the case,
 and State-Info headers are involved, them the cache should return a HTTP
 error code 501 (Not Implemented) to the requesting client, and throw away
 the response.

 I don't know if you have read the `tuned proxy caches' discussion: the
 above basically says that `tuned' proxies should tell users that
 stateful dialogs through them are not implemented, rather than risk
 breaking the synchronisation between server and user agent by
 inappropriately caching dynamic responses.

>[...]
>  >           (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.

They will always be is the service provider makes all responses dynamic.

[...]
>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).

I made my message so long because I felt that Shel Kaphans previous message
did not make a clear enough distinction between `dynamic responses' and
`responses to non-idempotent requests'.  I guess I haven't entirely
succeeded in making this distinction much more clear either.

>Dave Kristol

Koen.

Received on Sunday, 27 August 1995 08:08:07 UTC