Fetch API - что такое перенаправление: руководство
недавно я играл с API выборки Javascript. Насколько я понимаю, по умолчанию все перенаправления обрабатываются прозрачно, и в конце я получаю ответ от последнего вызова в цепочке перенаправления.
однако я мог бы вызвать fetch с {redirect:' manual'}, в этом случае он вернет ответ opaqueredirect без полезной информации. От https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect
непрозрачный-перенаправить отфильтрованный ответ отфильтрованный ответ, тип которого "opaqueredirect", состояние 0, сообщение о состоянии-пустая последовательность байтов, список заголовков пуст, тело-null, и трейлер пуст.
https://fetch.spec.whatwg.org/#http-fetch говорит, что ответ становится opaqueredirect, если redirect установлен в "manual":
включить режим перенаправления по запросу:
...
- руководство
Набор ответ на непрозрачный перенаправленный отфильтрованный ответ, внутренний ответ которого является actualResponse.
спецификация также говорит:
другими словами, непрозрачный фильтрованный ответ и непрозрачный перенаправленный фильтрованный ответ почти неотличимы от сетевой ошибки.
учитывая все это, зачем устанавливать перенаправление на руководство при использовании Fetch API? Мне это кажется совершенно бесполезным. Есть ли случаи использования, где это было бы полезно?
1 ответов
Я думаю, что короткий ответ: если вы не делаете что-то с кодом service-worker, например, что https://github.com/whatwg/fetch/issues/66 описывает, вы никогда не хотите redirect: 'manual'.
более длинный ответ:
на спецификация HTML, похоже, требует браузеры, чтобы изначально установить режим перенаправления на manual когда браузер начинает переход к ресурсу, до этого... (re) делает это с отключенным режимом перенаправления? (В этом случае по умолчанию возвращается значение follow.) Я не понимаю, почему алгоритм в спецификации делает это таким образом, но думаю, что это должно быть связано с обработкой случая, когда навигация терпит неудачу. Несмотря на это, я считаю, что это единственное использование в любой спецификации для manual режим переадресации.
в любом случае, Fetch API предназначен для отображения всех тех же примитивов, которые браузеры используют в выборках, но это не означает, что всегда есть хорошее использование для этих примитивов в коде веб-приложения (в отличие от использования что браузеры сами делают из примитивов).
поэтому я думаю, что спецификация выборки требовала этого, хотя вы мог бы вызовите API с помощью redirect: 'manual', браузеры бросят, если вы это сделаете-я думаю, потому что тогда никто еще не выдвинул никаких веских причин для его установки в любом случае, кроме браузеров, выполняющих навигацию.
но это поведение, похоже, было изменено из-за https://github.com/whatwg/fetch/issues/66 который описывает a (угловой) случай, где redirect: 'manual' требуется в коде service-worker.
аналогичный случай чего - то, что вы можете установить в Fetch API, но с очень маленькой утилитой в коде веб-приложения, - это mode: 'no-cors'. Это было первоначально добавлено только потому, что браузеры используют его для определенных запросов, поэтому API Fetch предоставляет его. Но это еще один случай, который имеет ограниченную полезность только для сервисных работников-для кэширования ответов, чтобы служить позже, без необходимости изучать ответы (которые mode: 'no-cors' предотвращает код веб-приложения от doing).