Як відповісти на запит HTTP OPTIONS?

84

Метод 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
...
http 
— FtDRbwLXw6
джерело
2
Allow: CONVERT??
— Pacerier

Відповіді:

20

RFC 2616 визначає "Дозволити" ( http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 ). "Public" більше не використовується. "Методи контролю доступу-дозволу" визначено в специфікації CORS (див. Http://www.w3.org/TR/cors/ ).

— Джуліан Решке
джерело
Дякую за роз'яснення. У разі CORS, повинен як Allowі Access-Control-Allow-Methodsбути відправлені, або тільки останній?
— FtDRbwLXw6
Я завжди повертав би "Дозволити", таким чином не спеціальний CORS.
— Джуліан Решке
6
А як щодо вмісту? Чи може бути доступний вміст тіла?
— CMCDragonkai
2
@CMCDragonkai Так, OPTIONSможе мати вміст. З RFC 2616: "Якщо запит OPTIONS включає тіло сутності (на що вказує наявність Content-Length або Transfer-Encoding), тоді тип носія ПОВИНЕН вказуватися полем Content-Type. Хоча ця специфікація не визначає будь-яке використання такого тіла, майбутні розширення HTTP можуть використовувати тіло OPTIONS для більш детальних запитів на сервері. Сервер, який не підтримує таке розширення, МОЖЕ відхилити тіло запиту. "
— єпископ
Я вважаю, що і те, Allowі інше Access-Control-Allow-Methodsпотрібно, якщо ви хочете використовувати CORS. Перший визначає, які методи підтримуються загалом, а другий визначає, які методи дозволяються для запитів перехресного походження. Наприклад, можна дозволити GET, POST, PUTі DELETEдля свого власного походження , але тільки дозволяє GETі POSTдля перехресного походження.
— Мікко Ранталайнен
8

У відповідь на заголовок: "Як відповісти на запит HTTP OPTIONS?" Щоб відповісти на це, я хотів би знати, чому ви хочете відповісти на запит OPTIONS? Хто / що надсилає вам запит OPTIONS і чому? Багато загальнодоступних серверів відповідають якоюсь формою "помилка" або "не дозволяється" (500, 501, 405). Отже, якщо ви не перебуваєте у конкретній ситуації, коли ваші клієнти розумно надсилатимуть запити OPTIONS і очікуватимуть корисну / значущу інформацію назад (наприклад, WebDAV, CORS), ви, мабуть, хочете відповісти: "не робіть цього".

Що стосується вашого запитання щодо запиту "OPTIONS / перетворення HTTP / 1.1": якщо ви не знаєте, що на вашому сервері є якийсь клієнт, клієнт, який надішле запит OPTIONS на "/ conversion" і очікує відповіді з "Allow: CONVERT" , "відповідь негативна: не було б сенсу так реагувати. Я думаю, що більшість реалізацій, які підтримують OPTIONS і відповідають "Дозволити", відповідають стандартними методами HTTP.

Ось чудова стаття на цю тему .

Короткий зміст: ОПЦІЇ негайно є проблематичним, оскільки він не підтримує кешування. Альтернативи: метадані на всьому сервері: спробуйте відомі URI . Спеціально для ресурсу: спробуйте використовувати заголовок Link у відповідях або посилання у форматі представлення для цього ресурсу.

І, нарешті, якщо то , що ви після того, як це загальне поняття, подивіться на WADL або RSDL .

РЕДАГУВАТИ:

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

— Соколиний Паркер
джерело
4
Стаття хороша, авторитетна і авторитетна, але див. Розділ "Чому HTTPbis залишає OPTIONS, а потім" та коментарі. За допомогою CORS система REST повинна мати можливість реагувати на ВАРІАНТИ, особливо якщо API будуть використовуватися з веб-додатку на основі JavaScript. Загальноприйняте для JS-фреймворків, що запускає запит на опції "перед вильотом" перед фактичним викликом HTTP.
— Судханшу Мішра,
Я бачив запити OPTIONS, коли підключаю свій (самостійно написаний) сервер http від macOS Finder ( за допомогою Webdav ).
— Джо
8

Що таке запит 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 в тілі.
  • Ви можете відповісти додатковими Access-Control-Request-*заголовками, визначеними CORS .
  • Ви можете відповісти за допомогою 405 Method Not Allowedабо 501 Not Implemented.

Як зупинити отримання запитів HTTP OPTIONS?

  • Якщо він надходить з браузера, оновіть свій API, щоб він не робив нічого «небезпечного» (наприклад, PUTабо DELETE, або POSTз application/json). Виконуйте лише прості запити .

Дивитися також

— Сурач
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.