Re: Cookies

"Jones, Matthew" wrote:
> This sounds like a good suggestion however I'd like to add some
> considerations.
> First normally cookies have a domain, which is the set of sites to return
> the
> cookies to.  For example by default if you went to the site and
> got
> a cookie then you would return the cookie to anything ending in
> You
> can change this (or just make it explicit which is often the case) by
> setting the
> domain field.  I'd wonder how this would apply to the SOAP paradigm.  Also
> you
> can send more than one cookie, I'd assume you can send more than one
> Session.  Finally
> how would the browser reply would it just return the sessionId?
Domain matching is probably good for tracking browsing habits of users -
I don't think it's so good for SOAP, unless we also propose to make the
SOAP agent aware of its users, which would open up a real can of worms.
Can you see a situation where it would be needed, or are you mainly
arguing from compatibility with HTTP cookies?

Given that every cookie would have a different session key, I'd suggest
that you would only send more than one when sending all long-life
cookies that match by host at the start of a conversation, and send just
one session cookie per message after that - otherwise you'd need to know
how to match cookies to different components in the message, which
breaks all the encapsulation wide open.

Finally the client SOAP agent would return the entire cookie to the
server - there'd be no point sending cookie content to the client
otherwise - it would just be some kind of application data.


Received on Tuesday, 28 August 2001 00:27:07 UTC