How to handle "OPTIONS *" request in nginx?

Question

In my environment, I use perlbal to redirect request to nginx. If verify_backend is on. perbal will send a "OPTIONS *" request to nginx, but the nginx response it as a bad request.

According to RFC2616:

If the Request-URI is an asterisk (""), the OPTIONS request is intended to apply to the ?server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

I think perlbal is trying to send this kind of request, but nginx can't handle this by default.

When I try to send a request "OPTIONS * HTTP/1.0", I always get "HTTP 400 bad request":

127.0.0.1 - - [18/Feb/2013:03:55:47 +0000] "OPTIONS * HTTP/1.0" 400 172 "-" "-" "-"

but it works on "OPTIONS / HTTP/1.0" option without asterisk requests :

127.0.0.1 - - [18/Feb/2013:04:03:56 +0000] "OPTIONS / HTTP/1.0" 200 0 "-" "-" "-"

How can I configure nginx to let it respond with http return 200 rather than HTTP return 400 ?

I don't think this is a solution but have you tried using HTTP/1.1 with a `Host:` header? ala... `OPTIONS * HTTP/1.1\r\nHost: devserver\r\n\r\n`. As per [RFC2616 Section 9](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html): `The set of common methods for HTTP/1.1 is defined below...` — Basic, Feb 18 '13 at 12:55
Hi, thanks for your idea, but I still got `400 Bad Request`, even has not chance to input header I tried to issue an Options request with host header via telnet: ` telnet 10.1.128.97 5274 Trying 10.1.128.97... Connected to 10.1.128.97. Escape character is '^]'. OPTIONS * HTTP/1.1 400 Bad Request
400 Bad Request

nginx/1.2.6 Connection closed by foreign host. ` — Cody, Feb 22 '13 at 06:41

score 17 · Answer 1 · answered Feb 26 '13 at 20:19

I know it's an overkill but one solution is to put HAProxy in front of it to just capture that OPTIONS request and then build your own response in HAProxy:

location * {
    if ($request_method = OPTIONS ) {
        add_header Content-Length 0;
        add_header Content-Type text/plain;
        return 200;
    }
}

score 0 · Answer 2 · answered Jan 24 '19 at 15:08

The only way I found to modify the behaviour in this case was to respond to 400 in general:

error_page 400 =200 /empty_reply.html;

You could just send empty responses to everything you cannot handle. For whoever wants to try to solve this another way, you can simulate this requests with:

 curl -X OPTIONS $yourserverip --request-target "*" --http1.1

How to handle "OPTIONS *" request in nginx?

400 Bad Request

2 Answers2