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

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
...
2 60
http

2 ответа:

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/).

14

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

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

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

резюме: параметры сразу же проблематично, потому что он не поддерживает кэширование. Альтернативы: метаданные на уровне сервера: try известный Ури. Специфичный для ресурса: попробуйте использовать ссылка заголовок на его ответы, или ссылку в формате представления для данного ресурса.

наконец, если то, что вам нужно, - это описание службы, посмотрите WADL или RSDL.

EDIT:

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

5