[wsrp-interfaces] Cookies and HTTP

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

wsrp-interfaces message