Re: State-Info is too fragile...

-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] --

Dave kristol wrote:
 > I see the need to add a section about possible implementation details.
And
> that's what I think this is.  

I agree that much of what I have been discussing is implementation detail --
not protocol requirements. I believe it is appropriate to consider a range
of potential implementations before finalizing protocol decisions.

> That's what I had in mind.  But the key isn't so much that the request is
for a
> different URI.  If it's for a different (new) application, then you
probably
> want to sustain the Foo information and start something for the new
> application.  So you'd probably get
>         State-Info: Foo Bletch

My assumption is that servers will provide some private method, not to be
defined in your proposal, for binding multiple CGI's, URI's etc. into
"applications," "scopes," or "realms." These methods will probably be
similar to those which are used by servers to define membership in
authentication realms. i.e. single files, itemized lists of files,  all
files in a directory, all files in a subtree of the file system, etc.

> what you're saying is that the server should
> segregate incoming State-Info in such a way that if there is State-Info
for two
> disjoint applications (for lack of a better term), the server should
process
> the request only with the state that's applicable to the corresponding
> application.

Precisely.

>> resources. If the amount of data in State-Info is large and the
>> number of "useless" exchanges also large, the overall impact could
>> be very bad. Thus, it would seem reasonable to warn creators of ...
>Agreed. Cookies have some similar problems, though perhaps less severe.

The maximum necessary "State-Info" under your proposal, given aggressive
"State-Info Compression," might be as small as one byte if the server uses
the State-Info value plus the requestor's IP address as the key to its State
-Info buffer and if there are a small number (<64) of concurrent sessions
with any single IP address. If we further assume that the server is expiring
sessions, it would be very surprising to ever see State-Info grow beyond the
two or three byte range! Netscape cookies have a minimum length of three
bytes "X=Y" and will normally have much greater length. The real "resource
saving"  advantage held by Netscape cookies is that they have the Path
attribute which can control how often the cookie is sent over the wire.
Given small State-Info sizes, this advantage is not really worth the added
client side complexity. Especially since the cookie proposal is weaker in
privacy protection, security, etc.

Given the potentially tiny bits of State-Info that need to be transferred by
network friendly servers, you might want to rename "State-Info:" to be
simply "State:". By doing so you would ensure that your tag (currently 11
bytes long) isn't so much larger than the data it tags.

		bob wyman

Received on Friday, 11 August 1995 17:44:19 UTC