--- On Wed, 6/1/10, Peter Saint-Andre <[email protected]> wrote:
> From: Peter Saint-Andre <[email protected]> > Subject: Re: [BOSH] HTTP session IDs > To: "Bidirectional Streams Over Synchronous HTTP" <[email protected]> > Date: Wednesday, 6 January, 2010, 3:48 AM > On 1/5/10 3:16 PM, Mridul > Muralidharan wrote: > > > > --- On Tue, 5/1/10, Peter Saint-Andre <[email protected]> > wrote: > > > >> From: Peter Saint-Andre <[email protected]> > >> Subject: Re: [BOSH] HTTP session IDs > >> To: "Bidirectional Streams Over Synchronous HTTP" > <[email protected]> > >> Date: Tuesday, 5 January, 2010, 9:50 PM > >> On 12/30/09 8:27 AM, Mridul > >> Muralidharan wrote: > >>> Sorry for the really really late response. We > had > >> solved this by > >>> making the connection manager slightly more > >> intelligent and > >>> introducing inter CM routing for such > packets. > >>> > >>> Note that since for security reasons we would > not > >> prefer CM to be in > >>> http - cookie's are not going to be of much > use > >> anyway. Ignoring that > >>> temporarily, most CM containers (tomcat, > appserver,etc > >> - not the CM > >>> itself) already set some cookie or other. > >> Not every CM is written on top of an app server. > > > > > > I was not specifying appserver actually - but to any > container : that is all cases except where server author > wrote the http server too as part of CM (which is not very > common imo). > > > >>> Additionally, most LB's > >>> loadbalance dont simply do loadbalancing based > on > >> round robin but can > >>> be configured based on other criterion (cookie > would > >> be one - if > >>> http, else IP, subnet, others etc). > >> Right. > >> > >>> So probably requiring or worse mandating this > for CM > >> would not be a > >>> nice idea. > >> It would *never* be required, it would only be > optional for > >> some > >> implementations/deployments. > > > > > > Then why do we need to specify it in bosh spec ? > > If I understood right, the intention is to reinforce > what http spec declares w.r.t cookie handling ? > > That is just simple http behavior imo - which already > elaborates on cookie handling for client, server; accept > conditions, error paths, etc : and probably better left out > of bosh ... my 2 cents. > > The point is to document what people will do if they need > this, and to > standardized the cookie name. This is exactly my worry. Cookie name and value is to be opaque to a client - just the behavior of acking to server is required (which is defined in http rfc) - assuming the constraints are met (domain, path, etc). It would be pretty bad if clients start special casing behavior for cookie "bosh-xyz" and not handling other cookies - because that was the name in the bosh spec. That would non-compliant behavior and also imposes deployment & impl constraints. We could mention that cookie support is recommended, but getting into what kind of cookie behavior patterns are to be supported, the names, etc is slightly discomforting ... Note: most secure & larger deployments dont use http to begin with anyway. Regards, Mridul > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
