Why Does the Preflight Options Request of an Authenticated Cors Request Work in Chrome But Not Firefox

Why does the preflight OPTIONS request of an authenticated CORS request work in Chrome but not Firefox?

Why does it work in Chrome and not Firefox?

The W3 spec for CORS preflight requests clearly states that user credentials should be excluded. There is a bug in Chrome and WebKit where OPTIONS requests returning a status of 401 still send the subsequent request.

Firefox has a related bug filed that ends with a link to the W3 public webapps mailing list asking for the CORS spec to be changed to allow authentication headers to be sent on the OPTIONS request at the benefit of IIS users. Basically, they are waiting for those servers to be obsoleted.

How can I get the OPTIONS request to send and respond consistently?

Simply have the server (API in this example) respond to OPTIONS requests without requiring authentication.

Kinvey did a good job expanding on this while also linking to an issue of the Twitter API outlining the catch-22 problem of this exact scenario interestingly a couple weeks before any of the browser issues were filed.

Why is an OPTIONS request sent and can I disable it?

edit 2018-09-13: added some precisions about this pre-flight request and how to avoid it at the end of this reponse.

OPTIONS requests are what we call pre-flight requests in Cross-origin resource sharing (CORS).

They are necessary when you're making requests across different origins in specific situations.

This pre-flight request is made by some browsers as a safety measure to ensure that the request being done is trusted by the server.
Meaning the server understands that the method, origin and headers being sent on the request are safe to act upon.

Your server should not ignore but handle these requests whenever you're attempting to do cross origin requests.

A good resource can be found here http://enable-cors.org/

A way to handle these to get comfortable is to ensure that for any path with OPTIONS method the server sends a response with this header

Access-Control-Allow-Origin: *

This will tell the browser that the server is willing to answer requests from any origin.

For more information on how to add CORS support to your server see the following flowchart

http://www.html5rocks.com/static/images/cors_server_flowchart.png

CORS Flowchart


edit 2018-09-13

CORS OPTIONS request is triggered only in somes cases, as explained in MDN docs:

Some requests don’t trigger a CORS preflight. Those are called “simple requests” in this article, though the Fetch spec (which defines CORS) doesn’t use that term. A request that doesn’t trigger a CORS preflight—a so-called “simple request”—is one that meets all the following conditions:

The only allowed methods are:

  • GET
  • HEAD
  • POST

Apart from the headers set automatically by the user agent (for example, Connection, User-Agent, or any of the other headers with names defined in the Fetch spec as a “forbidden header name”), the only headers which are allowed to be manually set are those which the Fetch spec defines as being a “CORS-safelisted request-header”, which are:

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (but note the additional requirements below)
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width

The only allowed values for the Content-Type header are:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

No event listeners are registered on any XMLHttpRequestUpload object used in the request; these are accessed using the XMLHttpRequest.upload property.

No ReadableStream object is used in the request.

Preflight CORS requests with Basic Authentication in Angular 2

The preflight request is made by the browser only to check if the CORS headers are set. If it doesn't get the required headers, there is nothing you can do. It will just not make the actual POST request.

What you actually can do, is to make the request from a server you control. Provide an API for your client to call your server and then make the call to the misconfigured server and forward the response to your browser client.

Response to preflight request doesn't pass access control check

You are running into CORS issues.

There are several ways to fix or workaround this.

  1. Turn off CORS. For example: How to turn off CORS in Chrome
  2. Use a plugin for your browser
  3. Use a proxy, such as nginx. Example of how to set up
  4. Go through the necessary setup for your server. This is more a factor of the web server you have loaded on your EC2 instance (presuming this is what you mean by "Amazon web service"). For your specific server, you can refer to the enable CORS website.

More verbosely, you are trying to access api.serverurl.com from localhost. This is the exact definition of a cross-domain request.

By either turning it off just to get your work done (OK, but poor security for you if you visit other sites and just kicks the can down the road) or you can use a proxy which makes your browser think all requests come from the local host when really you have a local server that then calls the remote server.

So api.serverurl.com might become localhost:8000/api, and your local nginx or other proxy will send to the correct destination.


Now by popular demand, 100% more CORS information—the same great taste!


Bypassing CORS is exactly what is shown for those simply learning the front end.
HTTP Example with Promises

FireFox Not Sending CORS Request (using jQuery)

Your answer could be in this response: Why does the preflight OPTIONS request of an authenticated CORS request work in Chrome but not Firefox?

It appears Firefox will stop sending requests if the pre-flight request response is a 401 whereas Webkit browsers will go ahead with the actual request (GET, POST, etc.)

EDIT: but then again, you are not even seeing the OPTIONS request being sent... still, the above mentioned post might be useful.



Related Topics



Leave a reply



Submit