Как обрабатывать запрос OPTIONS * в nginx?

В моей среде я использую 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.02.2013:03:55:47 +0000] "ОПЦИИ * HTTP/1.0" 400 172 "-" "-" "-"

но он работает с опцией «OPTIONS/HTTP/1.0» без запросов звездочки:

127.0.0.1 - - [18.02.2013:04:03:56 +0000] "ОПЦИИ / HTTP/1.0" 200 0 "-" "-" "-"

Как настроить nginx, чтобы он отвечал HTTP-возвратом 200, а не HTTP-возвратом 400?


http nginx bad-request http-options-method
person Cody    schedule 18.02.2013    source источник
comment
Я не думаю, что это решение, но пробовали ли вы использовать HTTP/1.1 с заголовком Host:? аля... OPTIONS * HTTP/1.1\r\nHost: devserver\r\n\r\n. Согласно RFC2616, раздел 9: The set of common methods for HTTP/1.1 is defined below...   -  person Basic    schedule 18.02.2013
comment
Привет, спасибо за вашу идею, но у меня все еще есть 400 Bad Request, даже нет возможности ввести заголовок. Я попытался отправить запрос параметров с заголовком хоста через telnet: ` telnet 10.1.128.97 5274 Попытка 10.1.128.97... Подключен к 10.1. 128,97. Экранирующий символ '^]'. ВАРИАНТЫ * HTTP/1.1 ‹html› ‹head›‹title›400 Bad Request‹/title›‹/head› ‹body bgcolor=white› ‹center›‹h1›400 Bad Request‹/h1›‹/center› ‹hr ›‹center›nginx/1.2.6‹/center› ‹/body› ‹/html› Соединение закрыто внешним хостом. `   -  person Cody    schedule 22.02.2013

Ответы (2)


arrow_upward
16
arrow_downward

Я знаю, что это излишество, но одно из решений — поставить HAProxy перед ним, чтобы просто захватить этот запрос OPTIONS, а затем создать свой собственный ответ в HAProxy:

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

arrow_upward
0
arrow_downward

Единственный способ изменить поведение в этом случае, который я нашел, - это ответить на 400 в целом:

error_page 400 =200 /empty_reply.html;

Вы можете просто отправлять пустые ответы на все, с чем не можете справиться. Для тех, кто хочет попытаться решить это по-другому, вы можете смоделировать эти запросы с помощью:

 curl -X OPTIONS $yourserverip --request-target "*" --http1.1
person David Sommer    schedule 24.01.2019