[Standards] BOSH with HTTP load balancers
mridul at sun.com
Fri May 4 08:35:38 UTC 2007
Since we recommend https, I am not really sure how useful this will be.
But for http case, do we need to specify this in the main spec itself
(it is a impl-deploy decision) ? Cookie handling is covered by http on
top of which 124 is built.
Maybe an informational xep for 124 would be a good idea where all the
implementation hints could be included (including impl hints on http,
recommended version related mapping). So that the core specs are free of
these details and only document the protocol.
Ian Paterson wrote:
> Bill Bishop pointed out off-list that BOSH (XEP-0124) currently does not
> enable off-the-shelf (hardware) HTTP load balancers to be used. Such
> load balancers know about 'Set-Cookie' and 'Cookie' HTTP headers, but
> not about BOSH 'sid' attributes.
> A small optional addition to the protocol will allow the "Cookie Passive
> Sticky" or "Cookie Insert Sticky" modes of hardware load balancers to be
> employed to distribute a connection manager's load amoungst a cluster of
> machines. I propose adding something like the following two paragraphs
> to XEP-0124:
> "Some connection managers may choose to employ "off-the-shelf" "sticky
> session" HTTP load balancers. To enable such load balancing, a
> connection manager MAY include a "real server ID" value in an HTTP
> "Set-Cookie" header (see RFC 2965) in its Session Creation Response. The
> value MAY be the same as the 'sid' attribute of the <body/> element of
> the response. If a client receives a "Set-Cookie" header from the
> connection manager then it SHOULD treat the value as opaque, and set the
> value of the HTTP "Cookie" header of all its subsequent HTTP requests
> during the session to the value it received in the "Set-Cookie" header.
> If a connection manager receives a Session Creation Request that
> includes a "Cookie" header then it SHOULD ignore the value of the cookie."
> "Note that clients running in restricted environments may not be able to
> read and/or set HTTP cookies, worse, some platforms or network
> components remove cookie-related headers. A connection manager SHOULD
> NOT rely on a client being able to return a cookie with each request."
> - Ian
More information about the Standards