패치

특정 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"를 반환한다.

직렬화된 쿠키 기본 경로를 URL url로부터 얻으려면:

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

2. cloneURL의 path를 쿠키 기본 경로로 설정한다. 이때 cloneURL의 path를 사용한다.

3. cloneURL의 URL 경로 직렬화를 반환한다.

요청 `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 프로토콜 사용 등).