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. >> 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. >> 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. Food for thought... Mike
