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.
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.
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.
Not sure about XHR, I'm not an AJAX expert.
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.
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.
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. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
