Handle HTTP OPTIONS

The HTTP OPTIONS (RFC 7231, section 4.3.7: OPTIONS) method is used to describe the communication options for the target resource. The client can specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server.

It is a request from the client to know what HTTP methods the server will allow, like GET, POST, etc.

The request might look like this when asking about the options for a particular resource:

OPTIONS /index.html HTTP/1.1

or like this when asking about the server in general:

OPTIONS * HTTP/1.1

The possible response from the server would be like this

HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Fri, 01 May 2020 00:39:41 GMT
Content-Type: application/octet-stream
Content-Length: 0
Connection: keep-alive
Content-Length: 0
Content-Type: text/plain
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: origin,authorization, x-requested-with, content-type, accept
Access-Control-Allow-Methods: GET, POST

Why is the server receiving an HTTP OPTIONS request?
a. Most of the REST API applications or systems are needing it.
b. Browsers will send it to servers as "preflighted" requests to see if the server understands CORS

This is one of the best methods to control external access and safeguard your API endpoints. For example, let's assume, we defined API endpoints where the authorization header is needed. If we don't have that OPTIONS request, the browser will just send it to the server, where the server needs to do the validation, and then proceed accordingly.

So, what if the browser knows beforehand that the request can not be sent due to the server not authorized to accept any request without authorization header, so the browser can avoid un-necessary sending out the network.

Normally, it is best to practice to implement this OPTION header handling at API gateway level or front-webservers like Nginx. The API gateway should able to configure your end-points related OPTION headers so that the application behind your API gateway can avoid the processing and focus only business logic without too much worry about HTTP Header administration.

For example, if you need to configure all your OPTION request returned like this from Nginx

location / {
               if ($request_method = OPTIONS ) {
                        add_header Content-Length 0;
                        add_header Content-Type text/plain;
                        add_header Access-Control-Allow-Origin *;
                        add_header Access-Control-Allow-Headers 'origin,authorization, x-requested-with, content-type, accept';
                        add_header Access-Control-Allow-Methods 'GET, POST';
                        return 200;
                }
                client_max_body_size 200M;
                proxy_pass  http://xx.xx.xx.xx:8080;  // This is your micro service end point

        }

Further reading: https://stackoverflow.com/questions/15381105/cors-what-is-the-motivation-behind-introducing-preflight-requests
: https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods