Peter, Would this not require an addition to XEP-0124 to specify the explicit handling of cookie headers? I'm thinking specifically of the following text in XEP-0124 section 5:
"Requests and responses MAY include HTTP headers not specified herein. The receiver SHOULD ignore any such headers" As-is, XEP-0124 specifies that the incoming "Set-Cookie" header be ignored, not reflected back to the CM in the "Cookie" header on subsequent requests. If cookies are to be used, perhaps some additional specification language could be added with respect to not requiring support for cookie expiration? I'd have to dig into the cookie spec a bit to verify this would be possible but I'm hoping it would allow the content of the "Set-Cookie" header to be blindly reflected back in subsequent requests without the client explicitly having to parse the cookie header value (and thereby have to implicitly also support the cookie spec) when the client does not implicitly support cookies (e.g., the client does not reside in a browser). One final note - the load balancer would need to be given knowledge of the BOSHSESSIONID variable before it would operate as desired. SESSIONID, being in standard use, would work out of the box. Mike On Wed, Sep 30, 2009 at 11:39 AM, Peter Saint-Andre <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Because of how HTTP is deployed, there might be intermediaries between a > BOSH client and a BOSH connection manager (CM). Such intermediaries > might include proxies, caching servers, and load balancers. Some of > these entities, especially load balancers, might redirect an HTTP > request from the client to a different CM. Here is some pretty ASCII art > that shows one possible deployment: > > +----+ -------> CM1 > Client -----> | LB | -------> CM2 > +----+ -------> CM3 > > Let's say that the Client sends an initial request that the Load > Balancer direct to CM1. Unless CM1 can tell the Client to send future > requests to CM1 (e.g., via an HTTP header or a cookie) in a way that the > Load Balancer will pass through, future requests from the Client might > be directed to CM2 or CM3, but those CMs know nothing about the Client's > BOSH session because only CM1 knows about the session. > > Discussions with implementers have led me to conclude that the best way > to do this is for the CM to set a temporary cookie on the client > (containing a session ID) in its response to the first BOSH request, and > for the client to return that cookie value to the CM when it sends > future requests during the life of the BOSH session. > > Many application servers (e.g., Tomcat) use such session IDs and some > BOSH CMs are probably written on top of such app servers, so they > already have support for session IDs out of the box. In the absence of > such an app-server-specific session ID, deployment experience has shown > that it would be useful to define a BOSH session ID. Basically the value > is just an opaque identifier as far as the client is concerned, although > it might have meaning to the BOSH CM (in fact, it might simply be the > BOSH sid from XEP-0124). > > Although we don't necessarily need to standardize this in XEP-0124, I > think it would be good to define a conventional name for the session ID > so that we have improved interoperability across different connection > managers. I propose BOSHSESSIONID as the name for this session ID. If > people would find it helpful, I could add a short informational note > about this to XEP-0124. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrDpdoACgkQNL8k5A2w/vwkCACffbl8zBmSlRYWzGGW7rWBpeLi > 758Ani8LAa7x/14MwnMOxs4ShkEFoqoH > =R9bz > -----END PGP SIGNATURE----- > -- Mike Cumings
