Disable upgrade to xhr_streaming if cloudflare headers detected #342
Conversation
| function actOnConnectHeaders(headers) { | ||
| if(headers && headers.server && (headers.server.indexOf('cloudflare') > -1)) { | ||
| /* Cloudflare doesn't support xhr streaming */ | ||
| XHRStreamingTransport.isAvailable = function() { return false; }; |
There was a problem hiding this comment.
You're comfortable that this is set globally, not just in this library instance? Will it ever get re-enabled? Don't we expect that the restriction should only apply to fallback hosts?
There was a problem hiding this comment.
Don't we expect that the restriction should only apply to fallback hosts?
Do we? I'm not sure how we're planning on using cloudflare -- mightn't we want to enable it on all endpoints in some circumstances (eg DDOS attack)?
You're comfortable that this is set globally, not just in this library instance?
Are we anticipating that people might have multiple instances of the library connecting to different endpoints?
(If so, there are other parts of the library which don't really work well with multiple instances, e.g. the log level and handler are set globally. If we think there are valid usecases for multiple realtime instances, we should fix those too.
We might, but my point is that once you have detected it on one host it doesn't then mean you want that restriction, forever, on all hosts.
I'm more concerned about the possibility that it never gets re-enabled, than I am about the issue of multiple instances sharing state. |
SimonWoolf
force-pushed
the
cloudflare-xhr
branch
from
bf0f0e4
to
406c475
Compare
Fair enough. Though given you have to reinitialize the lib if you want to change host, making it per-instance solves that, right? (ie no need to also make it re-enablable for a given lib instance) |
But a single library instance might be required to connect to a fallback, and then later be able to use the normal host. You don't think we should try to make streaming work again in that case? |
SimonWoolf
force-pushed
the
cloudflare-xhr
branch
3 times, most recently
from
81f7c28
to
5005a70
Compare
|
Right, yes, of course. Sorry, was being stupid. 5005a70 |
SimonWoolf
force-pushed
the
cloudflare-xhr
branch
from
5005a70
to
8dcfb40
Compare
|
That would work, but TBH I quite like that at the moment the connectionManager instance doesn't know anything about the current host (it's in the transportParams instance which is created by startConnect and passed around to the things that need it). So I'd rather not set properties on connectionManager that depend on what the current host being passed around; this seems cleaner even if it's a couple lines more code |
No description provided.