如何在nginx中处理“OPTIONS *”请求?

时间:2013-02-18 04:09:13

标签: http nginx bad-request http-options-method

在我的环境中,我使用perlbal将请求重定向到nginx。如果 verify_backend 已启用。 perbal会向nginx发送一个“OPTIONS *”请求,但是nginx会将其作为一个错误的请求进行响应。

根据RFC2616

  

如果Request-URI是星号(“”),则OPTIONS请求通常应用于?服务器而不是特定资源。由于服务器的通信选项通常取决于资源,因此“”请求仅用作“ping”或“no-op”类型的方法;除了允许客户端测试服务器的功能之外,它什么都不做。例如,这可用于测试代理是否符合HTTP / 1.1(或缺少)。

我认为perlbal正在尝试发送此类请求,但nginx默认无法处理此问题。

当我尝试发送请求“OPTIONS * HTTP / 1.0”时,我总是收到“HTTP 400错误请求”:

  

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

但它适用于没有星号请求的“OPTIONS / HTTP / 1.0”选项:

  

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

如何配置nginx让它以http返回200响应而不是HTTP返回400?

2 个答案:

答案 0 :(得分:10)

我知道它有点矫枉过正,但有一种解决办法是将HAProxy放在它前面,以便捕获OPTIONS请求,然后在HAProxy中构建自己的响应:

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

答案 1 :(得分:0)

在这种情况下,我发现修改行为的唯一方法是一般响应400:

error_page 400 =200 /empty_reply.html;

您可以将无法处理的所有内容发送空响应。 对于想尝试以其他方式解决此问题的人,可以使用以下命令模拟此请求:

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