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.

Consider that you and I each establish a "session" with the same server
and each set two "parameters" which mean "I like verbose error messages"
and "I want English error messages. We set these two parameters
identically but we get back two different tokens representing our
"session." We pass those tokens as the first parameter to every method
call (to avoid passing the two parameters). 

A cache will not know that the tokens are functionally equivalent.
Likely the tokens only live for a certain period of time, so we can't
store URLs to the method call results away because they will be invalid
when the token is discarded (no distributed GC!). That presumes that
there was even a syntax for the method calls which there isn't right
now. In many (most? all?) cases, it would be better to keep the
connection stateless and just send the parameters over and over again.
It seems inefficient but if it triggers cache hits it may turn out
better.

Re: SOAPAction. I agree that it is just another thing to go wrong. In my
experience, it is one of the less interoperable bits of SOAP today. The
spec should also have an explicit warning about SOAP implementations
that REQUIRE an XML namespace. Often that is just extra useless cruft
that complicates programming also.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook

Received on Sunday, 26 August 2001 07:17:39 UTC