Does AJAX in Chrome send OPTIONS instead of GET / POST / PUT / DELETE?

Question

I am working on an internal web application at work. In IE10, requests work fine, but in Chrome, all AJAX requests (of which there are many) are sent using OPTIONS instead of what I gave to this method. Technically, my requests are cross domain. The site is hosted on localhost: 6120, and the service with which I am making AJAX requests is located at 57124. This closed jquery error identifies the problem, but is not a real fix.

What can I do to use the correct http method in ajax requests?

Edit:

This is in loading the document on each page:

jQuery.support.cors = true; 

And each AJAX is built similarly:

 var url = 'http://localhost:57124/My/Rest/Call'; $.ajax({ url: url, dataType: "json", data: json, async: true, cache: false, timeout: 30000, headers: { "x-li-format": "json", "X-UserName": userName }, success: function (data) { // my success stuff }, error: function (request, status, error) { // my error stuff }, type: "POST" }); 

Answer 1

Chrome is preceded by a search request for CORS headers. If the request is acceptable, it will send a real request. If you are running this cross-domain, you just have to deal with it or find a way to make the request non-cross-domain. This is why the jQuery error was closed as it was not fixed. This is by design.

Unlike simple requests (see above), the “prefilled” requests are first requested; send an HTTP request using the OPTIONS method to a resource in another domain to determine if the actual request is safe to send. Cross-site request requests are preceded in this way, as they may have implications for user data. In particular, a request is preceded if:

• It uses methods other than GET, HEAD, or POST. Also, if POST is used to send request data using Content-Type, other than application / x-www-form-urlencoded, multipart / form-data, or text / plain, for example if the POST request sends an XML payload to the server using application / xml or text / xml, then the request is preceded.
• It sets custom headers in the request (for example, the request uses a header, for example X-PINGOTHER)

Answer 2

Based on the fact that the request is not sent to port 80/443 by default, this Ajax call is automatically considered a cross-source code (CORS) resource request , which means that the request automatically issues an OPTIONS request that checks the CORS headers on the server / servlet side .

This happens even if you installed

 crossOrigin: false; 

or even if you omit it.

The reason is that localhost != localhost:57124 . Try sending it only to localhost without a port - it will not work, because the requested target will not be achievable, however, note that if the domain names are equal , the request is sent without an OPTIONS request before POST.

Answer 3

I agree with Kevin B, the error report says it all. It looks like you're trying to make cross-domain ajax calls. If you are not familiar with the same origin policy, you can start here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript .

If this is not intended for ajax cross-tasking, try making your destination URL and see if the problem goes away. If you really look desperately at JSONP, but be careful, the chaos is hiding. In fact, we cannot do more to help you.

Answer 4

If it is possible to pass parameters through a regular GET / POST with a different name and enable its code on the server side.

I had a similar problem with my own proxy to get around CORS, and I got the same POST-> OPTION error in Chrome. It was the Authorization header in my case ( "x-li-format" and "X-UserName" here in your case.) I ended up passing it in a dummy format (like AuthorizatinJack in GET), and I changed the code for my proxy- server, turn this into a header when making a call to your destination. Here it is in PHP:

 if (isset($_GET['AuthorizationJack'])) { $request_headers[] = "Authorization: Basic ".$_GET['AuthorizationJack']; } 

Answer 5

In my case, I call the API hosted by AWS (API Gateway). The error occurred when I tried to call the API from a domain other than the native API domain. Since I own the API, I have enabled CORS for the test environment, as described in Amazon Documentation .

In production, this error will not occur, since the request and api will be in the same domain.

Hope this helps!

Answer 6

As @Dark Falcon replied , I just dealt with it.

In my case, I use the node.js server and create a session if it does not exist. Because the OPTIONS method does not contain session information, it created a new session for each POST request.

So, in my session-if-does not exist application, I just added a check to check if there is an OPTIONS method, and if so, just skip the session creation part:

  app.use(function(req, res, next) { if (req.method !== "OPTIONS") { if (req.session && req.session.id) { // Session exists next(); }else{ // Create session next(); } } else { // If request method is OPTIONS, just skip this part and move to the next method. next(); } } 

Answer 7

“pre-programmed” requests first send an HTTP request using the OPTIONS method to a resource in another domain to determine whether it is safe to send the actual request. Cross site requests

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Answer 8

Consider using axios

 axios.get( url, { headers: {"Content-Type": "application/json"} } ).then( res => { if(res.data.error) { } else { doAnything( res.data ) } }).catch(function (error) { doAnythingError(error) }); 

I had this problem using fetch , and the axioms worked fine.

Answer 9

I ran into a very similar problem. I spent almost half a day to understand why everything works correctly in Firefox and does not work in Chrome. In my case, this was due to duplicate (or possibly typos) fields in the header of my request.

Answer 10

  $.ajax({ url: '###', contentType: 'text/plain; charset=utf-8', async: false, xhrFields: { withCredentials: true, crossDomain: true, Authorization: "Bearer ...." }, method: 'POST', data: JSON.stringify( request ), success: function (data) { console.log(data); } }); 

contentType: 'text / plain; charset = utf-8 ', or just contentType:' text / plain ', works for me! Respectfully!!