Недавно я устранил проблему с приложением, которое я запускал на локальном сервере JSON, который не позволял мне применять запросы PATCH. В частности, он выдавал ошибку CORS.

Если вы сталкиваетесь с аналогичной проблемой при использовании fetch, вот TL; DR для утомленного программиста: соглашение всегда заключается в том, чтобы писать методы запроса в upcase.

Согласно спецификации HTTP, запросы PATCH не нормализуются, поэтому: «patch»! == «PATCH». Напротив, запросы PUT нормализованы, "put" == "PUT".

Позвольте мне объяснить, как я пришел к этому. Во-первых, было бы полезно объяснить, что «нормализовать» строку - значит преобразовать ее в желаемый регистр. На самом деле байтовый регистр, потому что каждая буква в каждом случае имеет собственное двоичное представление. Когда fetch нормализует метод, он переводит его в верхний регистр.

В то время, когда я работал с приложением, у меня не хватало времени, поэтому я использовал запрос PUT, чтобы заставить его работать. Впрочем, потом я задавался вопросом, почему «put» не выдает ошибку, а «patch» - дает.

Поиск в Google показал, что у других возникла такая же проблема. Хотя исправление было ясным (патч http-метода чувствителен к регистру), объяснение было немного более непрозрачным (_ 1_ нужно кричать заглавными буквами), и поскольку я искал понимания, я перешел по сопутствующей ссылке и откопал дальше. Прежде чем двигаться дальше, я посмотрел исходный код для fetch, чтобы увидеть для себя массив нормализованных глаголов, и PATCH действительно не был включен в этот список (строка № 317).

Двигаясь дальше, здесь кто-то просил добавить PATCH к тому же массиву HTTP-глаголов. Ответом на this была ссылка на docs. Идем по кроличьей норе.

Раздел 2.2.1. В документах по методам выборки описывается, как он определяет и обрабатывает различные методы, а также перечислены некоторые полезные советы для лучшего понимания.

  • Здесь говорится, что определение метода такое же, как указано в документе RFC7230 (раздел 3.1.1.), В котором изложены стандарты синтаксиса и маршрутизации HTTP.
  • В нем также указано, что методы CORS-safelist - это методы, которые являются методами GET, HEAD или POST.
  • Кроме того, в нем перечислены методы, которые он ограничивает по соображениям безопасности (см. HTTPVERBSEC1, 2, 3), и к ним относятся методы CONNECT, TRACE и TRACK.
  • Наконец, в нем указаны HTTP-команды, которые он будет нормализовать (также перечисленные в строке № 317 исходного кода выборки): DELETE, GET, HEAD, OPTIONS, POST и PUT. Эти методы также являются частью тех, что включены в RFC7231 (раздел 4.1. Обзор). Этот документ RFC определяет стандарт HTTP для всего Интернета.

Итак, в заключение, поскольку PATCH не включен в стандарт IETF HTTP для связи с веб-сервером и, следовательно, не включен в исходный код выборки для нормализации HTTP-глаголов, мы всегда должны писать его в верхнем регистре в наших запросах к серверу, поскольку он, вероятно, будет заблокирован CORS filter иначе.

Вот почему мой запрос Fetch не работал.

Изучая эту статью, я имел лишь базовое представление о многих вещах, поэтому, если у вас есть какие-либо исправления, ресурсы или советы, пожалуйста, оставьте комментарий.