패치

특정 fetch controller controller에 대해 타이밍 보고(report timing)를 하려면, global object global을 받아 다음을 실행합니다:

1. Assert: controller의 report timing steps가 null이 아님을 확인합니다.

2. controller의 report timing steps를 global과 함께 호출합니다.

특정 fetch controller controller에 대해 다음 수동 리디렉트 처리를 하려면:

1. Assert: controller의 next manual redirect steps가 null이 아님을 확인합니다.

2. controller의 next manual redirect steps를 호출합니다.

fetch controller controller에 대해 전체 타이밍 정보 추출을 하려면:

1. Assert: controller의 full timing info가 null이 아님을 확인합니다.

2. controller의 full timing info를 반환합니다.

특정 fetch controller controller에 대해 선택적 error와 함께 abort 하려면:

1. controller의 state를 "aborted"로 설정합니다.

2. fallbackError를 "AbortError" DOMException으로 둡니다.

3. error가 주어지지 않았다면 fallbackError로 설정합니다.

4. serializedError를 StructuredSerialize(error)로 둡니다. 예외가 발생하면 serializedError를 StructuredSerialize(fallbackError)로 둡니다.

5. controller의 serialized abort reason을 serializedError로 설정합니다.

null 또는 Record abortReason 및 realm realm이 주어졌을 때 serialize된 abort reason 역직렬화는 다음과 같습니다:

1. fallbackError를 "AbortError" DOMException으로 둡니다.

2. deserializedError를 fallbackError로 둡니다.

3. abortReason이 null이 아니면, deserializedError를 StructuredDeserialize(abortReason, realm)로 둡니다. 예외가 발생하거나 undefined를 반환하면 deserializedError를 fallbackError로 둡니다.

4. deserializedError를 반환합니다.

fetch controller controller를 종료(terminate)하려면, controller의 state를 "terminated"로 설정합니다.

fetch timing info timingInfo가 주어졌을 때 불투명 타이밍 정보 생성은, timingInfo의 start time과 post-redirect start time이 timingInfo의 start time인 새로운 fetch timing info를 반환합니다.

알고리즘 algorithm, global object 또는 parallel queue taskDestination이 주어졌을 때 fetch 태스크 큐잉(queue a fetch task)은 다음과 같이 실행합니다:

1. taskDestination이 parallel queue라면, enqueue algorithm을 taskDestination에 추가합니다.

2. 그렇지 않으면, 글로벌 태스크(global task)를 networking task source에 taskDestination과 algorithm으로 큐잉합니다.

환경 설정 객체 environment 오프라인 여부 확인:

• 사용자 에이전트가 인터넷 연결이 없다고 가정하면, true를 반환한다.

• environment의 WebDriver BiDi 네트워크 오프라인 여부를 반환한다.

HTTP 따옴표 문자열 수집(collect an HTTP quoted string) 을 하려면 문자열(string) input, 위치 변수(position variable) position, 선택적 불리언 extract-value (기본값 false)가 주어졌을 때 다음을 수행합니다:

1. positionStart를 position으로 둡니다.

2. value를 빈 문자열로 둡니다.

3. Assert: input의 position에 있는 코드 포인트가 U+0022 (")임을 확인합니다.

4. position을 1만큼 증가시킵니다.

5. 다음이 참인 동안:

   1. U+0022 (") 또는 U+005C (\)가 아닌 코드 포인트 시퀀스 수집 결과를 input, position으로부터 value에 추가합니다.

   2. position이 input의 끝을 지난 경우, break합니다.

   3. quoteOrBackslash를 input의 position에 있는 코드 포인트로 둡니다.

   4. position을 1만큼 증가시킵니다.

   5. quoteOrBackslash가 U+005C (\)이면:

      1. position이 input의 끝을 지난 경우 U+005C (\)를 value에 추가하고 break합니다.

      2. input의 position에 있는 코드 포인트를 value에 추가합니다.

      3. position을 1만큼 증가시킵니다.

   6. 그 외의 경우:

      1. Assert: quoteOrBackslash가 U+0022 (")임을 확인합니다.

      2. Break.

6. extract-value가 true라면 value를 반환합니다.

7. input의 positionStart부터 position까지(포함)의 코드 포인트들을 반환합니다.

구조화 필드 값 가져오기(get a structured field value) 를 하려면 헤더 이름 name과 문자열 type이 헤더 목록 list에서 주어졌을 때 다음 단계를 실행합니다. 결과는 null 또는 구조화 필드 값(structured field value)입니다.

1. Assert: type은 "dictionary", "list", 또는 "item" 중 하나입니다.

2. value를 헤더 목록에서 name을 가져온 결과로 둡니다.

3. value가 null이면 null을 반환합니다.

4. result를 구조화 필드 파싱(parsing structured fields)의 결과로 둡니다. input_string은 value, header_type은 type입니다.

5. 파싱에 실패했다면 null을 반환합니다.

6. result를 반환합니다.

구조화 필드 값 가져오기는 해당 헤더가 존재하지 않는 것과 값이 구조화 필드 값으로 파싱에 실패한 것을 의도적으로 구분하지 않습니다. 이는 웹 플랫폼 전반에서 일관된 처리를 보장합니다.

구조화 필드 값 설정(set a structured field value) 을 하려면 튜플(tuple) (헤더 이름 name, 구조화 필드 값 structuredValue)과 헤더 목록 list가 주어집니다:

1. serializedValue를 구조화 필드 직렬화(serializing structured fields) 알고리즘을 structuredValue에 적용한 결과로 둡니다.

2. Set (name, serializedValue) 를 list에 적용합니다.

구조화 필드 값은 HTTP가(결국) 흥미롭고 효율적으로 직렬화할 수 있는 객체로 정의되어 있습니다. 현재 Fetch는 헤더 값만 바이트 시퀀스로 지원하므로, 이 객체들은 직렬화를 통해서만 헤더 목록에 설정할 수 있고, 파싱을 통해서만 헤더 목록에서 얻을 수 있습니다. 앞으로는 객체 상태가 끝까지 유지될 수도 있습니다. [RFC9651]

헤더 목록 list가 헤더를 포함(contains)하는지 여부는 헤더 이름 name이 list에 포함된 헤더 중 name이 바이트 대소문자 구분 없이 name과 일치하는 것이 있는지로 판단합니다.

가져오기(get)는 헤더 이름 name과 헤더 목록 list가 주어졌을 때 다음 단계를 실행합니다. 결과는 null 또는 헤더 값입니다.

1. list가 name을 포함하지 않으면 null을 반환합니다.

2. list에서 헤더 중 name이 바이트 대소문자 구분 없이 name과 일치하는 모든 값을 0x2C 0x20(쉼표+공백)으로 구분하여 순서대로 반환합니다.

가져오기, 디코드 및 분할(get, decode, and split) 은 헤더 이름 name과 헤더 목록 list가 주어졌을 때 다음 단계를 실행합니다. 결과는 null 또는 리스트 ( 문자열(string) )입니다.

1. value를 name을 가져온 결과로 둡니다.

2. value가 null이면 null을 반환합니다.

3. get, decode, and split을 value에 적용한 결과를 반환합니다.

get, decode, and split 을 헤더 값(header value) value에 대해 실행하려면 다음 단계를 따릅니다. 반환 값은 문자열 리스트(list of strings)입니다.

1. input을 isomorphic decoding value 결과로 둡니다.

2. position을 위치 변수(position variable)로, input의 시작 위치로 지정합니다.

3. values를 문자열 리스트(list of strings)로, 처음에는 « »로 둡니다.

4. temporaryValue를 빈 문자열로 둡니다.

5. 다음이 참인 동안 반복합니다:

   1. U+0022 (") 또는 U+002C (,)가 아닌 코드 포인트 시퀀스 수집 결과를 input, position으로부터 temporaryValue에 추가합니다.

      이 결과는 빈 문자열일 수도 있습니다.

   2. position이 input의 끝을 지나지 않았고, position 위치의 코드 포인트가 U+0022 (")이면:

      1. temporaryValue에 HTTP 따옴표 문자열 수집 결과를 input, position으로부터 추가합니다.

      2. position이 끝을 지나지 않았다면 continue합니다.

   3. temporaryValue의 시작과 끝에서 HTTP 탭 또는 공백을 모두 제거합니다.

   4. Append temporaryValue를 values에 추가합니다.

   5. temporaryValue를 빈 문자열로 설정합니다.

   6. position이 input의 끝을 지났다면 values를 반환합니다.

   7. Assert: input의 position 위치의 코드 포인트가 U+002C (,)임을 확인합니다.

   8. position을 1만큼 증가시킵니다.

특정 허용된 호출지(blessed call sites)를 제외하고, 위 알고리즘을 직접 호출하지 않아야 합니다. 대신 get, decode, and split을 사용하세요.

append는 헤더(header) (name, value)를 헤더 목록(header list) list에 추가하는 알고리즘입니다:

1. list가 name을 포함하면, name을 첫 번째 해당 헤더의 name으로 설정합니다.

   이렇게 하면 list에 이미 존재하는 헤더의 name의 대소문자가 재사용됩니다. 여러 개가 일치하면 헤더의 name은 모두 동일합니다.

2. Append (name, value)를 list에 추가합니다.

delete는 헤더 이름(header name) name을 헤더 목록(header list) list에서 제거하는 알고리즘입니다. 이때 헤더의 name이 바이트 대소문자 구분 없이 name과 일치하는 모든 헤더를 list에서 제거합니다.

set은 헤더(header) (name, value)를 헤더 목록(header list) list에 설정하는 방법입니다:

1. list가 name을 포함하면, 첫 번째 해당 헤더(header)의 값(value)을 value로 설정하고, 나머지 해당 헤더들은 제거한다.

2. 그렇지 않으면, append (name, value)를 list에 추가합니다.

combine은 헤더(header) (name, value)를 헤더 목록(header list) list에 결합하는 방법입니다:

1. list가 name을 포함하면, 첫 번째 해당 헤더의 value 뒤에 0x2C 0x20(쉼표+공백), value를 순서대로 이어붙입니다.

2. 그렇지 않으면, append (name, value)를 list에 추가합니다.

combine은 XMLHttpRequest 및 WebSocket 프로토콜 핸드셰이크에서 사용됩니다.

헤더 이름을 정렬된 소문자 집합으로 변환(convert header names to a sorted-lowercase set)하려면, 리스트(list) headerNames가 주어졌을 때 다음 단계를 따릅니다. 반환값은 순서 있는 집합(ordered set)의 헤더 이름(header name)입니다.

1. headerNamesSet을 새로운 순서 있는 집합으로 둡니다.

2. 각 name에 대해, 바이트 소문자화(byte-lowercasing) name을 headerNamesSet에 append합니다.

3. 오름차순 정렬을 headerNamesSet에 바이트 비교(byte less than)로 적용한 결과를 반환합니다.

sort and combine은 헤더 목록(header list) list를 입력받아, 다음 단계를 실행합니다. 반환값은 헤더 목록(header list)입니다.

1. headers를 헤더 목록(header list)으로 둡니다.

2. names를 헤더 이름을 정렬된 소문자 집합으로 변환한 결과로 둡니다. 이때 list 내 헤더들의 이름을 사용합니다.

3. 각 name에 대해:

   1. name이 `set-cookie`라면:

      1. values를 list에서 헤더 중 name이 바이트 대소문자 구분 없이 name과 일치하는 모든 값의 리스트로 둡니다.

      2. 각 value에 대해 Append (name, value)를 headers에 추가합니다.

   2. 그 외의 경우:

      1. value를 list에서 name을 가져온 결과로 둡니다.

      2. Assert: value가 null이 아님을 확인합니다.

      3. Append (name, value)를 headers에 추가합니다.

4. headers를 반환합니다.

헤더 값 정규화(normalize)는 바이트 시퀀스 potentialValue에서 선행 및 후행 HTTP 공백 바이트를 제거하는 것입니다.

헤더 (name, value) 가 CORS-안전 목록 요청 헤더(CORS-safelisted request-header)인지 판단하려면 다음 단계를 실행합니다:

1. value의 길이가 128을 초과하면 false를 반환합니다.

2. 바이트 소문자화(Byte-lowercase)한 name에 따라 분기합니다:

   `accept`

   value에 CORS-비안전 요청 헤더 바이트가 있으면 false를 반환합니다.

   `accept-language`

   `content-language`

   value에 0x30 (0)~0x39 (9), 0x41 (A)~0x5A (Z), 0x61 (a)~0x7A (z), 0x20 (SP), 0x2A (*), 0x2C (,), 0x2D (-), 0x2E (.), 0x3B (;), 0x3D (=)에 속하지 않는 바이트가 있으면 false를 반환합니다.

   `content-type`

   1. value에 CORS-비안전 요청 헤더 바이트가 있으면 false를 반환합니다.

   2. mimeType을 파싱(parsing)한 등가 디코딩(isomorphic decoding) value 결과로 둡니다.

   3. mimeType이 실패(failure)라면 false를 반환합니다.

   4. mimeType의 essence가 "application/x-www-form-urlencoded", "multipart/form-data", 또는 "text/plain"이 아니면 false를 반환합니다.

   이는 MIME 타입 추출(extract a MIME type) 알고리즘을 사용하지 않습니다. 해당 알고리즘은 관대하며, 서버가 이를 구현해야 한다고 기대하지 않기 때문입니다.

   MIME 타입 추출을 사용할 경우 아래 요청은 CORS 프리플라이트 없이 처리되고, 서버의 단순 파서는 요청 본문을 JSON으로 처리할 수 있습니다:

   fetch("https://victim.example/naïve-endpoint", {
     method: "POST",
     headers: [
       ["Content-Type", "application/json"],
       ["Content-Type", "text/plain"]
     ],
     credentials: "include",
     body: JSON.stringify(exerciseForTheReader)
   });
   

   `range`

   1. rangeValue를 단일 range 헤더 값 파싱(parsing a single range header value) 에 value와 false를 넘긴 결과로 둡니다.

   2. rangeValue가 실패(failure)면 false를 반환합니다.

   3. rangeValue[0]이 null이면 false를 반환합니다.

      웹 브라우저는 `bytes=-500`와 같은 range를 내보내지 않으므로 이 알고리즘은 그런 경우를 safelist하지 않습니다.

   기타

   false를 반환합니다.

3. true를 반환합니다.

`Content-Type` 헤더 safelist에는 제한적 예외가 있습니다. 자세한 내용은 CORS 프로토콜 예외를 참고하세요.

CORS-비안전 요청 헤더 바이트(CORS-unsafe request-header byte)는 바이트 byte가 다음 중 하나에 해당할 때입니다:

• byte가 0x20 미만이고 0x09 HT가 아닌 경우

• byte가 0x22 ("), 0x28 (왼쪽 괄호), 0x29 (오른쪽 괄호), 0x3A (:), 0x3C (<), 0x3E (>), 0x3F (?), 0x40 (@), 0x5B ([), 0x5C (\), 0x5D (]), 0x7B ({), 0x7D (}), 또는 0x7F DEL인 경우.

CORS-비안전 요청 헤더 이름(CORS-unsafe request-header names)은 헤더 목록 headers에 대해 다음과 같이 결정합니다:

1. unsafeNames를 새 리스트로 둡니다.

2. potentiallyUnsafeNames를 새 리스트로 둡니다.

3. safelistValueSize를 0으로 둡니다.

4. 각 headers의 header에 대해:

   1. header가 CORS-안전 목록 요청 헤더가 아니면, append header의 name을 unsafeNames에 추가합니다.

   2. 그 밖의 경우, header의 name을 potentiallyUnsafeNames에 추가하고, safelistValueSize에 header의 value의 길이만큼 더합니다.

5. safelistValueSize가 1024를 초과하면 각 potentiallyUnsafeNames의 name을 append로 unsafeNames에 추가합니다.

6. 헤더 이름을 정렬된 소문자 집합으로 변환한 unsafeNames를 반환합니다.

헤더 (name, value)가 no-CORS-안전 목록 요청 헤더(no-CORS-safelisted request-header)인지 판단하려면 다음 단계를 실행합니다:

1. name이 no-CORS-안전 목록 요청 헤더 이름이 아니면 false를 반환합니다.

2. (name, value)가 CORS-안전 목록 요청 헤더인지 여부를 반환합니다.

헤더 (name, value)가 금지된 요청 헤더(forbidden request-header)인지 판단하려면 다음 단계가 true를 반환하면 됩니다:

1. name이 다음 중 하나와 바이트 대소문자 구분 없이 일치하면:

   • `Accept-Charset`
   • `Accept-Encoding`
   • `Access-Control-Request-Headers`
   • `Access-Control-Request-Method`
   • `Connection`
   • `Content-Length`
   • `Cookie`
   • `Cookie2`
   • `Date`
   • `DNT`
   • `Expect`
   • `Host`
   • `Keep-Alive`
   • `Origin`
   • `Referer`
   • `Set-Cookie`
   • `TE`
   • `Trailer`
   • `Transfer-Encoding`
   • `Upgrade`
   • `Via`

   true를 반환합니다.

2. name을 바이트 소문자화하여, proxy- 또는 sec-으로 시작하면 true를 반환합니다.

3. name이 다음 중 하나와 바이트 대소문자 구분 없이 일치하면:

   • `X-HTTP-Method`
   • `X-HTTP-Method-Override`
   • `X-Method-Override`

   다음 절차를 실행합니다:

   1. parsedValues를 get, decode, and split value의 결과로 둡니다.

   2. 각 parsedValues의 method에 대해, isomorphic encoding한 method가 금지된 메서드(forbidden method)라면 true를 반환합니다.

4. false를 반환합니다.

헤더 값 추출(extract header values) 은 헤더(header) header가 주어졌을 때 다음 단계를 실행합니다:

1. header의 value를 ABNF 기준으로 header의 name에 대해 파싱에 실패하면 failure를 반환합니다.

2. header의 value를 ABNF 기준으로 파싱하여 나온 하나 이상의 값을 반환합니다.

헤더 목록 값 추출(extract header list values) 은 헤더 이름 name과 헤더 목록(header list) list가 주어졌을 때 다음 단계를 실행합니다:

1. list가 name을 포함하지 않으면 null을 반환합니다.

2. name에 대한 ABNF가 단일 헤더(header)만 허용하고, list가 name을 중복 포함하면 failure를 반환합니다.

   다른 오류 처리가 필요하다면, 먼저 원하는 헤더를 추출하세요.

3. values를 빈 리스트로 둡니다.

4. list에 name을 포함하는 모든 헤더(header) header에 대해:

   1. extract를 헤더 값 추출을 header에 실행한 결과로 둡니다.

   2. extract가 failure면 failure를 반환합니다.

   3. extract의 각 값을 순서대로 values에 추가합니다.

5. values를 반환합니다.

콘텐츠 범위 생성(build a content range)은 정수 rangeStart, 정수 rangeEnd, 정수 fullLength가 주어졌을 때 다음 단계를 실행합니다:

1. contentRange를 `bytes `로 둡니다.

2. rangeStart를 직렬화 및 등가 인코딩(isomorphic encoded) 하여 contentRange에 추가합니다.

3. 0x2D (-)를 contentRange에 추가합니다.

4. rangeEnd를 직렬화 및 등가 인코딩 하여 contentRange에 추가합니다.

5. 0x2F (/)를 contentRange에 추가합니다.

6. fullLength를 직렬화 및 등가 인코딩 하여 contentRange에 추가합니다.

7. contentRange를 반환합니다.

단일 range 헤더 값 파싱(parse a single range header value)은 바이트 시퀀스 value와 불리언 allowWhitespace가 주어졌을 때 다음을 실행합니다:

1. data를 등가 디코딩(isomorphic decoding) value 결과로 둡니다.

2. data가 "bytes"로 시작하지 않으면 failure를 반환합니다.

3. position을 위치 변수(position variable)로, data의 5번째 코드 포인트 위치로 둡니다.

4. allowWhitespace가 true라면, HTTP 탭 또는 공백 시퀀스를 data, position에서 수집합니다.

5. data의 position 위치 코드 포인트가 U+003D (=)가 아니면 failure를 반환합니다.

6. position을 1만큼 증가시킵니다.

7. allowWhitespace가 true라면, HTTP 탭 또는 공백 시퀀스를 data, position에서 수집합니다.

8. rangeStart를 ASCII 숫자(ASCII digits) 시퀀스를 data, position에서 수집한 결과로 둡니다.

9. rangeStartValue를 rangeStart가 빈 문자열이 아니면 10진수로 해석한 값, 아니면 null로 둡니다.

10. allowWhitespace가 true라면, HTTP 탭 또는 공백 시퀀스를 data, position에서 수집합니다.

11. data의 position 위치 코드 포인트가 U+002D (-)가 아니면 failure를 반환합니다.

12. position을 1만큼 증가시킵니다.

13. allowWhitespace가 true라면, HTTP 탭 또는 공백 시퀀스를 data, position에서 수집합니다.

14. rangeEnd를 ASCII 숫자(ASCII digits) 시퀀스를 data, position에서 수집한 결과로 둡니다.

15. rangeEndValue를 rangeEnd가 빈 문자열이 아니면 10진수로 해석한 값, 아니면 null로 둡니다.

16. position이 data의 끝을 지나지 않았다면 failure를 반환합니다.

17. rangeEndValue와 rangeStartValue가 모두 null이면 failure를 반환합니다.

18. rangeStartValue와 rangeEndValue가 모두 숫자이고, rangeStartValue가 rangeEndValue보다 크면 failure를 반환합니다.

19. (rangeStartValue, rangeEndValue)를 반환합니다.

    range 끝이나 시작이 생략될 수 있습니다. 예: `bytes=0-` 또는 `bytes=-500`도 유효한 range입니다.

단일 range 헤더 값 파싱은 허용된 range 헤더 값의 일부만 성공하지만, 미디어 요청이나 다운로드 재개 등에서 사용자 에이전트가 가장 자주 사용하는 형식입니다. 이 range 헤더 값 형식은 range 헤더 추가를 통해 설정할 수 있습니다.

environment settings object environment의 environment default `User-Agent` value를 얻으려면:

1. userAgent를 WebDriver BiDi emulated User-Agent로 environment에 대해 설정한다.

2. userAgent가 null이 아니라면, userAgent를 isomorphic encoded된 값으로 반환한다.

3. default `User-Agent` value를 반환한다.

복제(clone)를 본문 body에 대해 실행하려면 다음을 따릅니다:

1. « out1, out2 »를 teeing body의 스트림의 결과로 둡니다.

2. body의 스트림을 out1으로 설정합니다.

3. 나머지 멤버는 body에서 복사하고, 본문의 스트림만 out2로 하여 반환합니다.

바이트 시퀀스 bytes를 본문으로(as a body) 얻으려면, 안전하게 추출(safely extracting) bytes의 결과 중 body를 반환합니다.

점진적으로 읽기(incrementally read)는 본문(body) body와 알고리즘 processBodyChunk, 알고리즘 processEndOfBody, 알고리즘 processBodyError, 옵션으로 null, parallel queue 또는 global object taskDestination (기본값 null)이 주어졌을 때 다음을 실행합니다. processBodyChunk는 바이트 시퀀스를 인자로 받는 알고리즘이어야 하며, processEndOfBody는 인자 없이, processBodyError는 예외를 인자로 받는 알고리즘이어야 합니다.

1. taskDestination이 null이면 새 parallel queue 시작 결과를 taskDestination로 둡니다.

2. reader를 리더(getting a reader)로 body의 스트림에 대해 구합니다.

   이 동작은 예외를 발생시키지 않습니다.

3. 점진적 읽기 루프(incrementally-read loop)를 reader, taskDestination, processBodyChunk, processEndOfBody, processBodyError로 실행합니다.

점진적 읽기 루프(incrementally-read loop)를 실행하려면, ReadableStreamDefaultReader 객체 reader, parallel queue 또는 global object taskDestination, 알고리즘 processBodyChunk, 알고리즘 processEndOfBody, 알고리즘 processBodyError가 주어집니다:

1. readRequest를 다음 read request로 둡니다:

   chunk steps (chunk)

   1. continueAlgorithm을 null로 둡니다.

   2. chunk가 Uint8Array 객체가 아니라면, continueAlgorithm을 다음 단계로 설정합니다: processBodyError를 TypeError와 함께 실행.

   3. 그 외의 경우:

      1. bytes를 복사(copy)된 chunk로 둡니다.

         구현은 이 복사를 피하는 전략을 사용할 것을 강력히 권장합니다.

      2. continueAlgorithm을 다음 단계로 설정합니다:

         1. processBodyChunk를 bytes로 실행.

         2. 점진적 읽기 루프를 reader, taskDestination, processBodyChunk, processEndOfBody, processBodyError로 재귀 호출.

   4. fetch 태스크 큐잉을 continueAlgorithm, taskDestination에 실행합니다.

   close steps

   1. fetch 태스크 큐잉을 processEndOfBody, taskDestination에 실행합니다.

   error steps (e)

   1. fetch 태스크 큐잉을 processBodyError에 e와 taskDestination로 실행합니다.

2. 청크 읽기(Read a chunk)를 reader와 readRequest로 실행합니다.

완전히 읽기(fully read)는 본문(body) body, 알고리즘 processBody, 알고리즘 processBodyError, 옵션으로 null, parallel queue 또는 global object taskDestination (기본값 null)이 주어졌을 때 다음을 실행합니다. processBody는 바이트 시퀀스를 인자로 받는 알고리즘이어야 하며, processBodyError는 예외(옵션)를 인자로 받을 수 있는 알고리즘이어야 합니다.

1. taskDestination이 null이면 새 parallel queue 시작 결과를 taskDestination로 둡니다.

2. successSteps를 fetch 태스크 큐잉을 processBody에 bytes, taskDestination로 실행하는 알고리즘으로 둡니다.

3. errorSteps를 fetch 태스크 큐잉을 processBodyError에 exception, taskDestination로 실행하는 알고리즘으로 둡니다.

4. reader를 리더(getting a reader)로 body의 스트림에 대해 구합니다. 예외가 발생하면 errorSteps를 그 예외와 함께 실행하고 종료합니다.

5. 모든 바이트 읽기(Read all bytes)를 reader, successSteps, errorSteps로 실행합니다.

콘텐츠 코딩 처리(handle content codings)는 codings와 bytes가 주어졌을 때 다음 단계를 수행합니다:

1. codings가 지원되지 않으면 bytes를 반환합니다.

2. HTTP에서 설명한 대로 codings로 bytes를 디코딩한 결과를 반환합니다. 디코딩 중 오류가 발생하면 failure를 반환합니다. [HTTP]

요청(request) request의 redirect-taint를 계산하려면 다음 단계를 수행한다. 반환값은 "same-origin", "same-site", "cross-site" 중 하나다.

1. 단언(assert): request의 origin이 "client"가 아니다.

2. lastURL을 null로 둔다.

3. taint를 "same-origin"으로 둔다.

4. 각 url에 대해 request의 URL 목록을 반복한다:

   1. lastURL이 null이면 lastURL을 url로 설정하고, 계속 진행한다.

   2. url의 origin이 same site가 아니고, lastURL의 origin이 request의 origin이 same site가 아니면 "cross-site"를 반환한다.

   3. url의 origin이 같은 출처(same origin)가 아니고, lastURL의 origin이 request의 origin이 같은 출처가 아니면, taint를 "same-site"로 둔다.

   4. lastURL을 url로 설정한다.

5. taint를 반환한다.

요청 출처 직렬화(Serializing a request origin)를 요청(request) request에 대해 수행하려면 다음을 따른다:

1. 단언(assert): request의 origin이 "client"가 아니다.

2. request의 redirect-taint가 "same-origin"이 아니라면 "null"을 반환한다.

3. request의 origin을 직렬화(serialized)하여 반환한다.

요청 출처 바이트 직렬화(Byte-serializing a request origin)는 요청(request) request를 받아, 요청 출처 직렬화를 request에 수행한 결과를 동형 인코딩(isomorphic encode)하여 반환한다.

복제(clone)하려면, 요청(request) request에 대해 다음 단계를 따른다:

1. newRequest를 request의 복사본으로 두되, 본문(body)은 제외한다.

2. request의 본문(body)이 null이 아니면, newRequest의 본문을 복제한 request의 본문으로 설정한다.

3. newRequest를 반환한다.

range 헤더 추가(add a range header)하려면, 요청(request) request에 정수 first와, 선택적으로 정수 last를 가지고 다음을 수행한다:

1. 단언(assert): last가 주어지지 않았거나, first가 last보다 작거나 같다.

2. rangeValue를 `bytes=`로 둔다.

3. 정수 직렬화(serialize) 및 동형 인코딩을 first에 적용하여 그 결과를 rangeValue에 추가한다.

4. 0x2D(-)를 rangeValue에 추가한다.

5. last가 주어졌다면, 정수 직렬화 및 동형 인코딩을 적용하고, 그 결과를 rangeValue에 추가한다.

6. 추가(Append)(`Range`, rangeValue)를 request의 헤더 목록(header list)에 추가한다.

range 헤더는 포함 범위의 바이트 구간을 나타낸다. 예를 들어 first가 0이고 last가 500이면, 501바이트 범위이다.

여러 응답을 하나의 논리 리소스로 결합하는 기능들은 역사적으로 보안 버그의 원인이 되어왔다. 파셜 응답(partial responses)와 관련된 기능은 반드시 보안 검토를 받을 것.

응답 URL 직렬화(serialize a response URL for reporting)하려면, 응답(response) response에 대해 다음 단계를 따른다:

1. 단언(assert): response의 URL 목록이 비어 있지 않다.

2. url을 response의 URL 목록[0]의 복사본으로 둔다.

   이는 response의 URL이 아니다. 리다이렉트 대상 유출을 방지하기 위해서임(비슷한 고려사항은 CSP 보고 참조). [CSP]

3. 사용자명(username)을 url에 빈 문자열로 설정한다.

4. 비밀번호(password)를 url에 빈 문자열로 설정한다.

5. 직렬화(serialization)된 url을 조각(fragment) 제외를 true로 하여 반환한다.

Cross-Origin-Embedder-Policy에서 credentials 허용 여부를 확인하려면, 요청(request) request에 대해 다음 단계를 따른다:

1. 단언(assert): request의 origin이 "client"가 아니다.

2. request의 mode가 "no-cors"가 아니면 true 반환.

3. request의 client가 null이면 true 반환.

4. request의 client의 policy container의 embedder policy의 값이 "credentialless"가 아니면 true 반환.

5. request의 origin과 request의 현재 URL의 origin이 동일 출처(same origin)이고, request의 redirect-taint가 "same-origin"이 아니라면 true 반환.

6. false 반환.

적절한 네트워크 오류(appropriate network error)를 fetch params fetchParams에 대해 생성하려면:

1. Assert: fetchParams가 취소(canceled) 상태임을 확인한다.

2. fetchParams가 중단(aborted) 상태면 중단된 네트워크 오류(aborted network error)를 반환하고, 아니면 네트워크 오류를 반환한다.

복제(clone)를 응답(response) response에 대해 실행하려면:

1. response가 filtered response라면, 동일한 filtered response를 새로 만들되, 내부 응답은 response의 내부 응답을 복제한 것으로 한다.

2. newResponse를 response의 복사본(단, body는 제외)으로 둔다.

3. response의 body가 null이 아니면, newResponse의 body를 복제 response의 body로 설정한다.

4. newResponse를 반환한다.

location URL은 응답(response) response와 null 또는 ASCII 문자열 requestFragment가 주어졌을 때 아래 단계를 따라 값을 반환합니다. 반환 값은 null, failure, 또는 URL입니다.

1. response의 status가 리다이렉트 상태(redirect status)가 아니면 null을 반환합니다.

2. location을 extracting header list values에 `Location`과 response의 header list를 넘겨 호출한 결과로 둡니다.

3. location이 header value라면, location을 파싱(parsing)한 결과로, base는 response의 URL로 설정합니다.

   response가 Response 생성자로 만들어진 경우 response의 URL은 null이므로, location이 절대 URL+fragment 문자열이어야만 파싱이 성공합니다.

4. location이 URL이고 fragment가 null이면, location의 fragment를 requestFragment로 설정합니다.

   이렇게 하면 모든(합성 포함) 응답이 HTTP에서 정의된 리다이렉트 처리 모델을 따르게 됩니다. [HTTP]

5. location을 반환합니다.

location URL 알고리즘은 오직 이 표준 및 HTML의 수동 리다이렉트 처리 navigate 알고리즘에서만 사용됩니다. [HTML]

변환(translate)을 잠재적 destination potentialDestination에 대해 실행하려면 다음을 따른다:

1. potentialDestination이 "fetch"라면 빈 문자열을 반환한다.

2. Assert: potentialDestination이 destination임을 확인한다.

3. potentialDestination을 반환한다.

origin 해석(resolve an origin)을 하려면, 네트워크 파티션 키(network partition key) key와 origin origin이 주어진다:

1. origin의 host가 IP 주소라면, « origin의 host »를 반환한다.

2. origin의 host의 public suffix가 "localhost" 또는 "localhost."라면, « ::1, 127.0.0.1 »를 반환한다.

3. origin을 하나 이상의 IP 주소의 집합(set)으로 변환하는 구현 정의(implementation-defined) 작업을 수행한다.

   또한 단순히 IP 주소만 얻는 것 외에, 다른 연결 정보도 얻는 작업이 구현 정의로 수행될 수 있다. 예를 들어, origin의 scheme이 HTTP(S) scheme라면, 구현체는 HTTPS RR에 대한 DNS 질의를 할 수도 있다. [SVCB]

   이 작업이 성공하면, IP 주소의 집합(set)과 추가 구현 정의 정보를 반환한다.

4. 실패(failure)를 반환한다.

origin 해석 결과는 캐시될 수 있다. 캐시할 경우, key를 캐시 키의 일부로 사용해야 한다.

connection timing info clamp/coarsen 알고리즘은 connection timing info timingInfo, DOMHighResTimeStamp defaultStartTime, 불리언 crossOriginIsolatedCapability가 주어졌을 때 다음을 실행한다:

1. timingInfo의 connection start time이 defaultStartTime보다 작으면, 모든 시각 값을 defaultStartTime으로 하고 ALPN negotiated protocol은 timingInfo의 값을 사용한 새로운 connection timing info를 반환한다.

2. 아니라면 각 시각 값을 coarsen time 알고리즘으로 crossOriginIsolatedCapability를 넘겨 처리한 값을 사용하고, ALPN negotiated protocol은 timingInfo의 값을 사용한 새로운 connection timing info를 반환한다.

연결을 획득(obtain a connection)하려면, 네트워크 파티션 키(network partition key) key, URL url, 불리언 credentials, 선택적 새 연결 설정(new connection setting) new(기본값 "no"), 선택적 불리언 requireUnreliable(기본값 false), 그리고 선택적 WebTransport-hash 목록 webTransportHashes(기본값 « »)를 입력받아 다음을 따른다:

1. new가 "no"라면:

   1. 단언(assert): webTransportHashes 가 비어 있음.

   2. connections를 사용자 에이전트의 연결 풀(connection pool) 내에서 key가 key이고, origin이 url의 origin이며, credentials이 credentials인 연결(connections)의 집합으로 둔다.

   3. connections가 비어 있지 않고 requireUnreliable이 false라면, connections 중 하나를 반환한다.

   4. connections 안에 예를 들어 HTTP/3 등 신뢰할 수 없는(unreliable) 전송을 지원할 수 있는 연결이 있다면, 해당 연결을 반환한다.

2. proxies를 url에 대해 구현자 정의 방식(implementation-defined manner)으로 프록시를 찾은 결과로 둔다. 프록시가 없으면 proxies는 « "DIRECT" »로 둔다.

   여기가 WPAD나 PAC 등의 비표준 기술이 동작하는 부분이다. "DIRECT" 값은 이 url에 프록시를 사용하지 않음을 의미한다.

3. timingInfo를 새로운 connection timing info로 둔다.

4. 각 proxies의 proxy에 대해:

   1. timingInfo의 domain lookup start time을 unsafe shared current time으로 설정한다.

   2. hosts를 « url의 origin의 host »로 둔다.

   3. proxy가 "DIRECT"이면, hosts를 key와 url의 origin을 사용하여 origin 해석(resolve an origin) 을 실행한 결과로 설정한다.

   4. hosts가 실패(failure)면 continue.

   5. timingInfo의 domain lookup end time을 unsafe shared current time으로 둔다.

   6. connection을 다음 단계의 결과로 둔다: 연결 생성(create a connection)을 key, url의 origin, credentials, proxy, hosts에서 구현자 정의 방식으로 하나의 host, timingInfo, requireUnreliable, webTransportHashes로 호출한다. 이를 구현자 정의 횟수만큼 서로 병렬(parallel)로 시도하고, 최소 하나 이상 값이 반환될 때까지 기다린다. 구현자 정의 방식으로 반환값 중 하나를 선택해 반환한다. 반환값 중 연결(connection)인 다른 값들은 닫힐 수 있다.

      실질적으로 이것은 구현체가 origin 해석(resolve an origin)의 결과(프록시가 "DIRECT"일 때)로 여러 IP 주소를 받아 병렬로 연결을 시도하거나, IPv6 우선 등 정책을 구현할 수 있음을 의미한다.

   7. connection이 실패(failure)이면 continue.

   8. new가 "yes-and-dedicated"가 아니라면 append connection을 사용자 에이전트의 connection pool에 추가한다.

   9. connection을 반환한다.

5. 실패(failure)를 반환한다.

여러 구현상의 뉘앙스가 존재하므로 의도적으로 다소 포괄적으로 서술되어 있다. 이것이 <link rel=preconnect> 기능도 설명하고, 연결(connection)이 credentials를 기반으로 구분됨을 명확하게 규정한다. 예컨대, TLS 세션 식별자는 credentials가 false인 연결과 true인 연결 간에 재사용되지 않는다는 점이 명확해진다.

연결 생성을 위해, 네트워크 파티션 키 key, origin origin, 불리언 credentials, 문자열 proxy, host host, 연결 타이밍 정보 timingInfo, 불리언 requireUnreliable, 그리고 WebTransport-hash 목록 webTransportHashes가 주어진다:

1. timingInfo의 connection start time을 unsafe shared current time으로 설정한다.

2. connection을 새 연결(connection)로 두되, key는 key, origin은 origin, credentials는 credentials, timing info는 timingInfo로 한다. connection timing info 기록(record connection timing info)을 connection에 대해 수행하고, proxy와 origin을 고려하여 host로 HTTP 연결을 설정한다. 아래 주의사항 참고. [HTTP] [HTTP1] [TLS]

   • requireUnreliable가 true라면, HTTP/3 등 신뢰할 수 없는 전송을 지원하는 연결을 설정한다. [HTTP3]

   • 신뢰할 수 없는 전송을 지원하는 연결을 설정할 때는 WebTransport에 필요한 옵션을 활성화해야 한다. HTTP/3의 경우, 초기 SETTINGS 프레임에 SETTINGS_ENABLE_WEBTRANSPORT와 H3_DATAGRAM 값을 1로 포함한다. [WEBTRANSPORT-HTTP3] [HTTP3-DATAGRAM]

   • credentials가 false면, TLS 클라이언트 인증서를 보내지 않는다.

   • webTransportHashes가 비어 있지 않으면, 기본 인증서 검증 알고리즘 대신, 서버 인증서가 사용자 정의 인증서 요건을 만족하고, 인증서 해시 검증이 webTransportHashes에 대해 true를 반환하면 서버 인증서가 유효한 것으로 간주한다. 조건이 충족되지 않으면 실패를 반환한다.

   • 연결 설정에 실패하면(예: UDP, TCP, TLS 오류 등) 실패를 반환한다.

3. timingInfo의 ALPN 협상 프로토콜(ALPN negotiated protocol)을 connection의 ALPN Protocol ID로 설정하되, 다음 예외를 적용한다. [RFC7301]

   • 프록시가 설정된 경우, 터널 연결이 수립됐다면 그 터널링된 프로토콜의 ALPN Protocol ID여야 하며, 아닐 경우 프록시의 첫 홉(hop)에 대한 값이어야 한다.

   • 실험적이거나 등록되지 않은 프로토콜을 사용하는 경우, 사용된 ALPN Protocol ID(있다면)를 사용해야 한다. 프로토콜 협상에 ALPN이 사용되지 않았다면, 설명적인 다른 문자열을 써도 된다.

     timingInfo의 ALPN 협상 프로토콜은 실제 협상 방식에 관계없이 사용 네트워크 프로토콜을 식별하기 위한 것이다. 즉 ALPN이 실제로 쓰이지 않더라도 사용된 프로토콜을 지시하는 ALPN Protocol ID다.

   IANA는 ALPN Protocol ID 목록을 관리한다.

4. connection을 반환한다.

connection timing info 기록(record connection timing info) 알고리즘은 connection connection에 대해 timingInfo를 connection의 timing info로 두고, 다음 사항을 관찰한다:

• timingInfo의 connection end time은 서버나 프록시 연결 직후 unsafe shared current time이어야 한다. 단, 아래의 세부사항 준수:

  • 반환 시각에는 트랜스포트 연결 시간뿐 아니라, SOCKS 인증 등 기타 시간도 포함해야 한다. 자원 요청을 위한 TLS handshake 최소 완료까지의 시간도 포함해야 한다.

  • 이 연결에 TLS False Start를 썼다면, 서버 Finished 메시지 수신까지의 시간은 포함하지 않는다. [RFC7918]

  • 전체 handshake 완료를 기다리지 않고 early data로 요청을 보낸다면, 서버 ServerHello 수신까지의 시간은 포함하지 않는다. [RFC8470]

  • 전체 handshake 완료를 기다려 요청을 보낸 경우, 이 시간에는 전체 TLS handshake가 포함된다(설령 다른 요청이 early data로 이미 전송됐더라도).

  예시: 사용자 에이전트가 TLS 1.3 기반 HTTP/2 연결을 맺고 GET과 POST 요청을 보낸다. t1에 ClientHello 및 GET을 early data로 보낸 뒤, POST는 안전하지 않으므로([HTTP] 9.2.1절), handshake가 완료된 t2까지 기다렸다가 보낸다. 두 요청 모두 같은 연결을 사용했지만 GET의 connection end time은 t1, POST는 t2로 기록된다.

• 보안 트랜스포트를 쓴 경우, timingInfo의 secure connection start time은 handshake 시작 직전 unsafe shared current time이어야 한다. [TLS]

• connection이 HTTP/3라면, timingInfo의 connection start time과 secure connection start time이 동일해야 한다(HTTP/3에서는 보안 handshake가 연결 초기화와 동시에 이루어지기 때문). [HTTP3]

connection timing info clamp/coarsen 알고리즘은 재사용된 연결의 상세 정보 노출 방지 및 시간값 coarsen을 보장한다.

네트워크 파티션 키 결정(determine the network partition key) 알고리즘은 environment environment가 주어졌을 때 다음을 따른다:

1. topLevelOrigin을 environment의 top-level origin으로 둔다.

2. topLevelOrigin이 null이면, topLevelOrigin을 environment의 top-level creation URL의 origin으로 둔다.

3. Assert: topLevelOrigin은 origin이다.

4. topLevelSite를 obtain a site 알고리즘을 topLevelOrigin에 대해 실행한 결과로 둔다.

5. secondKey를 null 또는 구현 정의 값 중 하나로 둔다.

   secondKey는 의도적으로 다소 모호하게 정의되어 있다. 세부 내용은 아직 발전 중임. issue #1035 참고.

6. (topLevelSite, secondKey)를 반환한다.

네트워크 파티션 키 결정(determine the network partition key)을 하려면, request request에 대해 다음을 수행한다:

1. request의 reserved client가 null이 아니면, request의 reserved client를 사용하여 네트워크 파티션 키 결정 결과를 반환한다.

2. request의 client가 null이 아니면, request의 client를 사용하여 네트워크 파티션 키 결정 결과를 반환한다.

3. null을 반환한다.

HTTP 캐시 파티션 결정(determine the HTTP cache partition)을 하려면, request request에 대해 다음을 수행한다:

1. key를 request로 네트워크 파티션 키 결정(determine the network partition key)의 결과로 둔다.

2. key가 null이면, null을 반환한다.

3. key와 연관된 고유 HTTP 캐시를 반환한다. [HTTP-CACHING]

request request를 가져오는 것이 나쁜 포트(bad port)로 인해 차단되어야 하는지 결정하려면:

1. url을 request의 현재 URL로 한다.

2. url의 스킴(scheme)이 HTTP(S) 스킴이고, url의 포트(port)가 나쁜 포트(bad port)라면, blocked를 반환한다.

3. allowed를 반환한다.

2.10. response를 request에 대해 MIME 타입으로 차단해야 하는가?

다음 단계를 실행한다:

1. mimeType을 response의 header list에서 MIME 타입 추출의 결과로 둔다.

2. mimeType이 failure라면 allowed를 반환한다.

3. destination을 request의 destination으로 둔다.

4. destination이 script-like이고, 아래 중 하나라도 해당되면 blocked를 반환한다:

   • mimeType의 essence가 "audio/", "image/", "video/"로 시작하는 경우
   • mimeType의 essence가 "text/csv"인 경우

5. allowed를 반환한다.

요청의 `Cookie` 헤더를 추가(append a request `Cookie` header)하려면, request request에 대해 다음을 수행한다:

1. 사용자 에이전트가 request에 대해 쿠키를 사용하지 않도록 설정되어 있다면, 반환한다.

2. sameSite를 request에 대해 same-site 모드 결정(determine the same-site mode)의 결과로 둔다.

3. isSecure를 request의 현재 URL의 스킴(scheme)이 "https"라면 true, 아니면 false로 둔다.

4. httpOnlyAllowed를 true로 둔다.

   fetch 에서 호출되는 경우이므로 document.cookie getter와 달리 true가 된다.

5. cookies를 쿠키 검색(retrieve cookies)을 isSecure, request의 현재 URL의 host, request의 현재 URL의 path, httpOnlyAllowed, sameSite를 넘겨 호출한 결과로 둔다.

   쿠키 저장소는 정렬된 쿠키 목록을 반환한다.

6. cookies가 비어 있다면 반환한다.

7. value를 쿠키 직렬화(serialize cookies)를 cookies에 대해 실행한 결과로 둔다.

8. 추가(Append) (`Cookie`, value)를 request의 헤더 목록(header list)에 추가한다.

응답의 `Set-Cookie` 헤더 파싱 및 저장을 하려면, request request와 response response를 입력으로 다음을 수행한다:

1. 사용자 에이전트가 request에 대해 쿠키 사용을 비활성화한 경우, 반환한다.

2. allowNonHostOnlyCookieForPublicSuffix를 false로 둔다.

3. isSecure를 request의 현재 URL의 스킴(scheme)이 "https"이면 true, 아니면 false로 둔다.

4. httpOnlyAllowed를 true로 둔다.

   fetch에서 호출되었으므로(예: document.cookie getter가 아님) true가 된다.

5. sameSiteStrictOrLaxAllowed를 동일 사이트 모드 결정(determine the same-site mode) 의 결과가 "strict-or-less"면 true, 아니면 false로 둔다.

6. 각 response의 헤더 목록(header list)의 header에 대하여:

   1. header의 이름(name)이 `Set-Cookie`와 바이트 대소문자 무시(byte-case-insensitive)로 일치하지 않으면 continue 한다.

   2. 쿠키 파싱 및 저장(Parse and store a cookie)를 header의 값(value), isSecure, request의 현재 URL의 host, request의 현재 URL의 path, httpOnlyAllowed, allowNonHostOnlyCookieForPublicSuffix, sameSiteStrictOrLaxAllowed로 실행한다.

   3. 쿠키 정리(Garbage collect cookies)를 request의 현재 URL의 host를 넘겨 실행한다.

   다른 곳에서도 언급된 것처럼 `Set-Cookie` 헤더는 병합될 수 없어 각 인스턴스별로 독립적으로 처리되어야 한다. 이는 다른 어떤 헤더에도 허용되지 않는다.

주어진 request request에 대해 same-site 모드 결정을 하려면:

1. 단언(assert): request의 method가 "GET" 또는 "POST"임을 단언한다.

2. request의 최상위 네비게이션 발신자 출처(top-level navigation initiator origin)가 null이 아니고 request의 URL의 origin과 same site가 아니면 "unset-or-less"를 반환한다.

3. request의 method가 "GET"이고, request의 destination이 "document"이면 "lax-or-less"를 반환한다.

4. request의 client의 교차 사이트 상위(cross-site ancestor)가 있으면 "unset-or-less"를 반환한다.

5. request의 redirect-taint가 "cross-site"이면, "unset-or-less"를 반환한다.

6. "strict-or-less"를 반환한다.

URL url에 대해 직렬화된 쿠키 기본 경로(serialized cookie default path)를 얻으려면:

1. cloneURL을 url의 복제본으로 둔다.

2. cloneURL의 경로(path)를 쿠키 기본 경로(cookie default path)로 설정한다. (대상은 cloneURL의 경로(path)임)

3. cloneURL의 URL 경로 직렬화(URL path serialization)를 반환한다.

요청 `Origin` 헤더 추가(append a request `Origin` header)를 하려면, request request에 대해 다음을 수행한다:

1. 단언(assert): request의 origin이 "client"가 아님을 단언한다.

2. serializedOrigin을 요청 출처 바이트 직렬화(byte-serializing a request origin)를 request로 호출한 결과로 둔다.

3. request의 response tainting이 "cors"이거나, request의 mode가 "websocket" 또는 "webtransport"이면, 추가(Append) (`Origin`, serializedOrigin)를 request의 헤더 목록(header list)에 추가한다.

4. 그렇지 않고 request의 method가 `GET`도 아니고 `HEAD`도 아니라면:

   1. request의 mode가 "cors"가 아니라면, request의 referrer policy에 따라 분기한다(switch):

      "no-referrer"

      serializedOrigin을 `null`로 설정한다.

      "no-referrer-when-downgrade"

      "strict-origin"

      "strict-origin-when-cross-origin"

      request의 origin이 튜플 출처(tuple origin)이고, 그 scheme이 "https"이며, request의 현재 URL의 scheme이 "https"가 아니면, serializedOrigin을 `null`로 설정한다.

      "same-origin"

      request의 origin이 request의 현재 URL의 origin과 동일 출처(same origin)가 아니면, serializedOrigin을 `null`로 설정한다.

      그 외

      아무 것도 하지 않는다.

   2. 추가(Append) (`Origin`, serializedOrigin)를 request의 헤더 목록(header list)에 추가한다.

request의 referrer policy는, fetcher가 (예: CORS 프로토콜 등으로) 명시적으로 서버에 출처(origin) 공유를 선택하지 않은 모든 fetch에 대해 고려된다.

길이 추출(extract a length) 알고리즘은 header list headers에서 다음 단계를 실행한다:

1. values를 getting, decoding, and splitting `Content-Length` from headers의 결과로 둔다.

2. values가 null이면 null을 반환한다.

3. candidateValue를 null로 둔다.

4. 각 values의 value에 대해:

   1. candidateValue가 null이면 candidateValue에 value를 할당한다.

   2. 아니라면 value가 candidateValue와 다르면 failure를 반환한다.

5. candidateValue가 빈 문자열이거나, code point 중 ASCII digit이 아닌 것이 있으면 null을 반환한다.

6. candidateValue를 10진수 숫자로 해석하여 반환한다.

MIME 타입 추출(extract a MIME type) 알고리즘은 header list headers에서 다음 단계를 실행한다. 반환 값은 failure 또는 MIME 타입이다.

1. charset을 null로 둔다.

2. essence를 null로 둔다.

3. mimeType을 null로 둔다.

4. values를 getting, decoding, and splitting `Content-Type` from headers의 결과로 둔다.

5. values가 null이면 failure를 반환한다.

6. 각 values의 value에 대해:

   1. temporaryMimeType을 MIME 타입 파싱(parsing) value 결과로 둔다.

   2. temporaryMimeType이 failure이거나, 그 essence가 "*/*"면 continue한다.

   3. mimeType을 temporaryMimeType으로 둔다.

   4. mimeType의 essence가 essence와 다르면:

      1. charset을 null로 둔다.

      2. mimeType의 parameters["charset"]가 존재하면 charset을 그 값으로 둔다.

      3. essence를 mimeType의 essence로 둔다.

   5. 아니라면, mimeType의 parameters["charset"]가 존재하지 않고, charset이 null이 아니면 mimeType의 parameters["charset"]를 charset으로 둔다.

7. mimeType이 null이면 failure를 반환한다.

8. mimeType을 반환한다.

레거시 인코딩 추출(legacy extract an encoding) 알고리즘은 failure 또는 MIME 타입 mimeType과 encoding fallbackEncoding이 주어졌을 때 다음을 따른다:

1. mimeType이 failure면 fallbackEncoding을 반환한다.

2. mimeType["charset"]이 존재하지 않으면 fallbackEncoding을 반환한다.

3. tentativeEncoding을 get an encoding 알고리즘에 mimeType["charset"]을 넘겨 실행한 결과로 둔다.

4. tentativeEncoding이 failure면 fallbackEncoding을 반환한다.

5. tentativeEncoding을 반환한다.

헤더 목록(header list) list에 대해 nosniff 판정(determine nosniff)을 하려면 다음을 실행한다:

1. values를 get, decode, split을 list에서 `X-Content-Type-Options` 에 대해 수행한 결과로 둔다.

2. values가 null이면 false를 반환한다.

3. values[0]이 "nosniff"와 ASCII 대소문자 구분 없이(ASCII case-insensitive) 일치하면 true를 반환한다.

4. false를 반환한다.

3.6.1. nosniff로 인해 response가 request에 대해 차단되어야 하는가?

다음 단계를 실행한다:

1. nosniff 판정(determine nosniff)을 response의 헤더 목록에 대해 호출했을 때 false라면 allowed를 반환한다.

2. mimeType을 헤더에서 MIME 타입 추출(extract MIME type)을 response의 헤더 목록에 대해 호출한 결과로 둔다.

3. destination을 request의 destination으로 둔다.

4. destination이 script-like이고 mimeType이 실패(failure)거나 자바스크립트 MIME 타입(JavaScript MIME type)이 아니면 blocked를 반환한다.

5. destination이 "style"이고, mimeType이 실패(failure)거나 그 essence가 "text/css"가 아니면 blocked를 반환한다.

6. allowed를 반환한다.

request의 destination 중 script-like이나 "style"만이 고려된다. 이는 악용 사례가 이 둘에 해당하기 때문이다. 또한 "image"에 대해선 배포된 컨텐트와 호환되지 않아 제외되었다.

다음 입력을 받아 교차 출처 리소스 정책 검사(cross-origin resource policy check)를 수행하려면: origin origin, 환경 설정 객체(environment settings object) settingsObject, 문자열 destination, response response, 선택적 불리언 forNavigation을 받아 다음 단계를 실행한다:

1. forNavigation이 주어지지 않았으면 false로 둔다.

2. embedderPolicy를 settingsObject의 policy container의 embedder policy로 둔다.

3. cross-origin resource policy internal check를 origin, "unsafe-none", response, forNavigation을 넘겨 호출했을 때 blocked를 반환한다면 blocked를 반환한다.

   이 단계는 아래의 Cross-Origin Embedder Policy와 관련 없는 위반사항은 보고하지 않도록 필요하다.

4. cross-origin resource policy internal check를 origin, embedderPolicy의 report only value, response, forNavigation으로 호출해서 blocked를 반환한다면, cross-origin embedder policy CORP violation report 큐잉을 response, settingsObject, destination, true로 실행한다.

5. cross-origin resource policy internal check를 origin, embedderPolicy의 value, response, forNavigation으로 호출해서 allowed를 반환한다면 allowed를 반환한다.

6. cross-origin embedder policy CORP violation report 큐잉을 response, settingsObject, destination, false로 실행한다.

7. blocked를 반환한다.

오직 HTML의 navigate 알고리즘만 forNavigation을 true로 주고 이 검사를 호출하는데 항상 중첩 탐색(nested navigation)에서 사용된다. 이외에는 response가 내부 응답(internal response) [opaque filtered response의]이거나, 응답(response)으로 [opaque filtered response의] 내부 응답이 될 것이다. [HTML]

origin origin, embedder policy value embedderPolicyValue, response response, 불리언 forNavigation을 입력으로 cross-origin resource policy internal check를 수행하려면:

1. forNavigation이 true이고 embedderPolicyValue가 "unsafe-none"이면 allowed를 반환한다.

2. policy를 헤더값 가져오기(get)로 response의 `Cross-Origin-Resource-Policy` 헤더값을 가져온다.

   즉 `Cross-Origin-Resource-Policy: same-site, same-origin` (콤마로 둘 다 있을 경우)는 실제론 아래에서 무조건 allowed가 된다. embedderPolicyValue가 "unsafe-none"인 한 어느 것도 매치되지 않기 때문이다. 하나 이상의 `Cross-Origin-Resource-Policy` 헤더가 있어도 효과는 같다.

3. policy가 `same-origin`, `same-site`, `cross-origin` 중 어느 것도 아니면 null로 설정한다.

4. policy가 null이면 embedderPolicyValue 기준으로 분기한다:

   "unsafe-none"

   아무 것도 하지 않는다.

   "credentialless"

   아래 둘 중 하나라도 true면 policy를 `same-origin`으로 설정한다:

   • response의 request-includes-credentials 가 true이거나,
   • forNavigation이 true

   "require-corp"

   policy를 `same-origin`으로 설정한다.

5. policy에 따라 분기한다:

   null

   `cross-origin`

   allowed를 반환한다.

   `same-origin`

   origin이 동일 출처(same origin)이고, response의 URL의 origin과 동일하면 allowed 반환, 그렇지 않으면 blocked 반환.

   `same-site`

   아래 모두 해당하면 allowed:

   • origin이 schemelessly same site이고, response의 URL의 origin과 같음.

   • origin의 스킴(scheme)이 "https"이거나, response의 URL의 스킴이 "https"가 아님

   위 조건을 모두 만족하면 allowed 반환, 아니면 blocked 반환.

   `Cross-Origin-Resource-Policy: same-site`는 보안 전송(secure transport)으로 전송된 응답이 비보안 요청 origin과 동일 사이트(host가 같아도)로 간주하지 않는다. 보안 전송된 응답은 반드시 보안 전송된 발신자(initiator)와만 매치된다.

response response, environment settings object settingsObject, 문자열 destination, 불리언 reportOnly가 입력일 때, cross-origin embedder policy CORP violation report 큐잉 알고리즘은 다음과 같다:

1. endpoint를 reportOnly가 true이면서 settingsObject의 policy container의 embedder policy의 report only reporting endpoint라면 그것으로, 아니면 reporting endpoint로 둔다.

2. serializedURL를 응답 URL 직렬화(serialize a response URL for reporting)를 response에 수행한 결과로 둔다.

3. disposition을 reportOnly가 true라면 "reporting"으로, 아니면 "enforce"로 둔다.

4. body를 다음 속성을 갖는 새 객체로 둔다:

   key	value
   "type"	"corp"
   "blockedURL"	serializedURL
   "destination"	destination
   "disposition"	disposition

5. Generate and queue a report를, settingsObject의 글로벌 객체(global object), "coep" 리포트 타입(report type), endpoint, body를 넘겨 실행한다. [REPORTING]

다음 단계들을 실행한다: fetch를 수행하기 위해, 주어진 요청 request, 선택적 알고리즘 processRequestBodyChunkLength, 선택적 알고리즘 processRequestEndOfBody, 선택적 알고리즘 processEarlyHintsResponse, 선택적 알고리즘 processResponse, 선택적 알고리즘 processResponseEndOfBody, 선택적 알고리즘 processResponseConsumeBody, 그리고 선택적 불리언 useParallelQueue (기본값 false)이 주어지면 아래 단계를 실행한다. 주어진다면, processRequestBodyChunkLength는 전송된 바이트 수를 나타내는 정수를 인수로 받는 알고리즘이어야 한다. 주어진다면, processRequestEndOfBody는 인수를 받지 않는 알고리즘이어야 한다. 주어진다면, processEarlyHintsResponse는 응답을 인수로 받는 알고리즘이어야 한다. 주어진다면, processResponse는 응답을 인수로 받는 알고리즘이어야 한다. 주어진다면, processResponseEndOfBody는 응답을 인수로 받는 알고리즘이어야 한다. 주어진다면, processResponseConsumeBody는 응답과 null, 실패, 또는 바이트 시퀀스를 인수로 받는 알고리즘이어야 한다.

사용자 에이전트는 진행 중인 fetch를 일시중단하도록 요청받을 수 있다. 사용자 에이전트는 일시중단 요청을 수락하거나 무시할 수 있다. 일시중단된 fetch는 재개될 수 있다. 사용자 에이전트는 진행 중인 fetch가 요청에 대한 HTTP 캐시의 응답을 갱신하고 있는 경우 일시중단 요청을 무시해야 한다.

사용자 에이전트는 요청의 캐시 모드가 "no-store"이거나 응답에 `Cache-Control: no-store` 헤더가 나타나면 해당 요청에 대한 HTTP 캐시 항목을 갱신하지 않는다. [HTTP-CACHING]

1. 단언(Assert): request의 mode가 "navigate"이거나 processEarlyHintsResponse가 null이다.

   초기 힌트(상태가 103인 응답)의 처리는 네비게이션에 대해서만 검증된다.

2. taskDestination를 null로 둔다.

3. crossOriginIsolatedCapability를 false로 둔다.

4. 클라이언트로부터 요청 채우기를 주어진 request로 실행한다.

5. 만약 request의 클라이언트가 null이 아니면, 다음을 실행한다:

   1. taskDestination를 request의 클라이언트의 글로벌 객체로 설정한다.

   2. crossOriginIsolatedCapability를 request의 클라이언트의 교차 출처 격리 능력으로 설정한다.

6. 만약 useParallelQueue가 true이면, taskDestination를 새 병렬 큐 시작의 결과로 설정한다.

7. timingInfo를 새로운 fetch timing info로 정한다. 그 시작 시간과 리디렉션 이후 시작 시간은 조정된 공유 현재 시간이며 crossOriginIsolatedCapability를 고려하여 가져온다. 또한 렌더 차단(render-blocking)은 request의 render-blocking으로 설정된다.

8. fetchParams를 새로운 fetch params로 정한다. 그 request는 request이고, timing info는 timingInfo, process request body chunk length는 processRequestBodyChunkLength, process request end-of-body는 processRequestEndOfBody, process early hints response는 processEarlyHintsResponse, process response는 processResponse, process response consume body는 processResponseConsumeBody, process response end-of-body는 processResponseEndOfBody, task destination는 taskDestination, 그리고 cross-origin isolated capability는 crossOriginIsolatedCapability로 설정한다.

9. 만약 request의 본문이 바이트 시퀀스라면, request의 본문을 request의 본문을 바디로서 설정한다.

10. 다음 모든 조건이 참이면:

    • request의 URL의 스킴이 HTTP(S) 스킴이다.

    • request의 mode가 "same-origin", "cors", 또는 "no-cors"이다.

    • request의 클라이언트가 null이 아니고, request의 클라이언트의 글로벌 객체가 Window 객체이다.

    • request의 메서드가 `GET`이다.

    • request의 unsafe-request 플래그가 설정되어 있지 않거나 request의 헤더 목록이 비어 있다.

    그렇다면:

    1. 단언(Assert): request의 원점(origin)이 request의 클라이언트의 origin과 동일 출처(same origin)임을 단언한다.

    2. onPreloadedResponseAvailable를 다음과 같은 알고리즘으로 정한다: 주어진 응답 response에 대해 실행되는 알고리즘은 fetchParams의 preloaded response candidate를 response로 설정한다.

    3. foundPreloadedResource를 request의 consume a preloaded resource를 request의 클라이언트에 대해 호출한 결과로 정한다. 호출에는 request의 URL, request의 destination, request의 mode, request의 credentials mode, request의 무결성 메타데이터, 그리고 onPreloadedResponseAvailable를 넘긴다.

    4. 만약 foundPreloadedResource가 true이고 fetchParams의 preloaded response candidate가 null이면, fetchParams의 해당 항목을 "pending"으로 설정한다.

11. 만약 request의 헤더 목록이 `Accept`를 포함하지 않으면:

    1. value를 `*/*`로 둔다.

    2. 만약 request의 initiator가 "prefetch"라면, value를 문서의 `Accept` 헤더 값으로 설정한다.

    3. 그렇지 않으면, 사용자 에이전트는 request의 destination를 기준으로 다음 중 첫 번째 일치 항목으로 value를 설정해야 한다:

       "document"

       "frame"

       "iframe"

       문서의 `Accept` 헤더 값

       "image"

       `image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5`

       "json"

       `application/json,*/*;q=0.5`

       "style"

       `text/css,*/*;q=0.1`

    4. 추가(Append) (`Accept`, value)를 request의 헤더 목록에 수행한다.

12. 만약 request의 헤더 목록이 `Accept-Language`를 포함하지 않고 request의 클라이언트가 null이 아니면:

    1. emulatedLanguage를 WebDriver BiDi 모사 언어로 정한다. 이는 request의 클라이언트에 대한 값이다.

    2. 만약 emulatedLanguage가 null이 아니면:

       1. encodedEmulatedLanguage를 emulatedLanguage의 isomorphic 인코딩으로 둔다.

       2. 추가(Append) (`Accept-Language`, encodedEmulatedLanguage)를 request의 헤더 목록에 수행한다.

13. 만약 request의 헤더 목록이 `Accept-Language`를 포함하지 않으면, 사용자 에이전트는 추가 (`Accept-Language, 적절한 헤더 값)를 request의 헤더 목록에 수행해야 한다.

14. 만약 request의 내부 우선순위(request-internal-priority)가 null이면, request의 우선순위, initiator, destination, 및 render-blocking을 구현 방식에 따라 사용하여 request의 내부 우선순위를 구현 상 정의된 객체로 설정한다.

    구현 상 정의된 객체는 HTTP/2의 스트림 가중치와 의존성, 적용되는 전송(예: HTTP/3)을 위한 Extensible Prioritization Scheme for HTTP에서 사용되는 우선순위, 또는 HTTP/1 페치의 디스패치 및 처리 우선순위를 정하는 데 사용되는 동등한 정보를 포함할 수 있다. [RFC9218]

15. 만약 request가 서브리소스 요청(subresource request)이면:

    1. record를 새로운 fetch record로 정한다. 그 request는 request이고 controller는 fetchParams의 controller이다.

    2. 추가(Append) record를 request의 클라이언트의 fetch group의 fetch records에 추가한다.

16. 메인 fetch를 fetchParams로 실행한다.

17. fetchParams의 controller를 반환한다.

주어진 요청 request에 대해 클라이언트로부터 요청을 채우기를 수행하려면:

1. 만약 request의 사용자 프롬프트를 위한 traversable가 "client"이면:

   1. request의 사용자 프롬프트를 위한 traversable를 "no-traversable"로 설정한다.

   2. 만약 request의 클라이언트가 null이 아니면:

      1. global를 request의 클라이언트의 글로벌 객체로 둔다.

      2. 만약 global가 Window 객체이고 global의 navigable이 null이 아니면, request의 사용자 프롬프트를 위한 traversable를 global의 navigable의 traversable navigable로 설정한다.

2. 만약 request의 origin이 "client"이면:

   1. 단언(Assert): request의 클라이언트는 null이 아니다.

   2. request의 origin을 request의 클라이언트의 origin으로 설정한다.

3. 만약 request의 정책 컨테이너(policy container)가 "client"이면:

   1. 만약 request의 클라이언트가 null이 아니면, request의 정책 컨테이너를 request의 클라이언트의 정책 컨테이너의 클론으로 설정한다. [HTML]

   2. 그렇지 않으면, request의 정책 컨테이너를 새로운 정책 컨테이너로 설정한다.

main fetch를 실행하려면, fetch params fetchParams와 선택적 불리언 recursive (기본값 false)를 받아 다음 단계를 실행한다:

1. request를 fetchParams의 request로 둔다.

2. response를 null로 둔다.

3. request의 local-URLs-only flag가 설정되어 있고, request의 current URL이 local이 아니면, response를 네트워크 에러로 설정한다.

4. Content Security Policy 위반 사항을 request에 대해 보고한다.

5. request를 필요하다면 잠재적으로 신뢰할 수 있는 URL로 업그레이드한다.

6. 혼합 콘텐츠 request를 필요하다면 잠재적으로 신뢰할 수 있는 URL로 업그레이드한다.

7. request가 잘못된 포트로 인해 차단되어야 하는지, request fetch가 혼합 콘텐츠로 인해 차단되어야 하는지, Content Security Policy에 의해 request가 차단되어야 하는지, 무결성 정책에 의해 request가 차단되어야 하는지 중 하나라도 blocked를 반환하면, response를 네트워크 에러로 설정한다.

8. request의 referrer policy가 빈 문자열이면, request의 referrer policy를 request의 policy container의 referrer policy로 설정한다.

9. request의 referrer가 "no-referrer"가 아니면, request의 referrer를 request의 referrer 결정의 결과로 설정한다. [REFERRER]

   Referrer Policy에서 명시한 대로, 사용자 에이전트는 최종 사용자에게 request의 referrer를 "no-referrer"로 오버라이드하거나 덜 민감한 정보만 노출하도록 선택권을 제공할 수 있습니다.

10. request의 current URL의 scheme을 아래 조건이 모두 true이면 "https"로 설정한다:

    • request의 current URL의 scheme이 "http"임
    • request의 current URL의 host가 도메인임
    • request의 current URL의 host의 public suffix가 "localhost" 또는 "localhost."가 아님
    • request의 current URL의 host를 Known HSTS Host Domain Name Matching으로 매칭한 결과, includeSubDomains 지시가 있는 슈퍼도메인 매칭 또는 congruent 매칭(지시 유무 상관없이)임 [HSTS] 또는 요청의 DNS 조회로 section 9.5에서 명시한 HTTPS RR이 매칭됨 [HSTS] [SVCB]

    모든 DNS 동작은 일반적으로 구현 정의이므로, DNS 조회에 HTTPS RR이 포함되어 있는지 판단하는 방법 역시 구현 정의입니다. DNS 동작은 전통적으로 연결 얻기 시점까지 수행되지 않으므로, 사용자 에이전트는 더 일찍 DNS 동작을 수행하거나, 로컬 DNS 캐시를 참조하거나, fetch 알고리즘 내에서 더 늦게까지 기다렸다가 scheme 변경이 필요함을 발견해서 로직을 되돌릴 수도 있습니다.

11. recursive가 false이면, 남은 단계를 병렬로 실행한다.

12. response가 null이면, 다음에서 처음으로 일치하는 구문에 해당하는 단계를 실행한 결과를 response로 설정한다:

    fetchParams의 preloaded response candidate가 null이 아님

    1. fetchParams의 preloaded response candidate가 "pending"이 아닐 때까지 대기한다.

    2. Assert: fetchParams의 preloaded response candidate가 response임

    3. fetchParams의 preloaded response candidate를 반환한다.

    request의 current URL의 origin이 request의 origin과 same origin이고, request의 response tainting이 "basic"임

    request의 current URL의 scheme이 "data"임

    request의 mode가 "navigate", "websocket", 또는 "webtransport"인 경우

    1. request의 response tainting을 "basic"으로 설정한다.

    2. "scheme-fetch"와 fetchParams가 주어졌을 때 override fetch를 실행한 결과를 반환한다.

    HTML은 URL의 스킴이 "data"인 경우, 해당 문서와 워커에 고유한 불투명 출처(opaque origin)를 할당합니다. 서비스 워커는 URL의 스킴이 HTTP(S) 스킴인 경우에만 생성될 수 있습니다. [HTML] [SW]

    request의 mode가 "same-origin"임

    네트워크 에러를 반환한다.

    request의 mode가 "no-cors"임

    1. request의 redirect mode가 "follow"가 아니면, 네트워크 에러를 반환한다.

    2. request의 response tainting을 "opaque"로 설정한다.

    3. "scheme-fetch"와 fetchParams가 주어졌을 때 override fetch를 실행한 결과를 반환한다.

    request의 current URL의 scheme이 HTTP(S) scheme이 아니면

    네트워크 에러를 반환한다.

    request의 use-CORS-preflight flag가 설정됨

    request의 unsafe-request flag가 설정되어 있고, request의 method가 CORS-safelisted method가 아니거나, CORS-unsafe request-header names가 request의 header list에 비어있지 않음

    1. request의 response tainting을 "cors"로 설정한다.

    2. corsWithPreflightResponse를 "http-fetch", fetchParams, 그리고 true를 주어 override fetch를 실행한 결과로 설정한다.

    3. corsWithPreflightResponse가 네트워크 에러면, 캐시 엔트리 삭제를 request로 실행한다.

    4. corsWithPreflightResponse를 반환한다.

    그 외의 경우

    1. request의 response tainting을 "cors"로 설정한다.

    2. "http-fetch"와 fetchParams가 주어졌을 때 override fetch를 실행한 결과를 반환한다.

13. recursive가 true면 response를 반환한다.

14. response가 네트워크 에러가 아니고 response가 filtered response가 아니면:

    1. request의 response tainting이 "cors"이면:

       1. headerNames를 extracting header list values를 `Access-Control-Expose-Headers`와 response의 header list로 실행한 결과로 둔다.

       2. request의 credentials mode가 "include"가 아니고, headerNames가 `*`를 포함하면, response의 CORS-exposed header-name list를 response의 header list 내의 모든 고유 header name로 설정한다.

       3. 그 외에 headerNames가 null 또는 실패가 아니면, response의 CORS-exposed header-name list를 headerNames로 설정한다.

          headerNames 중 하나가 여전히 `*`일 수 있지만, 이는 header의 name이 `*`인 경우에만 일치한다.

    2. response를 filtered response로 설정한다. response를 내부 응답으로 두고, request의 response tainting에 따라 아래와 같이 한다:

       "basic"

       basic filtered response

       "cors"

       CORS filtered response

       "opaque"

       opaque filtered response

15. internalResponse를 response가 네트워크 에러일 경우 response로, 아니면 response의 internal response로 둔다.

16. internalResponse의 URL list가 비어 있으면, request의 URL list의 복제본으로 설정한다.

    response의 URL list는 비어 있을 수 있음 (예: about: URL fetch 시).

17. internalResponse의 redirect taint를 request의 redirect-taint로 설정한다.

18. request의 timing allow failed flag가 설정되어 있지 않으면, internalResponse의 timing allow passed flag를 설정한다.

19. response가 네트워크 에러가 아니고, 아래 중 하나라도 blocked를 반환하면

    • internalResponse가 request에 대해 혼합 콘텐츠로 차단되어야 하는지

    • internalResponse가 request에 대해 Content Security Policy로 차단되어야 하는지

    • internalResponse가 MIME 타입으로 인해 request에 대해 차단되어야 하는지

    • internalResponse가 nosniff로 인해 request에 대해 차단되어야 하는지

    이 경우 response와 internalResponse를 네트워크 에러로 설정한다.

20. response의 type이 "opaque"이고, internalResponse의 status가 범위 상태이며, internalResponse의 범위 요청 플래그가 설정되어 있고, request의 헤더 목록이 `Range`를 포함하지 않는 경우, response와 internalResponse를 네트워크 오류로 설정합니다.

    전통적으로 API는 범위가 요청되지 않았더라도 범위가 지정된 응답을 허용합니다. 이는 이전의 범위 요청으로부터의 부분 응답이나 범위를 만족할 수 없는 응답이 범위 요청을 하지 않은 API에 제공되는 것을 방지합니다.

    추가 세부 사항

    위 단계는 다음과 같은 공격을 방지합니다:

    미디어 요소가 교차 출처 HTML 리소스의 범위를 요청하는 데 사용됩니다. 이는 유효하지 않은 미디어이지만, 응답의 복제본에 대한 참조를 서비스 워커에 유지할 수 있습니다. 이후 이는 스크립트 요소의 fetch에 대한 응답으로 사용될 수 있습니다. 부분 응답이 유효한 JavaScript인 경우(전체 리소스는 그렇지 않더라도), 이를 실행하면 개인 데이터가 유출될 수 있습니다.

21. response가 네트워크 에러가 아니고, request의 method가 `HEAD` 또는 `CONNECT`이거나, internalResponse의 status가 null body status이면, internalResponse의 body를 null로 설정하고, 그에 대한 enqueuing은 무시한다.

    이것은 HTTP를 위반하는 서버에 대한 에러 처리를 표준화합니다.

22. request의 integrity metadata가 빈 문자열이 아니면:

    1. processBodyError를 다음 단계로 설정: fetch response handover를 fetchParams와 네트워크 에러로 실행한다.

    2. response의 body가 null이면, processBodyError를 실행하고, 이 단계를 중단한다.

    3. processBody를 bytes를 인자로 받아 다음 단계로 설정:

       1. bytes가 request의 integrity metadata와 일치하지 않으면, processBodyError를 실행하고, 이 단계를 중단한다. [SRI]

       2. response의 body를 bytes as a body로 설정한다.

       3. fetch response handover를 fetchParams와 response로 실행한다.

    4. body 완전 읽기를 response의 body, processBody와 processBodyError로 실행한다.

23. 그 외의 경우, fetch response handover를 fetchParams와 response로 실행한다.

fetch response handover는 fetch params fetchParams와 response response를 받아 다음 단계를 실행한다:

1. timingInfo를 fetchParams의 timing info로 둔다.

2. response가 네트워크 에러가 아니고, fetchParams의 request의 client가 secure context이면, timingInfo의 server-timing headers를 response의 internal response의 header list에서 `Server-Timing`을 get/decode/split한 결과로 설정한다.

   internal response를 사용하는 것은 `Server-Timing` 헤더 데이터 노출이 `Timing-Allow-Origin` 헤더로 보호되기 때문에 안전하다.

   사용자 에이전트는 `Server-Timing` 헤더를 non-secure context 요청에도 노출할 수 있다.

3. 만약 fetchParams의 request의 destination이 "document"라면, fetchParams의 controller의 full timing info를 fetchParams의 timing info로 설정한다.

4. processResponseEndOfBody를 다음 단계로 둔다:

   1. unsafeEndTime을 unsafe shared current time으로 둔다.

   2. fetchParams의 controller의 report timing steps를 global object global을 받아 다음 단계로 둔다:

      1. fetchParams의 request의 URL의 scheme이 HTTP(S) scheme이 아니면 return.

      2. timingInfo의 end time을 relative high resolution time으로, unsafeEndTime과 global을 인자로 설정한다.

      3. cacheState를 response의 cache state로 둔다.

      4. bodyInfo를 response의 body info로 둔다.

      5. response의 timing allow passed flag가 설정되어 있지 않으면, timingInfo를 opaque timing info 생성의 결과로 설정하고, cacheState를 빈 문자열로 설정한다.

         response가 네트워크 에러인 경우도 포함한다.

      6. responseStatus를 0으로 둔다.

      7. fetchParams의 request의 mode가 "navigate"가 아니거나 response의 redirect taint가 "same-origin"이면:

         1. responseStatus를 response의 status로 설정한다.

         2. mimeType을 response의 header list에서 extracting a MIME type의 결과로 둔다.

         3. mimeType이 실패가 아니면, bodyInfo의 content type을 minimizing a supported MIME type의 결과로 mimeType을 넘겨 설정한다.

      8. fetchParams의 request의 initiator type이 null이 아니면, mark resource timing을 timingInfo, fetchParams의 request의 URL, fetchParams의 request의 initiator type, global, cacheState, bodyInfo, responseStatus로 실행한다.

   3. processResponseEndOfBodyTask를 다음 단계로 설정한다:

      1. fetchParams의 request의 done flag를 설정한다.

      2. fetchParams의 process response end-of-body가 null이 아니면, fetchParams의 process response end-of-body를 response로 실행한다.

      3. fetchParams의 request의 initiator type이 null이 아니고, fetchParams의 request의 client의 global object가 fetchParams의 task destination이면, fetchParams의 controller의 report timing steps를 fetchParams의 request의 client의 global object로 실행한다.

   4. fetch task 큐에 넣기를 실행하여 processResponseEndOfBodyTask를 fetchParams의 task destination과 함께 실행한다.

5. fetchParams의 process response가 null이 아니면, fetch task 큐에 넣기를 실행하여 fetchParams의 process response를 response로, fetchParams의 task destination과 함께 실행한다.

6. internalResponse를 response가 네트워크 에러일 경우 response로, 아니면 response의 internal response로 둔다.

7. internalResponse의 body가 null이면, processResponseEndOfBody를 실행한다.

8. 그 외의 경우:

   1. transformStream을 새로운 TransformStream으로 둔다.

   2. identityTransformAlgorithm을 알고리즘으로 두고, chunk를 받아 transformStream에 enqueue한다.

   3. transformStream 설정을 실행하여, transformAlgorithm을 identityTransformAlgorithm으로, flushAlgorithm을 processResponseEndOfBody로 설정한다.

   4. internalResponse의 body의 stream을 internalResponse의 body의 stream을 transformStream에 파이프한 결과로 설정한다.

   이 TransformStream은 스트림이 끝에 도달할 때 알림을 받기 위해 필요하며, 그 외에는 identity transform stream이다.

9. fetchParams의 process response consume body가 null이 아니면:

   1. processBody를 nullOrBytes를 인자로 받아, fetchParams의 process response consume body를 response와 nullOrBytes로 실행하는 단계로 설정한다.

   2. processBodyError를 fetchParams의 process response consume body를 response와 failure로 실행하는 단계로 설정한다.

   3. internalResponse의 body가 null이면, fetch task 큐에 넣기를 실행하여 processBody를 null로 실행하고, fetchParams의 task destination과 함께 실행한다.

   4. 그 외에는, body 완전 읽기를 internalResponse의 body, processBody, processBodyError, fetchParams의 task destination로 실행한다.

override fetch는 "scheme-fetch" 또는 "http-fetch" type, fetch params fetchParams, 그리고 선택적 boolean makeCORSPreflight (기본값 false)를 입력으로 받는다:

1. request를 fetchParams의 request로 설정한다.

2. response를 request에 대해 potentially override response for a request를 실행한 결과로 설정한다.

3. response가 null이 아니면 response를 반환한다.

4. type에 따라 다음 단계 중 하나를 실행한다:

   "scheme fetch"

   response를 fetchParams를 입력으로 scheme fetch를 실행한 결과로 설정한다.

   "HTTP fetch"

   response를 fetchParams와 makeCORSPreflight를 입력으로 HTTP fetch를 실행한 결과로 설정한다.

5. response를 반환한다.

이 potentially override response for a request 알고리즘은 request request를 받아, response 또는 null을 반환한다. 그 동작은 implementation-defined, 사용자 에이전트가 request에 대해 응답을 직접 반환하여 개입하거나, null을 반환하여 요청이 계속 진행되도록 허용한다.

기본적으로 이 알고리즘은 다음과 같이 단순하게 구현된다:

1. null을 반환한다.

스킴 fetch는 fetch params fetchParams를 입력으로 받는다:

1. fetchParams가 취소됨이면, fetchParams에 대해 적절한 네트워크 오류를 반환한다.

2. request를 fetchParams의 request로 설정한다.

3. request의 current URL의 scheme에 따라 다음 단계를 실행한다:

   "about"

   request의 current URL의 path가 "blank" 문자열이면, response를 새로 만들어 반환한다. status message는 `OK`, header list는 « (`Content-Type`, `text/html;charset=utf-8`) », body는 빈 바이트 시퀀스를 body로 변환한 값이다.

   URL "about:config" 등은 네비게이션 처리 시 다루며, fetch 맥락에서는 네트워크 오류가 발생한다.

   "blob"

   1. blobURLEntry를 request의 current URL의 blob URL entry로 둔다.

   2. request의 method가 `GET`이 아니거나 blobURLEntry가 null이면, network error를 반환한다. [FILEAPI]

      `GET` method 제한은 상호 운용 가능하다는 것 외에는 유용한 목적을 제공하지 않는다.

   3. requestEnvironment를, request를 주어 environment를 결정한 결과로 둔다.

   4. isTopLevelSelfFetch를 false로 둔다.

   5. request의 client가 null이 아니면:

      1. global을 request의 client의 global object로 둔다.

      2. 다음 모든 조건이 참이면:

         • global은 Window 객체이다;

         • global의 navigable이 null이 아니다;

         • global의 navigable의 parent 가 null이다; 그리고

         • requestEnvironment의 creation URL이 equals로 request의 current URL과 같다,

         그러면 isTopLevelSelfFetch를 true로 설정한다.

   6. stringOrEnvironment를 다음 단계의 결과로 둔다:

      1. request의 destination이 "document"이면, "top-level-navigation"을 반환한다.

      2. isTopLevelSelfFetch가 true이면, "top-level-self-fetch"를 반환한다.

      3. requestEnvironment를 반환한다.

   7. blob을, blobURLEntry와 stringOrEnvironment를 주어 blob 객체를 얻는 결과로 둔다.

   8. blob이 Blob 객체가 아니면, network error를 반환한다.

   9. response를 새로운 response로 둔다.

   10. fullLength를 blob의 size로 둔다.

   11. serializedFullLength를 fullLength를 serialized하고 isomorphic encoded한 값으로 둔다.

   12. type을 blob의 type으로 둔다.

   13. request의 header list가 포함하지 않는다면 `Range`:

       1. bodyWithType를 safely extracting blob의 결과로 둔다.

       2. response의 status message를 `OK`로 설정한다.

       3. response의 body를 bodyWithType의 body로 설정한다.

       4. response의 header list를 « (`Content-Length`, serializedFullLength), (`Content-Type`, type) »로 설정한다.

   14. 그 외의 경우:

       1. response의 range-requested flag를 설정한다.

       2. rangeHeader를, request의 header list에서 `Range`를 getting한 결과로 둔다.

       3. rangeValue를, rangeHeader와 true를 주어 parsing a single range header value의 결과로 둔다.

       4. rangeValue가 failure이면, network error를 반환한다.

       5. (rangeStart, rangeEnd)를 rangeValue로 둔다.

       6. rangeStart가 null이면:

          1. rangeStart를 fullLength − rangeEnd로 설정한다.

          2. rangeEnd를 rangeStart + rangeEnd − 1로 설정한다.

       7. 그 외의 경우:

          1. rangeStart가 fullLength 이상이면, network error를 반환한다.

          2. rangeEnd가 null이거나 rangeEnd가 fullLength 이상이면, rangeEnd를 fullLength − 1로 설정한다.

       8. slicedBlob을, blob, rangeStart, rangeEnd + 1, 그리고 type을 주어 slice blob을 호출한 결과로 둔다.

          range 헤더는 포함(inclusive)된 바이트 범위를 나타내지만, slice blob 알고리즘의 입력 범위는 그렇지 않다. slice blob 알고리즘을 사용하려면 rangeEnd를 증가시켜야 한다.

       9. slicedBodyWithType를 safely extracting slicedBlob의 결과로 둔다.

       10. response의 body를 slicedBodyWithType의 body로 설정한다.

       11. serializedSlicedLength를 slicedBlob의 size를 serialized하고 isomorphic encoded한 값으로 둔다.

       12. contentRange를, rangeStart, rangeEnd, fullLength를 주어 build a content range를 호출한 결과로 둔다.

       13. response의 status를 206으로 설정한다.

       14. response의 status message를 `Partial Content`로 설정한다.

       15. response의 header list를 « (`Content-Length`, serializedSlicedLength), (`Content-Type`, type), (`Content-Range`, contentRange) »로 설정한다.

   15. response를 반환한다.

   "data"

   1. dataURLStruct를, request의 current URL에 대해 data: URL 처리기를 실행한 결과로 둔다.

   2. dataURLStruct가 failure이면, network error를 반환한다.

   3. mimeType을 dataURLStruct의 MIME type을 직렬화한 값으로 둔다.

   4. 새로운 response를 반환하는데, 그 status message는 `OK`이고, header list는 « (`Content-Type`, mimeType) »이며, body 는 dataURLStruct의 body를 body로서 사용한 것이다.

   "file"

   현재로서는 아쉽지만, file: URLs 는 독자를 위한 연습 문제로 남겨둔다.

   확신이 서지 않으면, network error를 반환한다.

   HTTP(S) 스킴

   fetchParams를 주어 HTTP fetch를 실행한 결과를 반환한다.

4. network error를 반환한다.

환경 결정하기는 request request를 입력으로 받는다:

1. request의 reserved client가 null이 아니면, request의 reserved client를 반환한다.

2. request의 client가 null이 아니면, request의 client를 반환한다.

3. null을 반환한다.

HTTP fetch는 fetch params fetchParams와 선택적 boolean makeCORSPreflight (기본값 false)를 입력으로 받아, 다음 단계들을 실행한다:

1. request를 fetchParams의 request로 설정한다.

2. response와 internalResponse를 null로 설정한다.

3. request의 service-workers mode가 "all"이면:

   1. requestForServiceWorker를 request의 clone으로 설정한다.

   2. requestForServiceWorker의 body가 null이 아니면:

      1. transformStream을 새로운 TransformStream 객체로 설정한다.

      2. transformAlgorithm을 chunk을 입력으로 아래 단계로 정의한다:

         1. fetchParams가 취소됨이면, 이 단계를 중지한다.

         2. chunk가 Uint8Array 객체가 아니면 terminate를 fetchParams의 controller에 적용한다.

         3. 그 외의 경우, enqueue를 사용해 chunk를 transformStream에 넣는다. 사용자 에이전트는 chunk를 구현 정의의 적절한 크기로 분할하여 각각 enqueue하거나, chunk들을 구현 정의의 적절한 크기로 결합하여 enqueue할 수 있다.

      3. Set up을 사용해 transformStream을 transformAlgorithm이 transformAlgorithm이 되도록 설정한다.

      4. requestForServiceWorker의 body의 stream을 requestForServiceWorker의 body의 stream을 pipeThrough로 transformStream에 연결한 결과로 설정한다.

   3. serviceWorkerStartTime을 coarsened shared current time을 fetchParams의 cross-origin isolated capability로 실행한 결과로 설정한다.

   4. fetchResponse를 handle fetch에 requestForServiceWorker, fetchParams의 controller 및 fetchParams의 cross-origin isolated capability와 함께 호출한 결과로 설정한다. [HTML] [SW]

   5. 만약 fetchResponse가 response라면:

      1. response를 fetchResponse로 설정한다.

      2. fetchParams의 timing info의 final service worker start time을 serviceWorkerStartTime으로 설정한다.

      3. fetchParams의 timing info의 service worker timing info를 response의 service worker timing info로 설정한다.

      4. request의 body가 null이 아니라면, cancel request의 body를 undefined와 함께 호출한다.

      5. internalResponse를 response로, 만약 response가 filtered response가 아니라면 response로; 그렇지 않으면 response의 internal response로 설정한다.

      6. 다음 조건 중 하나라도 만족하면

         • response의 type이 "error"인 경우

         • request의 mode가 "same-origin"이고, response의 type이 "cors"인 경우

         • request의 mode가 "no-cors"가 아니고, response의 type이 "opaque"인 경우

         • request의 redirect mode가 "manual"이 아니고, response의 type이 "opaqueredirect"인 경우
         • request의 redirect mode가 "follow"가 아니고, response의 URL list에 항목이 두 개 이상 있는 경우

         이 경우 network error를 반환한다.

   6. 그 밖에, fetchResponse가 service worker timing info라면, fetchParams의 timing info의 service worker timing info를 fetchResponse로 설정한다.

4. response가 null이면:

   1. makeCORSPreflight이 true이고 다음 조건 중 하나라도 참이면:

      • request의 method에 대해 method cache entry match가 없고, request의 method가 CORS-safelisted method가 아니거나 request의 use-CORS-preflight flag가 설정된 경우

      • request의 header list에서 CORS-unsafe request-header names 중 header-name cache entry match가 없는 항목이 하나 이상 있을 때

      그렇다면:

      1. preflightResponse를 CORS-프리플라이트 fetch를 request에 대해 실행한 결과로 설정한다.

      2. preflightResponse가 network error이면 preflightResponse를 반환한다.

      이 단계는 CORS-프리플라이트 캐시를 확인하고 적절한 엔트리가 없으면 CORS-프리플라이트 fetch를 수행하며, 성공 시 캐시를 채운다. CORS-프리플라이트 fetch의 목적은 fetch 리소스가 CORS 프로토콜을 인지하고 있음을 보장하는 데 있다. 캐시는 CORS-프리플라이트 fetch 횟수를 최소화하기 위해 존재한다.

   2. request의 redirect mode가 "follow"이면, request의 service-workers mode를 "none"으로 설정한다.

      네트워크에서 발생한 리다이렉트는(서비스 워커로부터 발생한 것이 아닌 경우) 서비스 워커에 노출되어서는 안 된다.

   3. response와 internalResponse를 HTTP-네트워크-또는-캐시 fetch를 fetchParams에 대해 실행한 결과로 설정한다.

   4. request의 response tainting가 "cors"이고 CORS 체크를 request와 response에 대해 실행한 결과가 실패이면, network error를 반환한다.

      response의 status가 304 또는 407인 경우, 혹은 서비스 워커에서 온 response의 경우 CORS 검사가 적용되지 않으므로, 이 곳에서 적용된다.

   5. TAO 체크를 request와 response에 대해 실행한 결과가 실패이면, request의 timing allow failed flag를 설정한다.

5. request의 response tainting 또는 response의 type이 "opaque"이고, cross-origin resource policy check를 request의 origin, request의 client, request의 destination, 그리고 internalResponse로 수행한 결과가 blocked를 반환하면, network error를 반환한다.

   cross-origin resource policy check는 네트워크에서 오는 응답과 서비스 워커에서 오는 응답 모두에 대해 실행된다. 이는 CORS check와는 다른데, request의 client와 서비스 워커가 서로 다른 임베더 정책을 가질 수 있기 때문이다.

6. internalResponse의 status가 redirect status이면:

   1. internalResponse의 status가 303이 아니고 request의 body가 null이 아니며 connection이 HTTP/2를 사용하는 경우, 사용자 에이전트는 RST_STREAM 프레임을 전송해도 된다(권장됨).

      303은 일부 커뮤니티에서 특별한 의미를 가지므로 제외된다.

   2. request의 redirect mode에 따라 다음 단계 실행:

      "error"

      1. response를 network error로 설정한다.

      "manual"

      1. request의 mode가 "navigate"이면, fetchParams의 controller의 next manual redirect steps를 HTTP-리다이렉트 fetch를 fetchParams와 response로 실행하는 것으로 설정한다.

      2. 그 외의 경우, response를 opaque-redirect filtered response로 설정하고 internal response는 internalResponse로 한다.

      "follow"

      1. response를 HTTP-리다이렉트 fetch를 fetchParams와 response로 실행한 결과로 설정한다.

7. response를 반환한다. 일반적으로 internalResponse의 body의 stream은 반환 후에도 계속 enqueue된다.