Re: [Standards] Redirects in BOSH
On 5/10/11 1:17 PM, "Glenn Maynard" wrote: > Nothing stops you from using it if the client supports it; the spec doesn't > prohibit other headers from being set. I'm just opposed to BOSH *requiring* > cookie support from clients. You also probably want to test how well cookies work in practice if you're doing CORS. You may find that many modern browsers don't send cookies to CORS domains for security reasons. (sorry if this has been mentioned before in this thread; I skipped to the end) -- Joe Hildebrand
Re: [Standards] Redirects in BOSH
On Tue, May 10, 2011 at 8:50 PM, Evgeniy Khramtsov wrote: > I don't understand your position: "I don't want it, so noone should want > it". That's not how standards are written. > If we can't require it, then we should RECOMMEND it. You're misrepresenting my position, as I've said nothing of the kind. Anyone reading the thread already understands my position, so I'm not going to restate it. This will be my last post on this topic unless someone involved with editing the spec shows an interest. -- Glenn Maynard
Re: [Standards] Redirects in BOSH
11.05.2011 06:17, Glenn Maynard wrote: On Tue, May 10, 2011 at 3:33 AM, Evgeniy Khramtsovwrote: It is pretty possible to make this feature backward compatible: if you don't see Cookie in a packet, you route that packet internally. Nothing stops you from using it if the client supports it; the spec doesn't prohibit other headers from being set. I'm just opposed to BOSH *requiring* cookie support from clients. I don't understand your position: "I don't want it, so noone should want it". That's not how standards are written. If we can't require it, then we should RECOMMEND it. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
On Tue, May 10, 2011 at 3:33 AM, Evgeniy Khramtsov wrote: > 10.05.2011 17:21, Glenn Maynard wrote: > >> Doing it in BOSH would also be a new feature. >> > > It is pretty possible to make this feature backward compatible: if you > don't see Cookie in a packet, you route that packet internally. Nothing stops you from using it if the client supports it; the spec doesn't prohibit other headers from being set. I'm just opposed to BOSH *requiring* cookie support from clients. -- Glenn Maynard
Re: [Standards] Redirects in BOSH
10.05.2011 17:21, Glenn Maynard wrote: On Tue, May 10, 2011 at 3:10 AM, Evgeniy Khramtsovwrote: New feature wouldn't be supported at all, as practice shown: there were XEP about sessions handoffs, now, who can recall it's number? Doing it in BOSH would also be a new feature. It is pretty possible to make this feature backward compatible: if you don't see Cookie in a packet, you route that packet internally. Such scaling is not a way to go: balancing doesn't help you to much until you have too many *shared* data across a cluster. A good approach is taken by SIP folks: they put some pieces of state in packets using record-routing technics and this works very good. I disagree, but I don't have time right now to get into a long discussion about it. If anyone else wants to, feel free... Of course, there are always someone who agrees and disagrees: it's a matter of choice and we need to provide it. If you don't need it you don't use it, that's simple. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
On Tue, May 10, 2011 at 3:10 AM, Evgeniy Khramtsov wrote: > New feature wouldn't be supported at all, as practice shown: there were XEP > about sessions handoffs, now, who can recall it's number? Doing it in BOSH would also be a new feature. Scaling XMPP seems straightforward: load-balance the XMPP/BOSH front ends >> via DNS or any >> other mechanism, and handle message routing behind the scenes. Exposing >> that to the front-ends seems unnecessary, and just introduces ways for >> things to go wrong.) >> > > Such scaling is not a way to go: balancing doesn't help you to much until > you have too many *shared* data across a cluster. A good approach is taken > by SIP folks: they put some pieces of state in packets using record-routing > technics and this works very good. I disagree, but I don't have time right now to get into a long discussion about it. If anyone else wants to, feel free... -- Glenn Maynard
Re: [Standards] Redirects in BOSH
10.05.2011 16:45, Glenn Maynard wrote: On Tue, May 10, 2011 at 2:08 AM, Evgeniy Khramtsovwrote: How that could be done by XMPP??? We don't even have supported in the majority of clients even though that's XMPP core stuff. New XEP will not change things: client developers just don't care about scalability. You don't have support for it in BOSH, either, so either way it'd be introducing a new feature that wouldn't be well-supported for a long time. New feature wouldn't be supported at all, as practice shown: there were XEP about sessions handoffs, now, who can recall it's number? Scaling XMPP seems straightforward: load-balance the XMPP/BOSH front ends via DNS or any other mechanism, and handle message routing behind the scenes. Exposing that to the front-ends seems unnecessary, and just introduces ways for things to go wrong.) Such scaling is not a way to go: balancing doesn't help you to much until you have too many *shared* data across a cluster. A good approach is taken by SIP folks: they put some pieces of state in packets using record-routing technics and this works very good. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
On Tue, May 10, 2011 at 2:08 AM, Evgeniy Khramtsov wrote: > How that could be done by XMPP??? We don't even have > supported in the majority of clients even though that's XMPP core stuff. New > XEP will not change things: client developers just don't care about > scalability. You don't have support for it in BOSH, either, so either way it'd be introducing a new feature that wouldn't be well-supported for a long time. > (If you think there are scalability issues, it would be more useful to discuss them, rather than talking about features in isolation. Scaling XMPP seems straightforward: load-balance the XMPP/BOSH front ends via DNS or any other mechanism, and handle message routing behind the scenes. Exposing that to the front-ends seems unnecessary, and just introduces ways for things to go wrong.) -- Glenn Maynard
Re: [Standards] Redirects in BOSH
10.05.2011 15:52, Glenn Maynard wrote: On Tue, May 10, 2011 at 1:03 AM, Evgeniy Khramtsovwrote: OK, it's not a big deal to use redirects on clients, we can move that part on front-end servers, such as nginx. So I have a question about cookies: is it ok to use them? Are there any problems with them? Should we add a note about them in the XEP? It would be great to push some state in the cookies to avoid state sharing across the cluster. Also, a front-end can use them to make route decision without asking the back-end (XMPP server). It won't work in practice: many clients will just ignore them. That's the sort of thing that should be done by XMPP, not by BOSH. BOSH is just a transport layer; it's another way of transporting the higher-level XMPP protocol. How that could be done by XMPP??? We don't even have supported in the majority of clients even though that's XMPP core stuff. New XEP will not change things: client developers just don't care about scalability. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
10.05.2011 15:03, Evgeniy Khramtsov wrote: 10.05.2011 02:29, Glenn Maynard wrote: ... OK, it's not a big deal to use redirects on clients, we can move that part on front-end servers, such as nginx. So I have a question about cookies: is it ok to use them? Are there any problems with them? Should we add a note about them in the XEP? It would be great to push some state in the cookies to avoid state sharing across the cluster. Also, a front-end can use them to make route decision without asking the back-end (XMPP server). Hum, in the XEP-0124 there are some notes about cookies: 1) BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for "cookies" or even access to HTTP headers. 2) Clients are not required to have programmatic access to the headers of each HTTP request and response (e.g., cookies or status codes). 3) Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. Not sure what that means. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
On Tue, May 10, 2011 at 1:03 AM, Evgeniy Khramtsov wrote: > OK, it's not a big deal to use redirects on clients, we can move that part > on front-end servers, such as nginx. So I have a question about cookies: is > it ok to use them? Are there any problems with them? Should we add a note > about them in the XEP? It would be great to push some state in the cookies > to avoid state sharing across the cluster. Also, a front-end can use them to > make route decision without asking the back-end (XMPP server). It won't work in practice: many clients will just ignore them. That's the sort of thing that should be done by XMPP, not by BOSH. BOSH is just a transport layer; it's another way of transporting the higher-level XMPP protocol. Also, a problem with cookies is that they get sent by the client on every request, whether they're relevant to the request or not. BOSH makes a lot of tiny requests, so using cookies will add significantly to overhead. If you're using TLS with compression enabled it's not a big deal, but often you don't. -- Glenn Maynard
Re: [Standards] Redirects in BOSH
10.05.2011 02:29, Glenn Maynard wrote: ... OK, it's not a big deal to use redirects on clients, we can move that part on front-end servers, such as nginx. So I have a question about cookies: is it ok to use them? Are there any problems with them? Should we add a note about them in the XEP? It would be great to push some state in the cookies to avoid state sharing across the cluster. Also, a front-end can use them to make route decision without asking the back-end (XMPP server). -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
On Mon, May 9, 2011 at 4:13 AM, Evgeniy Khramtsov 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 ( ( ) and compression ( ) 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
Re: [Standards] Redirects in BOSH
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.
Re: [Standards] Redirects in BOSH
On Tue, May 3, 2011 at 8:26 AM, Evgeniy Khramtsov 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 redirect. 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) is a bit different stuff, it doesn't allow you to redirect without closing the C2S session, just because it's 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. -- Glenn Maynard
Re: [Standards] Redirects in BOSH
03.05.2011 22:26, Evgeniy Khramtsov wrote: 26.02.2011 00:26, Matthew A. Miller wrote: On Feb 25, 2011, at 08:14 , Joe Hildebrand wrote: If the redirect comes from a trusted source (e.g. over HTTPS with a verified certificate) then this can work ok, although we've decided that the BOSH see-other-uri error is easier to control through XMLHTTPRequest, particularly when doing CORS. Be careful that you don't blindly accept redirects, however, or you are trivial to man-in-the-middle attack. 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? My thoughts: 1) is a bit different stuff, it doesn't allow you to redirect without closing the C2S session, just because it's 2) if you don't use SSL, then you are affected by MITM attack no matter what transport you use. 3) security considerations of cookies are covered by the RFC6265. Peter is an Area Director of the corresponding WG, so he could say more if there are huge concerns about the topic which stops us to use 30x+Cookies, but he had no objections :) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
26.02.2011 00:26, Matthew A. Miller wrote: On Feb 25, 2011, at 08:14 , Joe Hildebrand wrote: If the redirect comes from a trusted source (e.g. over HTTPS with a verified certificate) then this can work ok, although we've decided that the BOSH see-other-uri error is easier to control through XMLHTTPRequest, particularly when doing CORS. Be careful that you don't blindly accept redirects, however, or you are trivial to man-in-the-middle attack. 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? -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Redirects in BOSH
(NOTE: Below "we" does not mean the XMPP community as a whole; "we" means our employer) On Feb 25, 2011, at 08:14 , Joe Hildebrand wrote: > > On 2/25/11 6:07 AM, "Peter Saint-Andre" wrote: > >> [old thread alert!] >> >> On 12/1/10 12:56 AM, Evgeniy Khramtsov wrote: >>> Is it possible to redirect BOSH requests (probably, using 3xx+cookie or >>> something like that)? The client should not interpret such responses as >>> fatal, e.g. it should not drop the existing session. >> >> I see no reason why not, but it's not described in the spec. Would it >> help for us to add some examples? > > If the redirect comes from a trusted source (e.g. over HTTPS with a verified > certificate) then this can work ok, although we've decided that the BOSH > see-other-uri error is easier to control through XMLHTTPRequest, > particularly when doing CORS. > > Be careful that you don't blindly accept redirects, however, or you are > trivial to man-in-the-middle attack. 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. - m&m smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Redirects in BOSH
On 2/25/11 6:07 AM, "Peter Saint-Andre" wrote: > [old thread alert!] > > On 12/1/10 12:56 AM, Evgeniy Khramtsov wrote: >> Is it possible to redirect BOSH requests (probably, using 3xx+cookie or >> something like that)? The client should not interpret such responses as >> fatal, e.g. it should not drop the existing session. > > I see no reason why not, but it's not described in the spec. Would it > help for us to add some examples? If the redirect comes from a trusted source (e.g. over HTTPS with a verified certificate) then this can work ok, although we've decided that the BOSH see-other-uri error is easier to control through XMLHTTPRequest, particularly when doing CORS. Be careful that you don't blindly accept redirects, however, or you are trivial to man-in-the-middle attack. -- Joe Hildebrand
Re: [Standards] Redirects in BOSH
[old thread alert!] On 12/1/10 12:56 AM, Evgeniy Khramtsov wrote: > Is it possible to redirect BOSH requests (probably, using 3xx+cookie or > something like that)? The client should not interpret such responses as > fatal, e.g. it should not drop the existing session. I see no reason why not, but it's not described in the spec. Would it help for us to add some examples? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
