What is the reason for an OPTIONS request not succeeding when the response to the subsequent request is a 204 status code?

Question

What is the reason for an OPTIONS request not succeeding when the response to the subsequent request is a 204 status code?

While developing a Backbone.js based application, I encountered an unusual issue.

When the app requests a collection resource at a specific point, I receive an error in Chrome and Safari that reads:

XMLHttpRequest cannot load http://api.mydomain.net/v1/foos/00000d/bars/000014/boots Origin http://localhost:3501 is not allowed by Access-Control-Allow-Origin.

Initially, I assumed it was a CORS problem and blamed my API. However, when I tried to request the same resource using CURL:

curl -i -H'Accept: application/json' -H'X-Auth-Token: pAWp5hrCmXA83GgFzgHC' -XOPTIONS 'http://api.mydomain.net/v1/foos/00000d/bars/000014/boots'
HTTP/1.1 200 OK
Status: 200
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,X-Auth-Token
Content-Length: 0

Seems fine so far, but when I tried the GET request:

curl -i -H'Accept: application/json' -H'X-Auth-Token: pAWp5hrCmXA83GgFzgHC' -XGET 'http://api.mydomain.net/v1/foos/00000d/bars/000014/boots'
HTTP/1.1 204 No Content
Status: 204
Cache-Control: no-cache
Content-Length: 0
Content-Type: text/plain

It only works if the boots collection contains at least one object. The CORS headers from my server seem correct. So why do the browsers still flag it as a cross-origin resource problem?

Could it be because of the content type text/plain in my 204 responses?

Preflight (OPTIONS) request in dev tools: https://i.sstatic.net/Viifh.png

Request headers of aborted response: https://i.sstatic.net/XdOgs.png

javascript ajax backbone.js xmlhttprequest cors

Answer 1

Answer №1

Make sure to include the Access-Control-Allow-Origin in the response headers of the second request as well. This issue is not on the client-side but rather on the backend.

This behavior aligns with the specifications outlined in the CORS specification, particularly detailed in the explanation found in section 7.1.5 "Cross-Origin Request with Preflight":

An initial preflight request occurs (details omitted)
The cross-origin request status is set to preflight complete.
This marks the actual request. While making this request, specific rules need to be observed.
- ~~If the response has an HTTP status code of 301, 302, 303, or 307~~ Not relevant
- ~~If the end user cancels the request~~ Not relevant
- ~~If there is a network error~~ Not relevant
- Otherwise,
  Perform a resource sharing check. If it fails, follow through with cache and network error steps.

Your request is currently failing at the first step of the resource sharing check:

If the response contains no or more than one Access-Control-Allow-Origin header values, mark it as a failure and stop the algorithm.

To assist you better understand the issue, here's a simple NodeJS example that showcases your problem.
Your current backend logic looks like:

require('http').createServer(function(request, response) {
    if (request.method == 'OPTIONS') { // Handling preflight
        response.writeHead(200, {
           "Access-Control-Allow-Origin": "*",
           "Access-Control-Allow-Headers": "X-Foo"
        });
    } else {                           // Handling actual requests
        response.writeHead(204, {
          //"Access-Control-Allow-Origin": "*"
        });
    }
    response.end();
}).listen(12345);

Observe the request and notice the failure experienced:

var x = new XMLHttpRequest;
x.open('GET', 'http://localhost:12345');
x.setRequestHeader('X-Foo','header to trigger preflight');
x.send();

If you revisit the provided code and enable the Access-Control-Allow-Origin header in the response, and test again - your request will now succeed.

Answer 2

Make sure to include the Access-Control-Allow-Origin in the response headers of the second request as well. This issue is not on the client-side but rather on the backend.

This behavior aligns with the specifications outlined in the CORS specification, particularly detailed in the explanation found in section 7.1.5 "Cross-Origin Request with Preflight":

An initial preflight request occurs (details omitted)
The cross-origin request status is set to preflight complete.
This marks the actual request. While making this request, specific rules need to be observed.
- ~~If the response has an HTTP status code of 301, 302, 303, or 307~~ Not relevant
- ~~If the end user cancels the request~~ Not relevant
- ~~If there is a network error~~ Not relevant
- Otherwise,
  Perform a resource sharing check. If it fails, follow through with cache and network error steps.

Your request is currently failing at the first step of the resource sharing check:

If the response contains no or more than one Access-Control-Allow-Origin header values, mark it as a failure and stop the algorithm.

To assist you better understand the issue, here's a simple NodeJS example that showcases your problem.
Your current backend logic looks like:

require('http').createServer(function(request, response) {
    if (request.method == 'OPTIONS') { // Handling preflight
        response.writeHead(200, {
           "Access-Control-Allow-Origin": "*",
           "Access-Control-Allow-Headers": "X-Foo"
        });
    } else {                           // Handling actual requests
        response.writeHead(204, {
          //"Access-Control-Allow-Origin": "*"
        });
    }
    response.end();
}).listen(12345);

Observe the request and notice the failure experienced:

var x = new XMLHttpRequest;
x.open('GET', 'http://localhost:12345');
x.setRequestHeader('X-Foo','header to trigger preflight');
x.send();

If you revisit the provided code and enable the Access-Control-Allow-Origin header in the response, and test again - your request will now succeed.

What is the reason for an OPTIONS request not succeeding when the response to the subsequent request is a 204 status code?

Answer №1

Similar questions

Sending information to a node using XMLHttpRequest

Invoke a fresh constructor within a $get method in Angular's provider

Having difficulty displaying GLTF object using three.js

What steps can be taken to verify that the submitted data is a legitimate numerical pair?

Prevent additional functions from running when clicking in Angular 5

Is it impossible to show more than 4 days of the week using Javascript?

Utilizing Three.js to create a vertex shader that dynamically adjusts pixel coloring according to its position on the screen

Adjust the JQuery UI Slider value in real-time as you slide the slider

Using Express.js to Serve Static Content on a Dynamic Route

Is it possible for an AJAX call to fail, despite receiving a valid 200OK response?

Unable to get the Express.js Router functioning correctly on my server, even in a basic scenario

Execute AJAX function following the completion of table loading from PHP in Ajax

Unusual layout in Next.js editor (VS Code)

Is it possible to recreate the initial JavaScript source file using a minified version alongside its associated source-map file?

Issue with JQuery Promise: fail() being invoked before promise resolution

hide the container while keeping the content visible

The link that has been clicked on should remain in an active state

Error encountered with jQuery UI datepicker beforeShowDay function

A Comprehensive Guide to Transmitting Variable Value Image Files using Ajax and PHP

Utilize Material UI's TouchRipple Component to enhance the interactivity of custom elements and components