Search code examples
curlcorsdjango-rest-frameworkdjango-cors-headers

CORS fails on request with OPTIONS (Response with status: 0)


Update: Rewrite of the question since I've got some new information. History is visible in the edits.

Issue introduction
I have a django-rest-framework application running on a subdomain api.nrzonline.nl. The frontend ng2 + webpack application is running on the domain itself nrzonline.nl. When sending a request with ng2-restangular to the API, I receive the following errors in my console:

 zone.js OPTIONS http://api.nrzonline.com/project/ net::ERR_EMPTY_RESPONSE
 EXCEPTION: Response with status: 0  for URL: null

The current issue
After quite some testing with curls, I found that all the requests fail when the preflight request with OPTIONS is send.

Request with -X GET works properly:

curl 'api.nrzonline.nl/skill/' -X GET
[{"id":1,"category":{"id":1,"title":"skill-a",...}]

(preflight) request with -X OPTIONS fails with no response

curl 'api.nrzonline.nl/skill/' -X OPTIONS
curl: (52) Empty reply from server

Performing this -x OPTIONS request on the API on the Django development server locally works without any issue's.

server settings

  • CORS_ORIGIN_ALLOW_ALL = True
  • CORS_ALLOW_METHODS is on default, which allows OPTIONS
  • CORS_ALLOW_HEADERS is on default

Middleware:

MIDDLEWARE = [
    ...
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    ...
]

What I have tried

  • I have read that it is possible that the server requires HTTPS request, but currently there is no SSL certificate active. (source) Though, I did try to curl with --insecure (source)
  • Sending the request as text/plain instead of application/json with -H "Content-Type: text/plain" (source (comment on answer))

The question
What am I missing / doing wrong, so that the preflight with -X OPTIONS is failing. Any tips, explanations or references to a possible solution are welcome.


Solution

  • Answer credits go to my brother, hoster of my website

    The issue was DirectAdmin related. By default DirectAdmin only allows GET, POST and HEAD.

    These settings are found in include /etc/nginx/webapps.conf; as:

    if ($request_method !~ ^(GET|HEAD|POST)$ ) {
        return 444;
    }
    

    Adding OPTIONS should fix the problem. Remove or comment out the code block to allow any request method.

    However, modifying /etc/nginx/webapps.conf might cause DirectAdmin to override this file during a new HTTPD update. The file <path_to_directadmin>/custombuild/costum/nginx/conf is used to generate a conf file. Making your modifications here should prevent loss of your adjustments.