ОПЦИИ Предварительный запрос выполняет код POST - это стандарт?

Question

Если я правильно понимаю, предварительный запрос OPTIONS отправляется для того, чтобы спросить «что здесь разрешено?».Затем, как только приходит ответ, если разрешено, вызывающий сайт отправляет запрос POST (или GET, но в моем случае это сообщение).Я выяснил, что, по крайней мере, в приложениях-функциях Azure запрос OPTIONS выполняет код, который, как я ожидал, будет выполняться только POST.Я полагаю, что это так, потому что, как только я добавил некоторую нулевую проверку (так как запрос OPTIONS не имеет полезной нагрузки в теле), все работало нормально.

Мне интересно, стандартно ли это.

Мне кажется, что если бы я написал API без использования приложений-функций Azure, я бы отправил запрос OPTIONS по пути, который установил бы соответствующие заголовки и возвратил бы ответ 200.И запрос POST будет отправлен по другому пути, который ожидает полезную нагрузку в теле.Если это так, как обычно, то это означает, что я только что обнаружил идиосинкразию функциональности Azure.Но если нет, это означает, что у меня есть кое-что, чтобы узнать о предварительном запросе OPTIONS.

Заранее спасибо за совет.

Дениз

Answer 1

Спасибо вам всем!Извините, мне было неясно.И извините, мне потребовалось некоторое время, чтобы вернуться.С этой стороны все было немного безумно.

Да, вызываемая функция - моя.И теперь я понимаю, что у браузера нет большого выбора относительно того, будет ли он вызывать OPTIONS.

И да, я мог бы заставить мою функцию Azure обрабатывать вызов параметров по-другому, и спасибо за это предложение.Это то, что я в итоге делал, но в основном я делал это, обрабатывая пустую полезную нагрузку.Первоначально я не следовал этой наилучшей практике, потому что думал, что любой действительный запрос будет иметь полезную нагрузку.Соответственно, любой запрос, который не имел полезной нагрузки, был недействительным и должен быть отклонен как отказ некоторого вида.Это было до того, как я узнал, что вызов OPTIONS фактически выполняет эту функцию.

Мой оставшийся вопрос: если бы я НЕ использовал Azure ... если бы я развернул свое собственное решение и где-то разместил его, я быиметь класс или, по крайней мере, методы, которые обрабатывают вызовы этого конкретного API.(Это то, что я новичок, так что терпите меня, если мои условия не совсем верны, и пожалуйста, поправьте меня).Так что, если бы я сделал свой собственный API, у меня был бы один метод для обработки вызова POST и другой метод для обработки вызова OPTIONS, не так ли?И метод, который обрабатывает вызов OPTIONS, будет возвращать информацию о том, что юридически возможно с этим API.И метод, который обрабатывает вызов POST, будет обрабатывать полезную нагрузку, отправленную с ним.И метод, который обрабатывает POST, не будет выполняться при отправке запроса OPTIONS.По крайней мере, я так и думал, что это сработает.И это мой вопрос - так ли это, если не позволить что-то вроде Azure управлять какой-то инфраструктурой?

Я просто пытаюсь понять, является ли запрос OPTIONS, выполняющий функцию POST, стандартной практикой, или это своего рода особенность работы с функциями Azure.

Еще раз спасибо за совет иза помощь мне понять эти вопросы.

Answer 2

Как уже упоминалось в sideshowbarker, запрос OPTIONS автоматически отправляется браузером, чтобы проверить, можно ли сделать запрос кросс-источника.

В случае функций Azure это будет обрабатываться Azure при работе в облаке.

Если ваша функция запускается, это будет означать, что у вас есть "options" в качестве поддерживаемого метода для HTTP Trigger

• В атрибуте HTTPTrigger для функций C #
• In functions.json для не-C # функций

Если вы хотите настроить ответы CORS и / или запуск функций в контейнере, вы всегда можете включить "options" в качестве поддерживаемого и отвечать по-разному, когда входящий HTTP-метод имеет значение OPTIONS.

Кроме того, если вы используете Управление API-интерфейсом Azure с функциями Azure , вы можете вместо этого перенести на него обработку CORS или даже использовать Прокси-функции , как показано здесь .