패치

특정 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으로 큐잉합니다.

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 헤더 추가를 통해 설정할 수 있습니다.

복제(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]

redirect-taint를 request request에 대해 계산하려면 다음 단계를 따른다. 반환값은 "same-origin", "same-site", "cross-site" 중 하나이다.

1. Assert: request의 origin이 "client"가 아님을 확인한다.

2. lastURL을 null로 둔다.

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

4. 각 request의 URL 목록의 url에 대해:

   1. lastURL이 null이면 lastURL을 url로 설정하고 continue한다.

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

   3. url의 origin이 lastURL의 origin과 same origin이 아니고, request의 origin이 lastURL의 origin과 same origin이 아니면, taint를 "same-site"로 설정한다.

   4. lastURL을 url로 설정한다.

5. taint를 반환한다.

요청 origin 직렬화(Serializing a request origin)는 request request가 주어졌을 때 다음을 실행한다:

1. Assert: request의 origin이 "client"가 아님을 확인한다.

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

3. request의 origin을 ascii 직렬화하여 반환한다.

요청 origin 바이트 직렬화(Byte-serializing a request origin)는 request request가 주어졌을 때, 요청 origin 직렬화의 결과를 등가 인코딩(isomorphic encoded)하여 반환한다.

복제(clone)를 request request에 대해 실행하려면 다음을 따른다:

1. newRequest를 request의 복사본(단, body는 제외)으로 둔다.

2. request의 body가 null이 아니면, newRequest의 body를 clone request의 body 결과로 설정한다.

3. newRequest를 반환한다.

range 헤더 추가(add a range header)를 request request에, 정수 first와 옵션 정수 last와 함께 하려면 다음을 따른다:

1. Assert: last가 주어졌다면, first가 last 이하임을 확인한다.

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

3. 직렬화 및 등가 인코딩한 first를 rangeValue에 추가한다.

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

5. last가 주어졌다면, 직렬화 및 등가 인코딩하여 rangeValue에 추가한다.

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

range 헤더는 양끝 포함 바이트 범위를 나타낸다. 즉, first가 0이고 last가 500이면 501 바이트 범위다.

여러 응답을 하나의 논리 리소스로 결합하는 기능은 역사적으로 보안 버그의 원인이었다. 부분 응답을 다루는 기능을 설계할 때는 반드시 보안 리뷰를 받을 것.

보고용 응답 URL 직렬화(serialize a response URL for reporting)는 response response에 대해 다음을 실행한다:

1. Assert: response의 URL list가 비어있지 않음을 확인한다.

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

   이는 response의 URL이 아니다. 리다이렉트 대상 정보 노출을 피하기 위함(이와 유사한 CSP 보고에 대한 고려도 참고). [CSP]

3. username 설정을 url과 빈 문자열로 실행한다.

4. password 설정을 url과 빈 문자열로 실행한다.

5. 직렬화(serialization)를 url에 대해(단, fragment 제외 옵션 포함) 반환한다.

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의 value가 "credentialless"가 아니면 true를 반환한다.

5. request의 origin이 request의 current URL의 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) 알고리즘은 네트워크 파티션 키 key, URL url, 불리언 credentials, 옵션 new connection setting new (기본값 "no"), 옵션 불리언 requireUnreliable (기본값 false)로 호출한다:

1. new가 "no"면:

   1. connections를 연결 풀에서 key가 key, origin이 url의 origin, credentials가 credentials인 connection 집합으로 한다.

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

   3. connections 중에서 불안정 전송(unreliable transport, 예: HTTP/3)을 지원하는 connection이 있으면 그것을 반환한다.

2. proxies를 url에 대한 프록시를 구현 정의 방식으로 찾은 결과로 한다. 프록시가 없으면 proxies는 « "DIRECT" »가 된다.

   이 단계에서는 Web Proxy Auto-Discovery Protocol(WPAD)이나 proxy auto-config(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를 resolve an origin 알고리즘에 key와 url의 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, 구현 정의 host (from hosts), timingInfo, requireUnreliable를 넘겨서, 여러 번 병렬로 실행하고 하나 이상이 성공할 때까지 기다린다. 구현 정의 방식으로 반환값 하나를 선택해 반환한다. 나머지 connection들은 닫을 수 있다.

      즉, 구현체는 IP 주소 여러 개를 pick & race 하거나, IPv6를 우선하거나, 타임아웃 시 재시도하는 등 다양한 전략을 쓸 수 있다.

   7. connection이 failure면 continue한다.

   8. new가 "yes-and-dedicated"가 아니면 append로 connection을 연결 풀에 추가한다.

   9. connection을 반환한다.

5. failure를 반환한다.

이 부분은 의도적으로 다소 모호하게 작성되어 있는데, 연결 관리에는 구현자 재량에 맡기는 것이 더 적합한 많은 미묘한 점들이 있기 때문이다. 이렇게 설명하는 것은 <link rel=preconnect> 기능을 설명하고, 연결이 인증 정보(credentials)를 기준으로 구분된다는 점을 명확히 하기 위함이다. 후자는 예를 들어, TLS 세션 식별자가 연결 중 인증 정보(credentials)가 false인 것과 연결 중 인증 정보(credentials)가 true인 것 사이에 재사용되지 않는다는 점을 명확히 한다.

연결 생성(create a connection) 알고리즘은 네트워크 파티션 키 key, origin origin, 불리언 credentials, 문자열 proxy, host host, connection timing info timingInfo, 불리언 requireUnreliable이 주어졌을 때 다음을 실행한다:

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

2. connection을 새 connection으로 만들고, key는 key, origin은 origin, credentials는 credentials, timing info는 timingInfo로 한다. record connection timing info를 connection에 대해 실행하고, connection을 이용해 host에 HTTP 연결을 수립한다(프록시, origin을 고려). 단, 아래 주의사항에 유의: [HTTP] [HTTP1] [TLS]

   • requireUnreliable가 true면 불안정 전송(예: HTTP/3) 가능한 연결만 수립한다. [HTTP3]

   • 불안정 전송 연결을 수립할 때 WebTransport에 필요한 옵션을 활성화한다. HTTP/3의 경우, 초기 SETTINGS 프레임에 SETTINGS_ENABLE_WEBTRANSPORT=1, H3_DATAGRAM=1을 포함한다. [WEBTRANSPORT-HTTP3] [HTTP3-DATAGRAM]

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

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

3. timingInfo의 ALPN negotiated protocol을 connection의 ALPN Protocol ID로 설정한다. 단, 아래 주의사항에 유의: [RFC7301]

   • 프록시를 사용할 경우, 터널 연결이 성립하면 해당 터널링 프로토콜의 ALPN Protocol ID로, 아니면 프록시까지의 첫 홉의 ALPN Protocol ID로 설정한다.

   • 실험적·비공식 프로토콜을 쓰면, 실제 사용된 ALPN Protocol ID를 사용해야 한다. ALPN이 협상에 사용되지 않았다면 다른 설명 문자열을 써도 된다.

     timingInfo의 ALPN negotiated protocol은 네트워크 프로토콜을 식별하기 위한 정보이며, ALPN이 협상에 쓰이지 않아도 실제 사용 프로토콜의 ALPN ID를 써야 한다.

   ALPN Protocol ID 목록은 IANA에서 관리한다. ALPN Protocol IDs 참고.

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에 대해 실행한 결과로 둔다.

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

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

request request에 대해 나쁜 포트(bad port)로 인해 차단되어야 하는지 여부를 결정하려면:

1. url을 request의 current URL로 둔다.

2. url의 scheme이 HTTP(S) scheme이고, 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를 same-site 모드 결정 알고리즘을 request에 대해 실행한 결과로 둔다.

3. isSecure는 request의 current URL의 scheme이 "https"이면 true, 아니면 false로 둔다.

4. httpOnlyAllowed를 true로 둔다.

   이는 fetch에서 호출되었기 때문에 true다. (예: document.cookie getter에서는 다를 수 있음)

5. cookies를 retrieve cookies 알고리즘에 isSecure, request의 current URL의 host, request의 current URL의 path, httpOnlyAllowed, sameSite를 넘겨 호출한 결과로 둔다.

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

6. cookies가 비어있으면 리턴한다.

7. value를 serialize cookies 알고리즘에 cookies를 넘겨 실행한 결과로 둔다.

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

응답 `Set-Cookie` 헤더 파싱 및 저장(parse and store response `Set-Cookie` headers) 알고리즘은 request request와 response response가 주어졌을 때 다음을 따른다:

1. 사용자 에이전트가 request에 대해 쿠키를 비활성화하도록 설정되어 있다면 리턴한다.

2. allowNonHostOnlyCookieForPublicSuffix를 false로 둔다.

3. isSecure를 request의 current URL의 scheme이 "https"이면 true, 아니면 false로 둔다.

4. httpOnlyAllowed를 true로 둔다.

   이는 fetch에서 호출되어 true임(document.cookie getter 등에서는 다름).

5. sameSiteStrictOrLaxAllowed를 same-site 모드 결정 알고리즘이 request에 대해 "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의 current URL의 host, request의 current URL의 path, httpOnlyAllowed, allowNonHostOnlyCookieForPublicSuffix, sameSiteStrictOrLaxAllowed를 넘겨 실행한다.

   3. Garbage collect cookies 알고리즘에 request의 current URL의 host를 넘겨 실행한다.

   `Set-Cookie` 헤더는 병합될 수 없으므로 각각 독립적으로 처리된다. 이는 다른 어떤 헤더에도 허용되지 않는다.

same-site 모드 결정(determine the same-site mode) 알고리즘은 request request에 대해 다음을 따른다:

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의 has cross-site ancestor가 true라면, "unset-or-less"를 반환한다.

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

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

요청 `Origin` 헤더 추가(append a request `Origin` header) 알고리즘은 request request가 주어졌을 때 다음을 실행한다:

1. Assert: request의 origin이 "client"가 아님을 확인한다.

2. serializedOrigin을 요청 origin의 바이트 직렬화 알고리즘을 request에 대해 실행한 결과로 둔다.

3. request의 response tainting이 "cors"이거나, request의 mode가 "websocket"이면, append (`Origin`, serializedOrigin)을 request의 header list에 추가한다.

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

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

      "no-referrer"

      serializedOrigin을 `null`로 설정한다.

      "no-referrer-when-downgrade"

      "strict-origin"

      "strict-origin-when-cross-origin"

      request의 origin이 tuple origin이고, 그 scheme이 "https"이며, request의 current URL의 scheme이 "https"가 아니면, serializedOrigin을 `null`로 설정한다.

      "same-origin"

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

      그 외

      아무것도 하지 않는다.

   2. append (`Origin`, serializedOrigin)을 request의 header list에 추가한다.

request의 referrer policy는 fetcher가 서버와 origin을 명시적으로 공유하도록 설정하지 않은 모든 fetch에 대해 고려된다(예: CORS 프로토콜 사용 등).

길이 추출(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을 반환한다.

nosniff 결정(determine nosniff) 알고리즘은 header list list가 주어졌을 때 다음을 따른다:

1. values를 getting, decoding, and splitting(`X-Content-Type-Options`)을 list에 대해 실행한 결과로 둔다.

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

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

4. false를 반환한다.

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

다음 단계를 실행한다:

1. nosniff 결정을 response의 header list에 대해 실행한 결과가 false라면 allowed를 반환한다.

2. mimeType을 response의 header list에서 MIME 타입 추출 알고리즘을 실행한 결과로 둔다.

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

4. destination이 script-like이고, mimeType이 failure이거나 JavaScript MIME 타입이 아니면 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. 교차 출처 리소스 정책 내부 검사를 origin, "unsafe-none", response, forNavigation에 대해 실행해 blocked를 반환하면 blocked를 반환한다.

   이 단계는 아래에서 Cross-Origin Embedder Policy에 관련 없는 위반을 보고하지 않기 위해 필요하다.

4. 교차 출처 리소스 정책 내부 검사를 origin, embedderPolicy의 report only value, response, forNavigation에 대해 실행해 blocked를 반환하면 교차 출처 임베더 정책 CORP 위반 리포트 큐잉을 response, settingsObject, destination, true로 실행한다.

5. 교차 출처 리소스 정책 내부 검사를 origin, embedderPolicy의 value, response, forNavigation에 대해 실행해 allowed를 반환하면 allowed를 반환한다.

6. 교차 출처 임베더 정책 CORP 위반 리포트 큐잉을 response, settingsObject, destination, false로 실행한다.

7. blocked를 반환한다.

HTML의 navigate 알고리즘만 forNavigation이 true로 이 검사를 사용하며, 항상 중첩 내비게이션에만 해당된다. 그 외에는 response가 internal response (또는 opaque filtered response의 internal response)이거나, response가 곧 internal response가 될 것이다. [HTML]

교차 출처 리소스 정책 내부 검사(cross-origin resource policy internal check) 알고리즘은 origin origin, embedder policy value embedderPolicyValue, response response, 불린 forNavigation이 주어졌을 때 다음을 수행한다:

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

2. policy를 getting(`Cross-Origin-Resource-Policy`)을 response의 header list에 대해 실행한 결과로 둔다.

   즉, `Cross-Origin-Resource-Policy: same-site, same-origin`은 아래에서 어떤 것도 일치하지 않으므로 항상 allowed가 된다. embedderPolicyValue가 "unsafe-none"일 때는 두 개 이상의 `Cross-Origin-Resource-Policy` 헤더도 동일하게 취급된다.

3. policy가 `same-origin`, `same-site`, `cross-origin` 중 어느 것도 아니면 policy를 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`

   다음 모두가 true이면

   • origin이 schemelessly same site라면 response의 URL의 origin

   • origin의 scheme이 "https"이거나, response의 URL의 scheme이 "https"가 아닌 경우

   그렇다면 allowed를 반환한다.

   그 외에는 blocked를 반환한다.

   `Cross-Origin-Resource-Policy: same-site`는 안전한 전송(https)으로 전달된 응답을 비안전한 요청(origin)과 일치시키지 않는다. 즉, secure로 전송된 응답은 secure로 시작한 initiator와만 일치한다.

교차 출처 임베더 정책 CORP 위반 리포트 큐잉(queue a cross-origin embedder policy CORP violation report) 알고리즘은 response response, environment settings object settingsObject, 문자열 destination, 불린 reportOnly가 주어졌을 때 다음을 수행한다:

1. endpoint를 reportOnly가 true이면 settingsObject의 policy container의 embedder policy의 report only reporting endpoint로, 그렇지 않으면 settingsObject의 policy container의 embedder policy의 reporting endpoint로 둔다.

2. serializedURL을 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 request, 선택적 알고리즘 processRequestBodyChunkLength, 선택적 알고리즘 processRequestEndOfBody, 선택적 알고리즘 processEarlyHintsResponse, 선택적 알고리즘 processResponse, 선택적 알고리즘 processResponseEndOfBody, 선택적 알고리즘 processResponseConsumeBody, 선택적 불리언 useParallelQueue (기본값 false)를 받아, 아래 단계를 수행합니다. processRequestBodyChunkLength가 주어질 경우, 전송된 바이트 수를 나타내는 정수를 받는 알고리즘이어야 합니다. processRequestEndOfBody가 주어질 경우, 인수를 받지 않는 알고리즘이어야 합니다. processEarlyHintsResponse가 주어질 경우, response를 받는 알고리즘이어야 합니다. processResponse가 주어질 경우, response를 받는 알고리즘이어야 합니다. processResponseEndOfBody가 주어질 경우, response를 받는 알고리즘이어야 합니다. processResponseConsumeBody가 주어질 경우, response와 null, 실패 또는 byte sequence를 받는 알고리즘이어야 합니다.

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

사용자 에이전트는 request의 캐시 모드가 "no-store"이거나 응답에 `Cache-Control: no-store` 헤더가 포함된 경우, HTTP 캐시의 항목을 업데이트하지 않습니다. [HTTP-CACHING]

1. Assert: request의 mode가 "navigate"이거나 processEarlyHintsResponse가 null이어야 한다.

   초기 힌트(status가 103인 응답) 처리는 내비게이션에 대해서만 검증됩니다.

2. taskDestination을 null로 둔다.

3. crossOriginIsolatedCapability를 false로 둔다.

4. 클라이언트로부터 요청 채우기를 request에 대해 실행한다.

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

   1. taskDestination을 request의 client의 global object로 설정한다.

   2. crossOriginIsolatedCapability를 request의 client의 cross-origin isolated capability로 설정한다.

6. useParallelQueue가 true라면, taskDestination을 새로운 병렬 큐 시작의 결과로 설정한다.

7. timingInfo를 fetch timing info의 새 인스턴스로 두고, start time과 post-redirect start time을 coarsened shared current time에 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의 body가 byte sequence라면, request의 body를 request의 body as a body로 설정한다.

10. 다음 조건이 모두 true라면:

    • request의 URL의 scheme가 HTTP(S) scheme임

    • request의 mode가 "same-origin", "cors", "no-cors" 중 하나임

    • request의 client가 null이 아니고, request의 client의 global object가 Window 객체임

    • request의 method가 `GET`임

    • request의 unsafe-request flag가 설정되지 않았거나, request의 header list가 비어 있음

    이 경우:

    1. Assert: request의 origin이 request의 client의 same origin임

    2. onPreloadedResponseAvailable을 다음 알고리즘으로 설정: response response를 받아, fetchParams의 preloaded response candidate에 response를 할당함

    3. foundPreloadedResource를 preloaded resource 소비의 결과로 설정함: request의 client, request의 URL, request의 destination, request의 mode, request의 credentials mode, request의 integrity metadata, onPreloadedResponseAvailable

    4. foundPreloadedResource가 true이고 fetchParams의 preloaded response candidate가 null이면, fetchParams의 preloaded response candidate를 "pending"으로 설정함

11. request의 header list에 `Accept`가 포함되어 있지 않으면:

    1. value를 `*/*`로 설정

    2. request의 initiator가 "prefetch"이면, value를 document `Accept` header value로 설정

    3. 그 외에는, 사용자 에이전트는 request의 destination에 따라 아래와 같이 value를 설정해야 함:

       "document"

       "frame"

       "iframe"

       document `Accept` header value

       "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의 header list에 추가한다.

12. request의 header list에 `Accept-Language`가 포함되어 있지 않으면, 사용자 에이전트는 append (`Accept-Language, 적절한 header value)를 request의 header list에 추가한다.

13. request의 internal priority가 null이면, request의 priority, initiator, destination, render-blocking을 사용하여 구현 정의 방식으로 request의 internal priority를 구현 정의 객체로 설정한다.

    구현 정의 객체에는 HTTP/2의 스트림 가중치 및 의존성, HTTP용 확장 우선순위 스킴(Extensible Prioritization Scheme for HTTP)에서 사용하는 우선순위 정보(HTTP/3 등 해당 전송 포함), HTTP/1 fetch의 디스패치 및 처리 우선순위를 위한 동등한 정보가 포함될 수 있습니다. [RFC9218]

14. request가 하위 리소스 요청이면:

    1. record를 새 fetch record로 두고, request는 request, controller는 fetchParams의 controller로 설정한다.

    2. Append record를 request의 client의 fetch group의 fetch records에 추가함

15. main fetch를 fetchParams로 실행한다.

16. fetchParams의 controller를 반환함

클라이언트로부터 요청 채우기를 실행하려면, request request를 받아:

1. request의 traversable for user prompts가 "client"이면:

   1. request의 traversable for user prompts를 "no-traversable"로 설정함

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

      1. global을 request의 client의 global object로 설정

      2. global이 Window 객체이고 global의 navigable이 null이 아니면, request의 traversable for user prompts를 global의 navigable의 traversable navigable로 설정

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

   1. Assert: request의 client가 null이 아님

   2. request의 origin을 request의 client의 origin으로 설정함

3. request의 policy container가 "client"이면:

   1. request의 client가 null이 아니면, request의 policy container를 request의 client의 policy container의 복제본으로 설정함 [HTML]

   2. 그 외에는, request의 policy container를 새 policy container로 설정함

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"임

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

    2. scheme fetch를 fetchParams로 실행한 결과를 반환한다.

    HTML은 URL의 scheme이 "data"인 경우, 생성된 문서 및 워커에 고유 불투명 origin을 할당한다. Service worker는 URL의 scheme이 HTTP(S) scheme인 경우에만 생성 가능하다. [HTML] [SW]

    request의 mode가 "same-origin"임

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

    request의 mode가 "no-cors"임

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

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

    3. scheme fetch를 fetchParams로 실행한 결과를 반환한다.

    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로 실행한 결과로 둔다.

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

    4. corsWithPreflightResponse를 반환한다.

    그 외의 경우

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

    2. HTTP fetch를 fetchParams로 실행한 결과를 반환한다.

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가 206, internalResponse의 range-requested flag가 설정되어 있고, request의 header list에 `Range`가 포함되어 있지 않으면, response와 internalResponse를 네트워크 에러로 설정한다.

    전통적으로, API는 range를 요청하지 않아도 range 응답을 허용했습니다. 이는 이전 range 요청의 부분 응답이 range 요청을 하지 않은 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로 실행한다.

스킴 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는 빈 바이트 시퀀스 as a body로 설정하여 반환한다.

   URL 중 "about:config" 등은 탐색 중 처리되며, fetching에서는 네트워크 에러가 된다.

   "blob"

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

   2. request의 method가 `GET`가 아니거나, blobURLEntry가 null이면, 네트워크 에러를 반환한다. [FILEAPI]

      `GET` method 제한은 상호 운용성 이외에 특별한 목적 없음.

   3. requestEnvironment를 determine the environment를 request로 실행한 결과로 둔다.

   4. isTopLevelNavigation을 request의 destination이 "document"이면 true, 아니면 false로 둔다.

   5. isTopLevelNavigation이 false이고 requestEnvironment가 null이면, 네트워크 에러를 반환한다.

   6. navigationOrEnvironment를 isTopLevelNavigation이 true면 "navigation", 아니면 requestEnvironment로 둔다.

   7. blob을 blob 객체 가져오기를 blobURLEntry와 navigationOrEnvironment로 실행한 결과로 둔다.

   8. blob이 Blob 객체가 아니면, 네트워크 에러를 반환한다.

   9. response를 새 response로 둔다.

   10. fullLength를 blob의 size로 둔다.

   11. serializedFullLength를 fullLength를 serialize하고 isomorphic encode한 결과로 둔다.

   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를 get을 `Range`와 request의 header list로 실행한 결과로 둔다.

       3. rangeValue를 parsing a single range header value를 rangeHeader와 true로 실행한 결과로 둔다.

       4. rangeValue가 실패면, 네트워크 에러를 반환한다.

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

       6. rangeStart가 null이면:

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

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

       7. 그 외의 경우:

          1. rangeStart가 fullLength 이상이면, 네트워크 에러를 반환한다.

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

       8. slicedBlob을 slice blob을 blob, rangeStart, rangeEnd + 1, type으로 실행한 결과로 둔다.

          Range 헤더는 바이트 범위를 포함하지만, slice blob 알고리즘은 그렇지 않으므로 rangeEnd를 1 증가시켜야 한다.

       9. slicedBodyWithType을 safely extracting을 slicedBlob으로 실행한 결과로 둔다.

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

       11. serializedSlicedLength를 slicedBlob의 size를 serialize하고 isomorphic encode한 결과로 둔다.

       12. contentRange를 build a content range를 rangeStart, rangeEnd, fullLength로 실행한 결과로 둔다.

       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를 data: URL processor를 request의 current URL로 실행한 결과로 둔다.

   2. dataURLStruct가 실패면, 네트워크 에러를 반환한다.

   3. mimeType을 dataURLStruct의 MIME type을 serialize한 결과로 둔다.

   4. 새 response를 생성하여, status message는 `OK`, header list는 « (`Content-Type`, mimeType) », body는 dataURLStruct의 body를 as a body로 설정하여 반환한다.

   "file"

   현재로서는 아쉽게도 file: URL은 독자의 몫으로 남겨둔다.

   의심스러울 경우, 네트워크 에러를 반환한다.

   HTTP(S) scheme

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

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

환경 결정을 실행하려면, request request를 받아:

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

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

3. null을 반환한다.

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

1. request를 fetchParams의 request로 둔다.

2. response와 internalResponse를 null로 둔다.

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

   1. requestForServiceWorker를 request의 복제본으로 둔다.

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

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

      2. transformAlgorithm을 chunk를 받아 다음 단계로 설정한다:

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

         2. chunk가 Uint8Array 객체가 아니면, 종료를 fetchParams의 controller에 대해 실행한다.

         3. 그 외에는 enqueue chunk를 transformStream에 넣는다. 사용자 에이전트는 chunk를 구현 정의 실제 크기로 나누어 각각 enqueue 할 수 있다. 또한 여러 chunk를 구현 정의 실제 크기로 합쳐 enqueue할 수 있다.

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

      4. requestForServiceWorker의 body의 stream을 requestForServiceWorker의 body의 stream을 파이프한 결과로 둔다.

   3. serviceWorkerStartTime을 coarsened shared current time으로, fetchParams의 cross-origin isolated capability를 인자로 설정한다.

   4. response를 handle fetch를 requestForServiceWorker, fetchParams의 controller, fetchParams의 cross-origin isolated capability로 실행한 결과로 둔다.

   5. response가 null이 아니면:

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

      2. request의 body가 null이 아니면, cancel request의 body를 undefined로 실행한다.

      3. internalResponse를 response가 filtered response가 아니면 response로, 아니면 response의 internal response로 설정한다.

      4. 다음 중 하나라도 true이면

         • 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가 한 개를 초과함

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

4. response가 null이면:

   1. makeCORSPreflight가 true이고 다음 중 하나라도 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에 item이 하나라도 있고, 해당 header-name cache entry match가 존재하지 않음

      이 경우:

      1. preflightResponse를 CORS-preflight fetch를 request로 실행한 결과로 둔다.

      2. preflightResponse가 네트워크 에러이면 preflightResponse를 반환한다.

      이 단계는 CORS-preflight cache를 확인하고 적절한 엔트리가 없으면 CORS-preflight fetch를 실행한다. 성공하면 캐시에 저장한다. CORS-preflight fetch의 목적은 가져온 리소스가 CORS 프로토콜을 인식하는지 확인하는 것이다. 캐시는 CORS-preflight fetch의 횟수를 최소화한다.

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

      네트워크에서 발생한 리다이렉트(서비스 워커에서 발생한 것이 아닌)는 서비스 워커에 노출되지 않는다.

   3. response와 internalResponse를 HTTP-network-or-cache fetch를 fetchParams로 실행한 결과로 설정한다.

   4. request의 response tainting이 "cors"이고, request와 response에 대해 CORS check가 실패하면 네트워크 에러를 반환한다.

      CORS check는 response의 status가 304 또는 407인 경우, 또는 서비스 워커에서 온 경우에는 적용하지 않으며, 여기서 적용한다.

   5. request와 response에 대해 TAO check가 실패하면 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를 반환하면 네트워크 에러를 반환한다.

   cross-origin resource policy check는 네트워크에서 온 response와 서비스 워커에서 온 response 모두에 대해 실행된다. 이는 CORS check와 다르다. request의 client와 서비스 워커는 서로 다른 embedder 정책을 가질 수 있다.

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를 네트워크 에러로 설정한다.

      "manual"

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

      2. 그 외에는 response를 opaque-redirect filtered response로 설정하며, internal response는 internalResponse로 둔다.

      "follow"

      1. response를 HTTP-redirect fetch를 fetchParams와 response로 실행한 결과로 설정한다.

7. response를 반환한다. 일반적으로 internalResponse의 body의 stream이 반환 후에도 enqueue되고 있을 수 있다.

HTTP-redirect fetch를 실행하려면, fetch params fetchParams와 response response를 받아 다음 단계를 실행한다:

1. request를 fetchParams의 request로 둔다.

2. internalResponse를 response가 filtered response가 아니면 response로, 아니면 response의 internal response로 둔다.

3. locationURL을 internalResponse의 location URL로, request의 current URL의 fragment를 인자로 사용한다.

4. locationURL이 null이면 response를 반환한다.

5. locationURL이 실패면 네트워크 에러를 반환한다.

6. locationURL의 scheme이 HTTP(S) scheme이 아니면 네트워크 에러를 반환한다.

7. request의 redirect count가 20이면, 네트워크 에러를 반환한다.

8. request의 redirect count를 1 증가시킨다.

9. request의 mode가 "cors"이고, locationURL이 credentials를 포함하며, request의 origin이 locationURL의 origin과 same origin이 아니면, 네트워크 에러를 반환한다.

10. request의 response tainting이 "cors"이고, locationURL이 credentials를 포함하면, 네트워크 에러를 반환한다.

    이 규칙은 교차 출처 리소스가 동일 출처 URL로 리다이렉트할 때를 잡아낸다.

11. internalResponse의 status가 303이 아니고, request의 body가 null이 아니며, request의 body의 source가 null이면, 네트워크 에러를 반환한다.

12. 다음 중 하나라도 true이면

    • internalResponse의 status가 301 또는 302이고, request의 method가 `POST`임

    • internalResponse의 status가 303이고, request의 method가 `GET` 또는 `HEAD`가 아님

    이 경우:

    1. request의 method를 `GET`으로, request의 body를 null로 설정한다.

    2. 각 headerName에 대해 request-body-header name을 삭제한다. request의 header list에서 headerName을 삭제한다.

13. request의 current URL의 origin이 locationURL의 origin과 same origin이 아니면, 각 headerName에 대해 CORS non-wildcard request-header name을 삭제한다. request의 header list에서 headerName을 삭제한다.

    즉, 최초 요청 이후에 다른 origin이 나타나면 `Authorization` 헤더가 제거된다.

14. request의 body가 null이 아니면, request의 body를 body로, safely extracting을 request의 body의 source로 실행한 결과로 설정한다.

    request의 body의 source가 null인지 이미 확인됨.

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

16. timingInfo의 redirect end time과 post-redirect start time을 coarsened shared current time으로, fetchParams의 cross-origin isolated capability를 인자로 설정한다.

17. timingInfo의 redirect start time이 0이면, timingInfo의 redirect start time을 timingInfo의 start time으로 설정한다.

18. Append locationURL을 request의 URL list에 추가한다.

19. 리다이렉트 시 request의 referrer policy 설정를 request와 internalResponse로 실행한다. [REFERRER]

20. recursive를 true로 둔다.

21. request의 redirect mode가 "manual"이면:

    1. Assert: request의 mode가 "navigate"임

    2. recursive를 false로 설정한다.

22. main fetch를 fetchParams와 recursive로 실행한 결과를 반환한다.

    이 단계는 main fetch를 호출하여 request의 response tainting 값을 올바르게 설정한다.

HTTP-네트워크-또는-캐시 가져오기를 실행하려면, fetch params fetchParams, 선택적 불리언 isAuthenticationFetch(기본값 false), 선택적 불리언 isNewConnectionFetch(기본값 false)를 받아 다음 단계를 수행한다:

일부 구현체는 HTTP 캐싱에 따라 부분 콘텐츠의 캐싱을 지원할 수 있습니다. 하지만 브라우저 캐시에서는 널리 지원되지 않습니다. [HTTP-CACHING]

1. request를 fetchParams의 request로 둔다.

2. httpFetchParams를 null로 둔다.

3. httpRequest를 null로 둔다.

4. response를 null로 둔다.

5. storedResponse를 null로 둔다.

6. httpCache를 null로 둔다.

7. revalidatingFlag를 unset으로 둔다.

8. 아래 단계를 실행하지만 abort when fetchParams가 취소됨이면 중단한다:

   1. request의 traversable for user prompts가 "no-traversable"이고 request의 redirect mode가 "error"이면, httpFetchParams를 fetchParams로, httpRequest를 request로 설정한다.

   2. 그 외의 경우:

      1. httpRequest를 request의 복제본으로 설정한다.

         구현체는 request의 body의 stream을 tee하는 것을 피하는 것이 권장된다. request의 body의 source가 null인 경우 단일 body만 필요하다. 예를 들어, body의 source가 null이면 리다이렉트와 인증이 fetch 실패로 끝난다.

      2. httpFetchParams를 fetchParams의 복제본으로 설정한다.

      3. httpFetchParams의 request를 httpRequest로 설정한다.

      사용자 프롬프트 또는 리다이렉트가 가능한 경우, 사용자 에이전트는 프롬프트 응답 후 또는 리다이렉트 위치 결정 후 새 헤더 집합으로 요청을 재전송해야 할 수 있다. 이때 원래 요청 body가 이미 부분적으로 전송되었을 수 있으므로, 사전에 요청(body 포함)을 복제해 예비 복사본을 확보해야 한다.

   3. includeCredentials를 아래 중 하나라도 true이면 true로, 아니면 false로 설정한다:

      • request의 credentials mode가 "include"임
      • request의 credentials mode가 "same-origin"이고 request의 response tainting이 "basic"임

   4. Cross-Origin-Embedder-Policy에서 credentials 허용이 request로 false를 반환하면 includeCredentials를 false로 설정한다.

   5. contentLength를 httpRequest의 body의 length로, body가 null이면 null로 설정한다.

   6. contentLengthHeaderValue를 null로 둔다.

   7. httpRequest의 body가 null이고 httpRequest의 method가 `POST` 또는 `PUT`이면 contentLengthHeaderValue를 `0`로 설정한다.

   8. contentLength가 null이 아니면 contentLengthHeaderValue를 contentLength로, serialize와 isomorphic encode를 적용한 결과로 설정한다.

   9. contentLengthHeaderValue가 null이 아니면, append (`Content-Length`, contentLengthHeaderValue)를 httpRequest의 header list에 추가한다.

   10. contentLength가 null이 아니고 httpRequest의 keepalive가 true이면:

       1. inflightKeepaliveBytes를 0으로 둔다.

       2. group을 httpRequest의 client의 fetch group으로 둔다.

       3. inflightRecords를 group 내 fetch record들 중 request의 keepalive가 true이고, done flag가 unset인 것의 집합으로 둔다.

       4. 각 fetchRecord에 대해:

          1. inflightRequest를 fetchRecord의 request로 둔다.

          2. inflightKeepaliveBytes를 inflightRequest의 body의 length만큼 증가시킨다.

       5. contentLength와 inflightKeepaliveBytes의 합이 64키비바이트 넘으면 네트워크 에러를 반환한다.

       위 제한은 body가 있는 요청이 환경 설정 객체보다 오래 살아남을 수 있는 경우, 크기가 제한되고 무한히 살아남지 않도록 보장한다.

   11. httpRequest의 referrer가 URL이면:

       1. referrerValue를 httpRequest의 referrer를 serialize하고 isomorphic encode한 값으로 둔다.

       2. append (`Referer`, referrerValue)를 httpRequest의 header list에 추가한다.

   12. 요청 `Origin` 헤더 추가를 httpRequest로 실행한다.

   13. Fetch 메타데이터 헤더 추가를 httpRequest로 실행한다. [FETCH-METADATA]

   14. httpRequest의 initiator가 "prefetch"이면 구조화 필드값 설정을 (`Sec-Purpose`, 토큰 prefetch)로 httpRequest의 header list에 설정한다.

   15. httpRequest의 header list가 `User-Agent`를 포함하지 않으면, 사용자 에이전트는 append (`User-Agent`, 기본 `User-Agent` 값)을 httpRequest의 header list에 추가해야 한다.

   16. httpRequest의 cache mode가 "default"이고 httpRequest의 header list가 `If-Modified-Since`, `If-None-Match`, `If-Unmodified-Since`, `If-Match`, `If-Range` 중 하나라도 포함하면 httpRequest의 cache mode를 "no-store"로 설정한다.

   17. httpRequest의 cache mode가 "no-cache"이고 httpRequest의 prevent no-cache cache-control header modification flag가 unset이며, httpRequest의 header list가 `Cache-Control`을 포함하지 않으면 append (`Cache-Control`, `max-age=0`)를 httpRequest의 header list에 추가한다.

   18. httpRequest의 cache mode가 "no-store" 또는 "reload"이면:

       1. httpRequest의 header list가 `Pragma`를 포함하지 않으면 append (`Pragma`, `no-cache`)를 httpRequest의 header list에 추가한다.

       2. httpRequest의 header list가 `Cache-Control`을 포함하지 않으면, append (`Cache-Control`, `no-cache`)를 httpRequest의 header list에 추가한다.

   19. httpRequest의 header list가 `Range`를 포함하면, append (`Accept-Encoding`, `identity`)를 httpRequest의 header list에 추가한다.

       이 단계는 콘텐츠 코딩 처리 시 인코딩된 response 일부와 관련된 실패를 방지한다.

       또한, 많은 서버는 비-identity 인코딩이 허용될 때 `Range` 헤더를 잘못 무시한다.

   20. httpRequest의 header list를 HTTP에 따라 수정한다. append는 httpRequest의 header list에 해당 header의 name이 이미 있으면 추가하지 않는다.

       이 부분을 더 규범적으로 만들 수 있으면 좋겠다. 이 시점에서 `Accept-Encoding`, `Connection`, `DNT`, `Host`는 필요하면 append된다.

       `Accept`, `Accept-Charset`, `Accept-Language`는 이 시점에 포함되지 않아야 한다.

       `Accept`, `Accept-Language`는 이미 포함됨(fetch()에서는 기본적으로 포함되지 않음), `Accept-Charset`는 불필요한 바이트다. 자세한 내용은 HTTP 헤더 계층 분리 참고.

   21. includeCredentials가 true이면:

       1. 요청 `Cookie` 헤더 추가를 httpRequest에 대해 실행한다.

       2. httpRequest의 header list가 `Authorization`를 포함하지 않으면:

          1. authorizationValue를 null로 둔다.

          2. authentication entry가 httpRequest에 대해 존재하고, httpRequest의 use-URL-credentials flag가 unset이거나, httpRequest의 current URL이 credentials를 포함하지 않으면, authorizationValue를 authentication entry로 설정한다.

          3. 그 외에 httpRequest의 current URL이 credentials를 포함하고, isAuthenticationFetch가 true이면 authorizationValue를 httpRequest의 current URL로, `Authorization` 값으로 변환한다.

          4. authorizationValue가 null이 아니면 append (`Authorization`, authorizationValue)를 httpRequest의 header list에 추가한다.

   22. proxy-authentication entry가 있으면 적절히 사용한다.

       이 단계는 httpRequest의 credentials mode에 의존하지 않는다.

   23. httpCache를 HTTP 캐시 파티션 결정을 httpRequest로 실행한 결과로 설정한다.

   24. httpCache가 null이면 httpRequest의 cache mode를 "no-store"로 설정한다.

   25. httpRequest의 cache mode가 "no-store" 또는 "reload"가 아니면:

       1. storedResponse를 httpCache에서 응답을 선택한 결과로 설정한다. 필요하면 검증해야 한다. 자세한 내용은 HTTP 캐싱의 "Constructing Responses from Caches" 챕터 참고. [HTTP-CACHING]

          HTTP 요구에 따라, `Vary` 헤더도 고려된다.

       2. storedResponse가 null이 아니면:

          1. cache mode가 "default"이고, storedResponse가 stale-while-revalidate response이며, httpRequest의 client가 null이 아니면:

             1. response를 storedResponse로 설정한다.

             2. response의 cache state를 "local"로 설정한다.

             3. revalidateRequest를 request의 복제본으로 설정한다.

             4. revalidateRequest의 cache mode를 "no-cache"로 설정한다.

             5. revalidateRequest의 prevent no-cache cache-control header modification flag를 설정한다.

             6. revalidateRequest의 service-workers mode를 "none"으로 설정한다.

             7. 병렬로 main fetch를 새 fetch params로 실행한다. request는 revalidateRequest로 둔다.

                이 fetch는 httpCache의 상태를 갱신하는 용도이며, 응답은 다음 캐시 접근 전까지 사용되지 않는다. stale 응답이 현재 요청의 응답으로 사용된다. 이 fetch는 client 컨텍스트에서 발행되므로 client가 사라지면 요청도 종료된다.

          2. 그 외의 경우:

             1. storedResponse가 stale response이면 revalidatingFlag를 설정한다.

             2. revalidatingFlag가 설정되어 있고, httpRequest의 cache mode가 "force-cache" 또는 "only-if-cached"가 아니면:

                1. storedResponse의 header list에 `ETag`가 포함되어 있으면 append (`If-None-Match`, `ETag`의 value)를 httpRequest의 header list에 추가한다.

                2. storedResponse의 header list에 `Last-Modified`가 포함되어 있으면 append (`If-Modified-Since`, `Last-Modified`의 value)를 httpRequest의 header list에 추가한다.

                HTTP 캐싱의 "검증 요청 보내기" 챕터 참고. [HTTP-CACHING]

             3. 그 외에는 response를 storedResponse로 설정하고 response의 cache state를 "local"로 설정한다.

9. aborted라면 fetchParams에 대한 적절한 네트워크 에러를 반환한다.

10. response가 null이면:

    1. httpRequest의 cache mode가 "only-if-cached"이면 네트워크 에러를 반환한다.

    2. forwardResponse를 HTTP-network fetch를 httpFetchParams, includeCredentials, isNewConnectionFetch로 실행한 결과로 설정한다.

    3. httpRequest의 method가 unsafe이고 forwardResponse의 status가 200~399 범위면, httpCache에서 적절한 저장된 response를 무효화한다. 자세한 내용은 HTTP 캐싱의 "저장된 응답 무효화" 챕터 참고. [HTTP-CACHING] storedResponse를 null로 설정한다.

    4. revalidatingFlag가 설정되어 있고 forwardResponse의 status가 304이면:

       1. storedResponse의 header list를 forwardResponse의 header list로 갱신한다. 자세한 내용은 HTTP 캐싱의 "검증 시 저장된 응답 신선화" 챕터 참고. [HTTP-CACHING]

          이 단계는 캐시에 저장된 응답도 갱신한다.

       2. response를 storedResponse로 설정한다.

       3. response의 cache state를 "validated"로 설정한다.

    5. response가 null이면:

       1. response를 forwardResponse로 설정한다.

       2. httpRequest와 forwardResponse를 httpCache에 저장한다. 자세한 내용은 HTTP 캐싱의 "캐시에 응답 저장" 챕터 참고. [HTTP-CACHING]

          forwardResponse가 네트워크 에러이면, 이는 네거티브 캐싱(네트워크 에러 캐싱)이다.

          관련 body info도 캐시에 함께 저장된다.

11. response의 URL list를 httpRequest의 URL list의 복제본으로 설정한다.

12. httpRequest의 header list가 `Range`를 포함하면, response의 range-requested flag를 설정한다.

13. response의 request-includes-credentials를 includeCredentials로 설정한다.

14. response의 status가 401이고, httpRequest의 response tainting이 "cors"가 아니고, includeCredentials가 true이며, request의 traversable for user prompts가 traversable navigable이면:

    1. 테스트 필요: 다중 `WWW-Authenticate` 헤더, 누락, 파싱 이슈.

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

       1. request의 body의 source가 null이면 네트워크 에러를 반환한다.

       2. request의 body를 body로, safely extracting을 request의 body의 source로 실행한 결과로 설정한다.

    3. request의 use-URL-credentials flag가 unset이거나 isAuthenticationFetch가 true이면:

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

       2. username과 password를 최종 사용자에게 각각 요청하여 입력받고, request의 traversable for user prompts에서 입력한다.

       3. username 설정을 request의 current URL과 username으로 실행한다.

       4. password 설정을 request의 current URL과 password로 실행한다.

    4. response를 HTTP-네트워크-또는-캐시 가져오기를 fetchParams와 true로 실행한 결과로 설정한다.

15. response의 status가 407이면:

    1. request의 traversable for user prompts가 "no-traversable"이면 네트워크 에러를 반환한다.

    2. 테스트 필요: 다중 `Proxy-Authenticate` 헤더, 누락, 파싱 이슈.

    3. fetchParams가 취소됨이면 fetchParams에 대한 적절한 네트워크 에러를 반환한다.

    4. 최종 사용자에게 request의 traversable for user prompts에서 적절히 프롬프트하고, 결과를 proxy-authentication entry로 저장한다. [HTTP]

       프록시 인증 관련 세부 사항은 HTTP에서 정의된다.

    5. response를 HTTP-네트워크-또는-캐시 가져오기를 fetchParams로 실행한 결과로 설정한다.

16. 아래 모두 true이면:

    • response의 status가 421임

    • isNewConnectionFetch가 false임

    • request의 body가 null이거나, request의 body가 null이 아니고, request의 body의 source가 null이 아님

    이 경우:

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

    2. response를 HTTP-네트워크-또는-캐시 가져오기를 fetchParams, isAuthenticationFetch, true로 실행한 결과로 설정한다.

17. isAuthenticationFetch가 true이면 authentication entry를 request와 주어진 realm에 대해 생성한다.

18. response를 반환한다. 일반적으로 response의 body의 stream은 반환 후에도 enqueue되고 있을 수 있다.