Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimizing away preflight requests #465

Open
deliminator opened this issue Feb 11, 2017 · 2 comments
Open

Optimizing away preflight requests #465

deliminator opened this issue Feb 11, 2017 · 2 comments

Comments

@deliminator
Copy link

The cross-origin-long-polling transport issues an OPTIONS request before every long-polling POST request. This is because the 'Pragman: no-cache' header is being set on the XHR object by the client.

Is there a specific reason this header has to be set? It would be great if we could either remove it, or add an option that allows one to opt-out of setting this header.

@deliminator
Copy link
Author

Just saw this:

  • Send Pragma: no-cache with XHR requests to guard against iOS 6 POST caching

Would it be possible to instead add something to the query string to prevent caching?

For our usecase we would also be fine just having a way to opt out of setting the header, since the overhead of an additional OPTIONS request seems rather large considering it's to circumvent buggy behaviour of a single client.

@jcoglan
Copy link
Collaborator

jcoglan commented Aug 2, 2017

I don't have any devices available to me to check this now, but from a little googling it seems like the only fix known at the time was to use cache control headers, rather than query strings. If you do find out that query strings are sufficient to prevent this error, I'll happily remove the header.

However, it's worth noting in relation to #466, for us to use the regular long-polling transport for cross-origin requests to other Bayeux servers, we'd need to set Content-Type: application/json, which would also trigger a pre-flight request.

Does the access-control-max-age header not prevent your client from making repeated OPTIONS requests?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants