Как отвечать на запрос HTTP OPTIONS?

Метод HTTP OPTIONS предположительно используется для определения того, какие другие методы поддерживает сервер на данном ресурсе. Учитывая это, у меня есть два вопроса:

Как выглядит этот ответ? Я видел примеры с списками CSV в заголовках Public, Allow и даже Access-Control-Allow-Methods. Все ли они нужны? Какая разница? RFC 2616 здесь не очень помогает.
Было бы уместно использовать это, чтобы перечислять действия, которые поддерживает ресурс в среде, отличной от REST-API? Например, если мой ConversionController поддерживает действие convert, будет ли такой ответ как это:

Запрос:

OPTIONS /conversion HTTP/1.1

Ответ:

HTTP/1.1 200 OK
...
Allow: CONVERT
...

Ответ 1

RFC 2616 определяет "Разрешить" (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7). "Public" больше не используется. "Access-Control-Allow-Methods" определено в спецификации CORS (см. Http://www.w3.org/TR/cors/).

Ответ 2

В ответ на заголовок: "Как ответить на запрос HTTP OPTIONS?" Чтобы ответить на этот вопрос, я хотел бы знать, почему вы хотите ответить на запрос ОПЦИИ? Кто/что посылает вам запрос ОПЦИИ и почему? Многие общедоступные серверы отвечают в той или иной форме "ошибкой" или "недопустимым" (500, 501, 405). Таким образом, если вы не находитесь в конкретной ситуации, когда ваши клиенты будут разумно отправлять запросы OPTIONS и ожидают получения полезной/значимой информации (например, WebDAV, CORS), вы, вероятно, захотите ответить: "не делайте этого".

С точки зрения вашего вопроса о запросе "OPTIONS/Conversion HTTP/1.1": если вы не знаете, что существует какой-то клиент вашего сервера, клиент, который отправит запрос OPTIONS в "/Conversion" и ожидает ответа с "Allow: CONVERT". "Ответ - нет: не имеет смысла отвечать так. Я думаю, что большинство реализаций, которые поддерживают OPTIONS и отвечают "Разрешить", отвечают стандартными методами HTTP.

Здесь отличная статья на эту тему.

Описание: OPTIONS сразу проблематичен, потому что он не поддерживает кэширование. Альтернативы: общесерверные метаданные: попробуйте известные URI. Для конкретного ресурса: попробуйте использовать заголовок Link в его ответах или ссылку в формате представления для этого ресурса.

И наконец, если вам нужно описание сервиса, взгляните на WADL или RSDL.

РЕДАКТИРОВАТЬ:

dotnetguy делает хорошую точку в комментариях ниже: OPTIONS, несомненно, ценный в определенных контекстах (например, CORS); Я, конечно, не хотел предложить иначе.

Ответ 3

Что такое запрос HTTP OPTIONS?

Это запрос от клиента, чтобы узнать, какие методы HTTP сервер разрешит, такие как GET, POST и т.д.

Запрос

Запрос может выглядеть следующим образом при запросе параметров для определенного ресурса:

OPTIONS /index.html HTTP/1.1

или так, когда спрашиваете о сервере в целом:

OPTIONS * HTTP/1.1

отклик

Ответ будет содержать заголовок Allow с разрешенными методами:

Allow: OPTIONS, GET, HEAD, POST

Почему сервер получает запрос HTTP OPTIONS?

Некоторым API REST это нужно (но если вы определяете API, вы это знаете)
Браузеры отправляют его на сервер в виде "предварительно выданных" запросов, чтобы узнать, понимает ли сервер CORS
Злоумышленники отправляют его, чтобы получить больше информации об API

Как ответить на запрос HTTP OPTIONS?

Вы можете ответить Allowed заголовком и даже задокументировать свой API в теле.
Вы можете ответить дополнительными заголовками, определенными в CORS Access-Control-Request-*.
Вы можете ответить 405 Method Not Allowed или 501 Not Implemented.

Как мне прекратить получать запросы HTTP OPTIONS?

Если это происходит из браузера, обновите ваш API, чтобы он не делал ничего "опасного" (например, PUT или DELETE, или POST с application/json). Выполняйте только простые запросы.