Re: Possible optimization to State-Info proposal

  > With the recent addition to the proposal that clients stay in the "have
  > state-info" state when there is no state-info in the server's (or cache's)
  > response, this means that caches need not "reflect" state-info either.

  Actually, "reflect" isn't the right word here. It's something more like
  "forward."

Well, I really meant reflect, as in "send back to the requestor as is".
But the proxy wouldn't have to *forward* state-info either.

  I've been awfully tempted on many occaisions to make the same suggestion
  that you have, with much the same reasoning. However, there are at least two
  problems with the proposal:

  1.  HTTP V1.0 only says that the idempotent nature of GET and HEAD is "by
  convention" -- it doesn't really state this as a requirement. Should we
  write protocol that assumes the "convention" is being followed?

Let's put it this way: since we allowing caching, we have already
implicitly written this into the protocol.  Caching results of
non-idempotent methods is functionally different from not caching
them. The cache interferes in the semantics.  If this happens, you
have lost.  So if the spec doesn't make it clear that certain methods
have to have no side effects so that their results can be cached, the
spec needs work.

  2. If you remove the requirement for forwarding of State-Info, you break
  the ability of servers to use State-Info for click tracking. This is,
  unfortunately, one of the applications that State-Info is supposed to
  support. If it wasn't for click tracking, I would whole-heartedly support
  your suggestion.

		  bob wyman

Hmmm.  Bug or feature?  Personally I think statefulness is important
enough to support well even if click tracking isn't supported by the
same mechanism.  


--Shel

Received on Thursday, 24 August 1995 20:25:19 UTC