Re: Cookies

Hi Paul,

Paul Prescod wrote:
> 
> Can you please clarify the requirement for cookies? A cookie is extra
> information that is passed along with a request. A SOAP message uses an
> extensible syntax designed to transmit arbitrarily complex information.
> 
>  a) Why would you need to put the cookie in a header.
> 
>  b) What is the benefit in having a *standardized* cookie syntax rather
> than transmitting the same information as a random XML element in your
> favorite XML namespace. myns:mycookie
> 
> Or even better, you could just transmit the information represented by
> the cookie explicitly (e.g. your customer id, your authentication
> information, etc.).

It's all about complexity. The simplest way to define communicating
systems with persistent state is to specify only those parameters that
are required for each call, and assume that there is a persistent link
so that state management can be handled implicitly.

But you can't actually implement things that way using protocols like
HTTP which don't have reliable persistence. So an alternative would be
to explicitly include the cookie information in each message, as in your
final suggestion. There are three problems with this approach:

[1] it creates unnecessary linkage between messages, and makes it harder
to re-use messages between applications with, say, different
authentication requirements. 

[2] it increases linkage between design and implementation - why should
I have to specify at design time whether servers will store state
locally and simply require the client to persist a session key, as
opposed to a more scalable but higher comms overhead approach of storing
the entire state in a cookie? 

[3] state information requires a particular behaviour on the client.
Must this behaviour be signalled and implemented through new ad-hoc
methods every time?

When you consider these factors you see why HTTP cookies, which are a
limited but mature technology, make such an attractive alternative. All
you have to do is stuff the necessary state data or session key into a
cookie and cross fingers that the client doesn't have cookies disabled,
and that you will never have to re-implement the application over a
transport layer that doesn't have cookies. In my world, this would be a
slightly reluctant no-brainer.

What I'd like to see would be a standard for achieving the same
productivity in a transport-independent way. I'm not an expert in the
implementation of cookies, but I'll suggest a possibly adequate solution
to fuel discussion. Servers should be allowed to return in a header a
session element with optional key, actor and expire attributes, and
optional any content - something like:

	<xs:complexType name="SessionType">
		<xs:sequence>
			<xs:any minOccurs="0" maxOccurs="unbounded"/>
		</xs:sequence>
		<xs:attribute name="sessionId" type="xs:hexBinary" use="required"/>
		<xs:attribute name="actor" type="xs:anyURI"/>
		<xs:attribute name="expire" type="xs:dateTime"/>
	</xs:complexType>

	<xs:element name="Session" type="env:SessionType"/>

...with some standard behaviour: all cookies are uniquely keyed by actor
(explicit or default) and sessionId. They can be made to live beyond a
conversation by specifying an expire date (or time). Opening a
conversation to a SOAP host would pick up any long-life cookies for that
host and include them in the header. During the conversation only
cookies fresh from the server get returned to the server. The server can
update a cookie by sending it back with the same sessionId but different
contents. It can delete a cookie by sending it back with a back-dated
expire date. It can ignore cookies by not sending them back.

Then add a fault message for "could not resume conversation", and I
think you would have a very satisfactory solution that would get used.

Francis.

Received on Monday, 27 August 2001 06:30:37 UTC