Ответ
OPTIONS — это HTTP-метод, используемый для описания возможностей взаимодействия с целевым ресурсом. Клиент запрашивает у сервера информацию о поддерживаемых методах, заголовках или других параметрах.
Основное применение — CORS Preflight:
Перед отправкой «непростого» кросс-доменного запроса (например, с кастомными заголовками) браузер автоматически отправляет OPTIONS-запрос для проверки разрешений.
Пример запроса и ответа:
OPTIONS /api/users HTTP/1.1
Host: example.com
Origin: https://myapp.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, AuthorizationHTTP/1.1 200 OK
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400Характеристики метода:
- Идемпотентный и безопасный: Не изменяет состояние ресурса.
- Ответ: Сервер возвращает заголовки
Allow(стандартный HTTP) и CORS-заголовки (Access-Control-Allow-*). - Использование: Отладка API, механизм CORS, автоматическое обнаружение возможностей сервера.
Ответ 18+ 🔞
Да ты посмотри, что вытворяют эти ваши браузеры, блядь! Сидит такой, сука, паук-программист, накодил себе API, а оно не работает — и начинается: «Почему? А? Почему запрос не летит?». А потому, что забыл про этот ёбанный OPTIONS, вот почему!
Представь картину: твой фронтенд на myapp.com такой весь из себя важный, решил отправить PUT запрос на example.com, да ещё и с какими-то своими, блядь, хитрожопыми заголовками Content-Type и Authorization. А браузер-то не дурак, он как сторожевой пёс: «Стой, бля! Ты куда? На чужой домен? С какими-то левыми заголовками? А ну-ка, блядь, проверим, что там сервер скажет!».
И шлёт он, сука, не сам запрос, а сначала разведчика — этот самый OPTIONS. Типа, «Эй, сервак, а можно вот так и так?». И в запросе этом, смотри, какая подстава:
OPTIONS /api/users HTTP/1.1
Host: example.com
Origin: https://myapp.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization«Ориджин» — это я, мол, с какого хуя пришёл. «Дайте-ка мне метод PUT и вот эти ваши заголовки».
А сервер, если он не совсем мудак, должен ответить чётко и ясно:
HTTP/1.1 200 OK
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400Вот это уже дело! «Allow» — это типа «вообще-то я вот такие все методы понимаю, ваще». А дальше — конкретика для этого чувака с myapp.com: «Ладно, иди, хуле. С PUT методом заходи, заголовки твои я вижу, валидные. И запомни на 86400 секунд, чтобы каждый раз не спрашивать, заебешь».
А если сервер в ответ плюнет или скажет «Access-Control-Allow-Origin: *» не поставит, или методы не перечислит — браузер тут же, блядь, встанет в позу: «Нет, извини, друг. Не пущу. CORS policy, ёпта». И будет в консоли красная ошибка, а фронтендер — биться головой об клавиатуру.
И самое пикантное, что этот OPTIONS — он, блять, святой. Идемпотентный и безопасный. Ничего на сервере не меняет, не трогает базу, не логирует. Как призрак, сука. Прилетел, узнал, что нужно, и растворился. Чисто техническая формальность, но без неё — нихуя не работает, весь этот ваш крутой кросс-доменный секс!
Так что, когда API с другого домена не отвечает, первым делом — смотри в Network вкладку, не тормозит ли там твой OPTIONS-запрос, ожидая разрешения на жизнь. Чаще всего вся проблема, блядь, именно в нём!