[Standards] Redirects in BOSH
glenn at zewt.org
Mon May 9 05:57:33 UTC 2011
On Tue, May 3, 2011 at 8:26 AM, Evgeniy Khramtsov <xramtsov at gmail.com>wrote:
> 26.02.2011 00:26, Matthew A. Miller wrote:
>> If the redirect is via HTTP 3xx+cookie, then CORS already has a solution
>> via Access-Control-* headers. However, the XMLHttpRequest objects in
>> browsers don't always let you know this happened. Maintaining the redirect
>> then becomes the responsibility of the browser, which may not be desirable
>> for BOSH (I don't think it's desirable, anyway (-: ).
>> If done via the "see-other-uri" BOSH error condition, then this is
>> definitely a concern. On the plus side, the BOSH software (whether
>> browser-based or stand-alone) knows a redirect is happening in this case, so
>> you have a better opportunity to protect yourself at the application-level.
> So what is the decision? What approach should we choose?
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.
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
As Matthew said, I don't think there's any way to detect that you've been
redirected with XHR. The client may want to know this; for example, to
attempt to resume a session across browser restarts by caching SIDs in
localStorage, you want to know if the server you're talking to has changed.
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.)
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.
So, my strong recommendation is to avoid HTTP redirects.
> 1) <see-other-host/> is a bit different stuff, it doesn't allow you to
redirect without closing the C2S session, just because it's <stream:error/>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards