am I simulating CORS with cURL correctly and do I need to implement OPTIONS request

Question

I'm not very good with web server development as well as understanding how exactly http headers work. I've done quite a bit of reading but still a little confused. At the moment I'm trying to simulate CORS request with cURL. (Need it for personal development). To do so I found a simple REST server written in C (C is the language I'm most familiar with). Code is actually located here . I found this post which explains how to simulate CORS.

Here is the problem:

If I run

curl -H "Origin: http://localhost:3000" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X OPTIONS --verbose \
  http://localhost:8537/test

The request fails with the following response

*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 8537 failed: Connection refused
*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 8537 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8537 (#0)
> OPTIONS /test HTTP/1.1
> Host: localhost:8537
> User-Agent: curl/7.61.1
> Accept: */*
> Origin: http://localhost:3000
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Request-With
>
< HTTP/1.1 404 Not Found
< Connection: Keep-Alive
< Content-Length: 32
< Access-Control-Allow-Origin: *
< Date: Sat, 12 Jan 2019 02:21:59 GMT
<
* Connection #0 to host localhost left intact
Page not found, do what you want

However if I run the same request with -X POST instead of -X OPTIONS , ie

curl -H "Origin: http://localhost:3000" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X POST --verbose \
  http://localhost:8537/test

The request succeeds with the following response:

*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 8537 failed: Connection refused
*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 8537 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8537 (#0)
> POST /test HTTP/1.1
> Host: localhost:8537
> User-Agent: curl/7.61.1
> Accept: */*
> Origin: http://localhost:3000
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Request-With
>
< HTTP/1.1 200 OK
< Connection: Keep-Alive
< Content-Length: 19
< Access-Control-Allow-Origin: *
< Date: Sat, 12 Jan 2019 02:25:28 GMT
<
Hello World!
* Connection #0 to host localhost left intact
(null)

I get the same results if execute

curl -H "Origin: http://localhost:3000" -X OPTIONS --verbose http://localhost:8537/test

and

curl -H "Origin: http://localhost:3000" -X POST --verbose http://localhost:8537/test

ie the request fails with OPTIONS request and succeeds with POST request.

The code does allow for CORS (at least that what I think). Here is the line of code that does it

u_map_put(instance.default_headers, "Access-Control-Allow-Origin", "*");

So here are the questions:

1. To simulate CORS, do I need to use OPTIONS request or a POST request?
2. If I were to write a server similar to the one in the example, do I need to implement OPTIONS response or I can get away with POST/GET?

Answer 1

In CORS, OPTIONS is being used for preflight requests . You're not necessarily need to handle OPTIONS requests, if you're issuing only "simple" CORS requests.

You can read the definition of Simple CORS Request here .