사양

여기에 써있는 것의 일본어 번역과 실제로 사용할 때의 보충.

fetch mode

요청 모드를 결정하는 옵션.

fetch(url, { mode: "cors" })

no-cors

CORS-safelisted methods와 CORS-safelisted request-headers 만 사용한 요청을 보냅니다.
성공하면 opaque filtered response를 반환합니다.
no-cors 라는 말대로, 실질별 오리진에의 리퀘스트로서는 기능하지 않게 된다.

CORS-safelisted methods 및 CORS-safelisted request-headers

htps : //로 ゔぇぺぺr. 모잖아. 오 rg / 그럼 / cs / u b / Ht tP / RS
여기의 "단순 요청"항목을 참조하십시오.

opaque filtered response

no-cors의 경우, CORS라도 에러가 나오지 않고, 아래와 같은 허무한 응답이 돌려준다.

type: "opaque"

URL list: 하늘

status: 0

status message: 빈 문자열

header list: 하늘

body: null

cors

CORS 요청을 보냅니다.
CORS의 프로토콜에 따르지 않는 경우(필요한 헤더가 없는 등)에는 에러가 된다.

CORS 요청을 원한다면 이것.

same-origin

Used to ensure requests are made to same-origin URLs. Fetch will return a network error if the request is not made to a same-origin URL.

다른 오리진에 대한 요청을 보낼 수 없습니다.
요청 대상이 다른 오리진인 경우 즉 오류.

navigate

페이지 천이시에 사용하는 특별한 모드.
전혀 모르겠지만, 페이지 천이시에 js로 fetch를 발화시키는 것은 어떤 유스 케이스?

websocket

websocket 연결을 설정할 때 사용하는 특수 모드.
사양 이외에서 언급된 것을 본 적이 없기 때문에 무시해도 좋지 않을까()

mode의 기본값

fetch 사양에서는 "기본값은 no-cors이지만 새로운 기능에 no-cors를 사용하는 것은 안전하지 않기 때문에 권장하지 않습니다."합니다.
즉, 순수하게 CORS 리퀘스트를 보내는 경우는 아무것도 지정하지 않아 OK.

결국 어떤 것을 사용하면 좋을까?

cors 로 해 두면 좋은 생각이 들었습니다(대개 최근의 브라우저는 디폴트치가 cors이므로 막히는 지정이 불필요, 그러한 암묵적인 결정이 신경이 쓰이는 경우는 명시적으로 지정하자).
동일 오리진의 경우는 물론 문제없이 통과하고, 다른 오리진의 경우도 적절하지 않으면 에러가 됩니다.

반대로 동일 오리진 이외에의 의도하지 않은 액세스를 하지 않게 하기 위해 cors 라든지를 사용하는 경우도 있는 것일까?