[wsrp-interfaces] Cookies and HTTP

Title: Message

Mike Hillerman, Mike Freedman, Alejandro, and others,

 

The recent correspondence around cookies and HTTP raises a few valid issues, but also 
brings about some confusion.

 

First, cookies 
are not part of HTTP. They are not mentioned in RFC2068 
(HTTP/1.1), but are rather built as a mechanism 
on top of the (extensible) HTTP protocol to support a way 
"clients and servers that 
wish to exchange state information to place HTTP requests and responses within a 
larger context", which is RFC2109. 

 

What's important is that 
RFC2109 does not define what the context of communication is. 
The context we are all familiar with is the context of a user browser that 
shares cookies across windows. So if you open two browser windows then they tend 
to share cookies, but this is not defined anywhere, and isn't necessarily the 
case if the browsers are launched in separate processes, and obviously if you 
have both IE and Netscape open simultaneously.

 

What the above statement 
means is that SOAP infrastructure does not, and will not, 
support cookies in HTTP. Firstly, because cookies are not really HTTP. But more 
importantly, because it has no way of knowing what the "context" is. In some 
cases, a single context is established between a client and a server. In some 
cases, it will be more than one (as in the case of WSRP, where there's at least 
a context per user). The SOAP infrastructure cannot tell what's a context 
without an explicit mechanism to do so. Such mechanisms may be built in the 
future as part of SOAP, but it is more than likely that they will be built on 
top of SOAP and not as part of the HTTP protocol. Thus, 
requesting a SOAP client to maintain HTTP cookies across requests completely 
contradicts the SOAP model.

 

This still leaves two 
questions: what does WSRP define as a context, and how is load balancing 
implemented.

 

The assumption in the 
F2F was that WSRP defines what a context/session is explicitly as part of 
the WSRP protocol. It was decided that the context (=session) is created by the 
Producer and thus the Producer can optimize its session management. I believe 
that this is important for multiple reasons, flexibility being one, and 
performance being another. Just to connect this to the load-balancing 
discussion, if we had a single session per Consumer-Producer relationship, then 
all the requests for all the portlets would have always had go to the same 
machine at the Producer, which inhibits parallelism even if the portlets have 
nothing in common. However, like any other decision - we can decide to re-open 
the issue and change the spec accordingly, but mind you, this is not a trivial 
change.

 

Load-balancing is a 
serious consideration. Mind you that the same load-balancing issue arises in any 
SOAP-based protocol that needs to establish a context across requests and 
maintain transient state (sessions). Hence, at some point the issue will be 
standardized and implemented at the application server level, probably when 
state will be added to SOAP. In the meanwhile, as Carsten suggested, it seems 
that the Producer will have to handle this in a proprietary way (e.g., write a 
filter that puts the SOAP parameter into a cookie, forward the request to a URL 
that includes the cookie, etc.). This is not an optimal solution, but I just 
don't see how we can rely on custom handling of HTTP cookies in a SOAP-based 
protocol.

 

Eilon