Fetch API - 리디렉션의 용도 : 수동

Question

최근에 Javascript Fetch API를 사용하고 있습니다. 내가 아는 한, 기본적으로 모든 리디렉션이 투명하게 처리되며 결국 리디렉션 체인의 마지막 호출로부터 응답을받습니다.

그러나 {redirect : 'manual'}을 사용하여 가져 오기를 호출 할 수 있습니다.이 경우 사용 가능한 정보가없는 opaqueredirect 응답이 반환됩니다. https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect

의 응답 여과 opaqueredirect에는 유형 인 "opaqueredirect", 상태 0, 상태 메시지가 빈 바이트 시퀀스 인 헤더리스트가 비어 본체가 null 필터링 응답이며, 트레일러는 빈.

https://fetch.spec.whatwg.org/#http-fetch

는 응답이 리디렉션은 '수동'으로 설정되어있는 경우 opaqueredirect 할 얻을 수 있다고 말한다 :

요청의 리디렉션 모드에 스위치 :
...
- 수동
        내부 응답이 actualResponse 인 opaque-redirect로 필터링 된 응답에 응답을 설정합니다.

사양은 말한다 즉 불투명 응답 여과하고 여과 불투명 리다이렉트 응답

네트워크 에러로부터 거의 구별.

이 모든 것을 감안할 때 Fetch API를 사용할 때 수동으로 리디렉션하는 이유는 무엇입니까? 나에게 그것은 꽤 쓸모없는 것처럼 보인다. 이것이 유용한 유스 케이스가 있습니까?

Answer 1

짧은 대답은 다음과 같습니다. https://github.com/whatwg/fetch/issues/66과 같은 서비스 작업자 코드를 사용하지 않는 한 redirect: 'manual'을 원하지 않습니다.

긴 대답 :

브라우저가 자원을 탐색 시작할 때 처음 manual로 리디렉션 모드를 설정하는 HTML spec seems to require 브라우저, 그 전에 ... (재) 해제 리디렉션 모드와 함께 그 일을? (이 경우 기본값은 follow입니다.) 스펙의 알고리즘이 왜 그렇게하는지 이해할 수 없지만 탐색에 실패한 경우를 처리하는 것과 관련이 있어야합니다. 어쨌든, 리디렉션 모드에 대한 모든 사양의 유일한 사용이라고 생각합니다.

어쨌든 Fetch API는 브라우저가 페치에서 사용하는 것과 동일한 모든 프리미티브를 표시하도록 설계되었지만 웹 앱 코드의 기본 요소에 항상 좋은 용도가 있음을 의미하지는 않습니다 (브라우저 그들 자신이 프리미티브를 만든다).

그래서 나는 당신이 redirect: 'manual'으로 API를 호출 할 수있다하더라도, 브라우저가 될 수 있도록 그 당시에는 아무도 아직 타당한 이유를 제시하지 않았기 때문에 당신이-I는 않았다 생각하면 던질 것을 요구하는 데 사용되는 가져 오기 사양을 생각한다 탐색을 수행하는 브라우저 이외의 모든 경우에 설정됩니다.

그러나 서비스 작업자 코드에 redirect: 'manual'이 필요한 (코너) 경우를 설명하는 https://github.com/whatwg/fetch/issues/66으로 인해 동작이 변경된 것으로 보입니다.

Fetch API에서 설정할 수있는 것과 비슷한 경우이지만 웹 앱 코드의 유틸리티가 거의없는 경우는 mode: 'no-cors'입니다. 브라우저가 특정 요청에 사용하기 때문에 초기에 추가되었으므로 Fetch API가이를 노출합니다. 하지만 그것은 서비스 근로자에게만 제한적인 유틸리티를 사용하는 또 다른 사례입니다. 응답을 캐싱하여 나중에 응답을 조사 할 필요없이 (다시 말해서 웹 앱 코드가 수행하지 못하도록합니다).