On Mon, May 9, 2011 at 4:13 AM, Evgeniy Khramtsov <xramt...@gmail.com>wrote:
> 09.05.2011 15:57, Glenn Maynard wrote: > >> >> Thinking about this and doing a bit of spec refreshing, a lot of problems >> with HTTP redirects come to mind: >> >> XHR will silently redirect from HTTPS to HTTP if the server tells it to. >> This is a major problem if the client is configured to refuse to connect >> to >> a server insecurely; that's a setting servers should not be able to >> bypass. >> >> > > This should be handled correctly: if a server redirects from HTTPS to HTTP, > then it will have problems. It would be nice if clients handled this better, but they don't. BOSH needs to work actual clients, not only ideal ones. > You want to be sure that requests in a session don't keep going to the >> original server, redirecting every time. This will happen if the HTTP >> client doesn't support caching (or do so correctly) in order to cache the >> redirect. >> >> > > What is a problem here? I think it's mostly an optimization issue for a > client. Remember that the "client" with BOSH is two pieces: the HTTP client and the BOSH application on top of it. BOSH is designed under to allow implementation on less-than-ideal HTTP clients (like XHR). If the HTTP client doesn't handle this correctly, then BOSH would no longer work properly in that environment. Some clients don't redirect correctly. RFC2616 notes: "When automatically >> redirecting a POST request after receiving a 301 status code, some >> existing >> HTTP/1.0 user agents will erroneously change it into a GET request." This >> would be fatal for BOSH. (Even current versions of Wget still do this, so >> there may be client libraries in the wild that still do, too.) >> > > Then this should be fixed in clients and libraries. Sure, but again, BOSH works with actual libraries, not only optimal ones. > RFC2616 also says about all redirect types: "If the 3xx status code is >> received in response to a request other than GET or HEAD, the user agent >> MUST NOT automatically redirect the request unless it can be confirmed by >> the user, since this might change the conditions under which the request >> was >> issued." I don't know how many clients actually implement this >> requirement >> (HTML forms in browsers do, but XHR doesn't), but it would break BOSH. >> > > I don't know why this requirement exists and whether it is applicable for > BOSH since all our requests are POSTs. POST is a request other than GET or HEAD, so it's applicable. I have a hard time seeing session hand-offs ever actually working. They'll >> be rare and require careful handling in clients, so they won't be handled >> reliably, so servers in turn won't use them. It seems a lot saner to just >> terminate the session and negotiate a new one. >> > > You don't need to hand-off a session all the time, sometimes you just need > to redirect a client to a correct node (where the state is kept) to avoid > inter-node traffic overhead. This would require careful handling. You may have several requests in the pipeline; to prevent message loss, the server and client would need to handshake, as with XMPP's TLS ( (<starttls/> <proceed/>) and compression (<compress/> <compressed/>) within XMPP. If you want to support seamless handoffs, I'd suggest proposing it as as an extension to BOSH's protocol. There's no need to try to do this at the HTTP level. -- Glenn Maynard
