Re: POST abuse?

Kurt Cagle wrote:
> 
> 
> Cookies are an attempt to push the state maintenance onto the client.
> Realistically, multiple transactions in a process will need to maintain a
> session token, but that session token should in all truth be passed back and
> forth between transactions in the SOAP message itself. A long term
> subscription services makes caching a transaction id necessary at the very
> least. Still I'm not sure how such cookies or handles, if passed within the
> body of the SOAP message itself, would necessarily place that much of an
> onus upon addressability.
> 
Microsoft uses cookies or URL mangling to store 120 bit session keys for
.NET web services. It seems to me that this rather locks these web
services into HTTP.

Yann Christensen of Microsoft commented in
microsoft.public.dotnet.framework.aspnet.webservices

"Using cookies to maintain session state is pretty widely adopted on the
internet today.

Its more related to HTTP than to SOAP, but any SOAP client that runs
over HTTP will probably have some degree of cookie support.

Over time you will probably see some SOAP headers defined to deal with
this issue in a way that is not transport specific. If you wanted you
could invent your own SOAP header today and use that in combination with
the ASP.NET cache or your own database to maintain state for a given
client."

This seems a reasonable analysis of the current situation to me - but a
more satisfactory alternative to this situation would be to define an
official session key storage element in the SOAP header section. I think
that this might satisfy an immediate and important user requirement,
before less satisfactory solutions get frozen into de-facto standards.

Francis.

Received on Sunday, 26 August 2001 12:30:39 UTC