-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/30/09 4:20 PM, Mike Cumings wrote: > On Wed, Sep 30, 2009 at 2:07 PM, Peter Saint-Andre <[email protected]> wrote: >> When Ian Paterson took over maintenance of XEP-0124 from Dave Smith, he >> was adamant that we support the most minimal subset of browsers (or even >> HTTP user agents). While that was a laudable goal, it's not clear to me >> that we need to be so stringent nowadays. > > I'm not in disagreement, though the addition of cookies (or any other > similar spec) does add a small burden to the implementations. Not a > huge deal for something this small, though.
I agree that it does need to be well-specified. Clearly, if a client doesn't mirror the cookie then in certain deployment scenarios it will fail to connect to the CM. This is sub-optimal but unavoidable. Specifying a session ID format will at least make it possible for clients to interoperate if they decide to support cookies. >>> 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). >> Yes, that seems reasonable. > > On closer examination after skimming RFC 2109, this approach looks > like it might work. The cookie's "Domain", "Path", and "Version" > attributes would only be interpreted by the origin server if they were > named "$Domain", "$Path", and "$Version" respectively. This would > result in the origin server interpreting these attributes as > additional cookie values, likely to be ignored. Since the RFC > specifies that origin servers should treat semi-colons and commas both > as cookie delimiters the specification of cookie attributes in the > request shouldn't be a problem. > > I'm certainly no expert at (HTTP) cookie usage though, so perhaps this > is still a dangerous road. I think this road is fairly safe (all those other session ID people have been down it before), but we do need to specify exactly how we expect BOSH clients and CMs to function. >>> 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. >> Do intermediaries look for "SESSIONID" specifically? I'm not an HTTP >> expert, but it's my understanding that different application servers use >> different cookie names -- JSESSIONID, PHPSESSID, and so on. I don't >> think that they all use "SESSIONID" but I might be wrong about that. > > You're probably right. My point was more along the lines of it being > easier to support on an arbitrary load balancer right out of the box > if the spec used an existing standard. It might not makes sense if > there is no predominant standard or if the existing approaches appear > implementation-specific (such as J*, PHP*, etc.). If there is no > prevailing standard, I retract my point; in that case the load > balancer implementors are likely to have made the specific cookie name > easily configurable. Perhaps they have. I don't yet know enough about load balancer implementations to speak authoritatively, though I'm happy to ping people who know more about this than I do. :) I'll do that and report back. 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/ iEYEARECAAYFAkrFGY8ACgkQNL8k5A2w/vyS3gCgzEEY6mWHL2S7ZdTo69pzd2cy bC8AoKS5jR/e7d+HymQtOy/jqFKDviB2 =o4FV -----END PGP SIGNATURE-----
