프리페치

1. hypotheticalEnvironment을 예약 클라이언트 생성하기의 결과로 생성한다. 매개값으로 navigable, response의 URL, 그리고 null을 전달한다.

2. hypotheticalPartitionKey를 네트워크 파티션 키 결정을 hypotheticalEnvironment에 대해 실행한 결과로 생성한다.

3. 만약 hypotheticalPartitionKey가 sourcePartitionKey와 같거나, 자격 증명이 URL과 hypotheticalPartitionKey를 기준으로 연관되지 않은 경우 false를 반환한다.

4. true를 반환한다.

1. 단언: redirectChain은 비어있지 않음입니다.

2. 단언: redirectChain의 마지막 항목의 request가 request와 동일하며, response가 null입니다.

3. redirectChain의 마지막 항목의 request를 request 클론으로 설정합니다.

   클론 작업을 통해 향후 리다이렉트로 인해 request가 변경되어도 저장된 request는 활성화 시점(prefetch 기록에서 네비게이션 파라미터 만들기 단계)에서 원본 리다이렉트 체인을 제대로 참조하기 위해 보존됩니다. 현재 명세상에서 request의 필드가 변형되면서 활성화 시점에도 필요로 하는 유일한 경우는 referrer 필드입니다. 명세 견고성을 위해 전체 request를 클론합니다.

   프리페치는 오직 `GET` 요청에 대해서만 수행하므로, request의 body는 항상 null이며, 따라서 클론이 간단합니다.

4. redirectChain의 마지막 항목의 response를 response로 설정합니다.

1. prefetchRecord의 URL이 url과 같으면 true를 반환한다.

2. prefetchRecord의 response가 null이 아니라면:

   1. searchVariance을 URL 검색 변동성 얻기를 prefetchRecord의 redirect chain[0]의 response에 대해 실행한 결과로 설정한다.

      첫 response(prefetchRecord의 response가 아니라)의 No-Vary-Search 헤더만 매칭에 영향을 주므로, 꼭 0번째 response를 체크해야 합니다. 이는 prefetch record의 URL이 첫 번째 요청/응답 쌍의 URL이기 때문입니다.

   2. searchVariance를 사용했을 때 prefetchRecord의 URL과 url이 검색 변동성 기준으로 동등(equivalent modulo search variance)하면 true를 반환한다.

3. 그 외에는 false를 반환한다.

1. prefetchRecord가 URL에 매칭된다면 true를 반환한다.

2. prefetchRecord의 response가 null일 경우:

   1. searchVariance를 prefetchRecord의 No-Vary-Search 힌트로 한다.

   2. prefetchRecord의 URL과 url이 검색 변동성 기준으로 동등하면 true 반환.

3. 그 외에는 false 반환.

1. 단언: prefetchRecord가 document의 프리페치 기록에 포함되어 있음.

2. 단언: prefetchRecord의 상태가 "취소됨"이 아님.

3. prefetchRecord의 상태를 "취소됨"으로 설정한다.

4. 중단(abort): prefetchRecord의 fetch controller. 이로 인해 진행중인 fetch는 취소되고, 네트워크 오류가 발생합니다.

5. prefetchRecord의 prerendering traversable이 traversable navigable이면 파괴(destroy)한다.

6. 제거: document의 프리페치 기록에서 prefetchRecord를 제거한다.

7. 프리페치 상태 갱신 이벤트 트리거를 document의 node navigable, prefetchRecord, 그리고 "failure" 상태로 호출한다.

완료된 프리페치나 프리렌더도 활성화되지 않습니다. 하지만 프리페치 또는 프리렌더 과정에서 HTTP 캐시가 수정된다면, 이후의 탐색 속도를 높일 수 있습니다.

1. 단언: document가 완전히 활성화됨.

2. currentTime을 현재 고해상도 시간으로 설정, document의 관련 글로벌 객체 기준.

3. expiryTime을 currentTime + 300000(즉, 5분)으로 설정.

4. 제거: document의 프리페치 기록 중 prefetchRecord와 동일한 URL을 가진 완료(상태가 "완료됨")된 기록을 모두 제거.

5. prefetchRecord의 상태를 "완료됨", 만료 시간을 expiryTime으로 설정.

6. 프리페치 상태 갱신 이벤트 트리거를 document의 node navigable, prefetchRecord, 그리고 "ready" 상태로 호출.

1. exactRecord를 null로 초기화.

2. inexactRecord를 null로 초기화.

3. 각 record에 대해 sourceSnapshotParams의 프리페치 기록에서 반복:

   1. record의 상태가 "완료됨"이 아니면 다음 반복으로.

   2. record의 URL이 url과 같다면:

      1. exactRecord를 record로 설정.

      2. 반복 종료.

   3. inexactRecord가 null이고, record가 URL에 매칭된다면:

      1. inexactRecord를 record로 설정.

4. recordToUse를 exactRecord가 null이 아니면 그것으로, 아니면 inexactRecord로 설정.

5. recordToUse가 null이 아니면:

   1. currentTime을 현재 고해상도 시간으로 설정, navigable의 활성 문서 기준.

   2. recordToUse의 만료 시간이 currentTime보다 작으면:

      1. 프리페치 상태 갱신 이벤트 트리거를 navigable, recordToUse, "failure" 상태로 호출.

      2. null 반환.

   3. 각 exchangeRecord에 대해 recordToUse의 redirect chain에서 반복:

      1. 충돌하는 자격 증명이 존재하면, exchangeRecord의 response, navigable, recordToUse의 source partition key를 기준으로:

         1. 프리페치 상태 갱신 이벤트 트리거를 navigable, recordToUse, "failure" 상태로 호출.

         2. null 반환.

      초기엔 크로스 파티션 자격증명이 없어도 이후 생길 수 있습니다. 사용자 에이전트는 URL의 쿠키가 변경되었는지 모니터링하거나, 해시/타임스탬프/버전번호 등을 저장하는 식의 조잡한 알고리즘을 쓸 수도 있습니다.

   4. recordToUse 반환.

6. null 반환.

실제로 프리페치가 본문 전체를 가져왔는지 필요는 없고, 응답 헤더만 있으면 됩니다. 즉, 프리페치를 활용한 탐색이라도 즉시 로드되지 않을 수 있습니다.

캐시 응답 헤더를 활용하여 여러 번 응답을 사용할 수 있을지 결정하는 것도 가능할 수 있으나, 프리페치 버퍼의 짧은 수명으로 실효성은 불투명합니다.

1. 단언: 병렬로 실행중인지 확인(in parallel).

2. timeout을 null로 초기화.

3. 선택적으로 timeout을 구현자 정의 지속 기간으로 설정, 진행중인 프리페치가 응답하지 않으면 탐색을 재시작하는 최대 대기 시간.

   적정 timeout 선택은 어렵고, 탐색 또는 프리페치의 정확한 발신자(예: 추측 규칙 eagerness나 프리렌더 예정 여부 등)에 따라 달라질 수 있다. 일반적으로 timeout은 피하는 게 좋지만, 일부 구현체에선 몇 초 수준의 timeout이 더 나은 결과를 줄 때가 있다.

4. startTime을 공유 현재 시간으로 설정.

5. 이 단계들을 실행하되, timeout이 null이 아니고 위험한 공유 현재 시각 − startTime이 timeout보다 크면 중단(abort when)한다:

   1. 반복:

      1. completeRecord를 완료된 프리페치 기록 찾기의 결과(navigable, sourceSnapshotParams, url 매개값)로 설정.

      2. completeRecord가 null이 아니면 completeRecord를 반환.

      3. potentialRecords를 빈 리스트로 초기화.

      4. 각 record에 대해 sourceSnapshotParams의 프리페치 기록에서 반복:

         1. 아래 모두 true이면:

            • record의 상태가 "진행중";

            • record가 URL에 매칭될 것으로 예상됨; 그리고

            • record의 만료 시간이 현재 고해상도 시간보다 큼(navigable의 활성 창 기준),

            조건 충족 시 리스트에 추가: record를 potentialRecords에 추가.

         반복마다 potentialRecords를 새로 계산합니다. 이후 반복에서 potentialRecords는 이전 반복의 potentialRecords의 부분집합이 됩니다. sourceSnapshotParams의 프리페치 기록은 스냅샷이기 때문이며, 해당 조건들은 false→true로 변화하지 않음에서 비롯됩니다.

         동등한 전략으로는 potentialRecords의 초기 인스턴스를 한 번만 구성한 뒤, 더 이상 조건을 충족하지 않는 항목을 그 인스턴스에서 제거할 수 있습니다.

      5. potentialRecords가 비어있으면 null 반환.

      6. 상태가 바뀔 때까지 sourceSnapshotParams의 프리페치 기록에서 대기.

6. null 반환.

sourceSnapshotParams의 프리페치 기록은 스냅샷이므로, 탐색 이후에 시작된 프리페치는 해당 탐색에서 활성화될 수 없습니다.

1. 각 candidate를 candidates에서 반복:

   1. prefetchRecord가 URL에 매칭되지 않으면 candidate의 URL에 대해 다음으로 계속.

   2. candidate가 프리페치 후보이고, prefetchRecord의 익명화 정책이 candidate의 익명화 정책과 다르면 다음으로 계속.

   3. candidate가 프리렌더 후보이고, prefetchRecord의 프리렌더링 traversable 값이 null이면 다음으로 계속.

   4. true 반환.

2. false 반환.

1. 각 record를 document의 프리페치 기록에서 반복:

   1. record의 상태가 "취소됨"이면 다음으로 계속.

   2. checkPrerender가 true이면:

      1. record의 프리렌더링 traversable 값이 null이면 다음으로 계속.

      2. record의 프리렌더링 대상 navigable name 힌트가 recordUnderConsideration의 프리렌더링 대상 navigable name 힌트와 다르면 사용자 에이전트는 다음으로 계속할 수 있다.

         프리렌더링 대상 name 힌트에 따라 별도의 프리렌더링 traversable을 만드는 사용자 에이전트는 여기서 continue 합니다. 반대로, 해당 힌트와 상관없이 기존 traversable을 활성화할 수 있다면, 기록을 동일하게 취급합니다.

   3. recordNVS를 null로 둡니다.

   4. record의 response가 null이 아니면, recordNVS = URL 검색 변동성 취득 결과 (record의 response 기준).

   5. 그 외에는 recordNVS = record의 No-Vary-Search 힌트로 둡니다.

   6. recordUnderConsideration의 No-Vary-Search 힌트가 recordNVS와 다르면 다음으로 계속.

   7. recordUnderConsideration의 URL과 record의 URL이 검색 변동성 기준으로 동등(recordUnderConsideration의 No-Vary-Search 힌트 기준)이면 true 반환.

2. false 반환.

No-Vary-Search 비교에 관한 논의는 HTML 표준을 참조

1. responseOrigin을 null로.

2. responseCOOP을 null로.

3. coopEnforcementResult를 탐색용 COOP enforcement 결과 생성의 결과로 함. navigable의 active document, documentState의 initiator origin 사용.

4. finalSandboxFlags을 빈 샌드박스 플래그 집합으로.

5. responsePolicyContainer를 null로.

6. urlList를 빈 리스트로.

7. response를 record의 response로.

8. 각 exchangeRecord에 대해 record의 redirect chain 반복:

   1. redirectChainRequest를 exchangeRecord의 request로.

   2. redirectChainResponse를 exchangeRecord의 response로.

   3. 추가: redirectChainRequest의 URL을 urlList에.

   4. responsePolicyContainer를 fetch response로 정책 컨테이너 만들기 결과로 설정. redirectChainResponse, redirectChainRequest의 reserved client 사용.

   5. finalSandboxFlags를 합집합으로, targetSnapshotParams의 샌드박스 플래그와 responsePolicyContainer의 CSP list의 CSP 파생 샌드박스 플래그.

   6. responseOrigin를 origin 결정 결과로, redirectChainResponse의 URL, finalSandboxFlags, documentState의 initiator origin, null 사용.

   7. responseCOOP을 cross-origin opener policy 획득 결과로, redirectChainResponse, redirectChainRequest의 reserved client 사용.

   8. coopEnforcementResult를 cross-origin opener policy enforcement 결과로 수정, navigable의 active browsing context, redirectChainResponse의 URL, responseOrigin, responseCOOP, coopEnforcementResult 및 redirectChainRequest의 referrer 사용.

   9. finalSandboxFlags가 empty가 아니고 responseCOOP의 값이 "unsafe-none"이면, response를 적절한 네트워크 오류로 하고 반복 종료.

9. request의 URL이 urlList[0]과 다르면 request의 URL을 0번째 항목 뒤에 urlList에 삽입.

   이 경우, 탐색은 request의 URL로가지만, 프리페치는 urlList[0]의 response에서 온다는 점(No-Vary-Search 헤더 때문). 이를 0번째 응답에서 URL로의 리다이렉트처럼 취급. 만약 삽입 후 urlList 크기가 2이면, 생성된 Document에서 탐색 대상 URL을 사용. 그 이상이면 영향 없음.

   예: /page?param=1을 프리페치하면 서버가 200과 No-Vary-Search: params=("param") 헤더를 보냄.

   나중에 /page?param=2로 탐색하면 프리페치가 사용됨. urlList는 « /page?param=1, /page?param=2 »가 되어, 생성된 Document의 URL은 /page?param=2가 됨.

   예: /page?param=1을 프리페치하면 서버가 No-Vary-Search: params=("param")와 301, Location: https://other.example/을 보냄.

   나중에 /page?param=2로 탐색하면 프리페치가 사용됨. urlList는 « /page?param=1, /page?param=2, https://other.example/ »가 되어, 최종 Document의 URL은 https://other.example/가 됨.

10. request의 URL 리스트를 urlList로 설정.

11. request의 reserved client를 reserved client 생성 결과로, navigable, request의 URL 사용.

    이 환경은 결과 Document와 환경 설정 객체를 생성하는 데 쓰입니다. 프리페치 기록이 소비될 때마다 별도의 환경이 필요하며, record의 리다이렉트 체인 마지막 항목의 요청의 예약된 클라이언트를 쓰면 안 됩니다. 그렇지 않으면 같은 프리페치 기록을 여러 탐색 매개변수(즉, 여러 탐색)에 재사용할 때 생성된 환경 설정 객체들이 id를 공유하게 됩니다. 이는 clients.get() API 등을 통해 노출되어 매우 혼란스러운 결과를 낳습니다.

12. request의 reserved client의 active service worker를 record의 redirect chain 마지막 항목의 request의 reserved client의 active service worker로 설정.

    여기서 생성될 Document의 Service Worker로 프리페치 처리 중 최종 응답을 가로챈 SW 또는 탐색 대상인 request의 URL에 매칭하는 등록의 SW 중 선택 가능. 대부분 같지만, No-Vary-Search와 함께 개발자가 /page?param=1과 /page?param=2에 서로 다른 SW를 생성하는 예외적인 상황에서는 서로 다를 수 있음.

    최종 응답을 가로챈 SW를 사용. SW를 추가로 조회하지 않아도 되고, 프리렌더링에서도 URL 업데이트가 SW 변경을 일으키지 않으므로 일관됨.

13. resultPolicyContainer를 navigation params 정책 컨테이너 결정 결과로, record의 response의 URL, documentState의 history policy container, sourceSnapshotParams의 source policy container, null, responsePolicyContainer 사용.

14. response가 네트워크 오류가 아니면:

    1. 선택적으로 response를 클론으로 만드세요. 다회 소비 예상시 필요.

       구현체는 프리페치가 여러 번 소비될 것으로 예상되면 이 단계를 수행할 수 있음. 예를 들어 이후 응답이 프리렌더에 소비되면, 그 프리렌더링 traversable이 여러 방법으로 삭제될 수 있음. 보통은 이때 응답도 폐기되지만, 구현체가 이 단계를 수행하면 프리페치된 응답이 남아 이후 탐색에 제공될 수 있음. [PRERENDERING-REVAMPED]

    2. 직전 단계를 하지 않았다면, 반드시 제거: record를 navigable의 active document의 프리페치 기록에서 제외.

15. 아래 정보를 포함한 새로운 navigation params를 반환:

    id

    navigationId

    request

    request

    response

    response

    origin

    responseOrigin

    policy container

    resultPolicyContainer

    final sandboxing flag set

    finalSandboxFlags

    cross-origin opener policy

    responseCOOP

    COOP enforcement result

    coopEnforcementResult

    reserved environment

    request의 reserved client

    navigable

    navigable

    navigation timing type

    navTimingType

    fetch controller

    record의 fetch controller

    위 선택 단계를 수행하여 record가 이 알고리즘의 여러 호출을 통해 다수의 탐색 매개변수를 생성하는 경우, 모든 탐색 매개변수가 같은 페치 컨트롤러를 공유해도 됩니다. 탐색 매개변수의 페치 컨트롤러는 탐색 타이밍 정보를 계산하는 데만 쓰이며, 이 정보는 재사용할 때도 같아야 하기 때문입니다.

    commit early hints

    null

    프리페치 문서에 대해 early hints가 처리되지 않음을 의미. 향후 명세에서 유용한 리소스 힌트가 흔하다면 바뀔 수 있음. 현재 프리페치가 응답 헤더 도착 전에는 제공되지 않으므로 early hints를 더 일찍 처리할 수 없음. 향후 명세에서 활용 가능성 있음.

    delivery type

    "navigational-prefetch"

1. policy가 크로스 오리진 프리페치 IP 익명화 정책이면:

   1. request의 URL의 origin이 policy의 origin과 동일이면 false 반환.

   2. true 반환.

2. 단언: policy는 null.

3. false 반환.

create a reserved client: navigable navigable, URL url, opaque origin 또는 null isolationOrigin이 주어졌을 때:

1. topLevelCreationURL = url로 둡니다.

2. topLevelOrigin = null로 둡니다.

3. isolationOrigin이 null이 아니면:

   1. topLevelCreationURL을 about:blank로 설정

   2. topLevelOrigin을 isolationOrigin으로 설정

4. 아니면, navigable이 top-level traversable이 아니면:

   1. parentEnvironment = navigable의 parent의 active document의 relevant settings object로 둡니다.

   2. topLevelCreationURL = parentEnvironment의 top-level creation URL로 설정.

   3. topLevelOrigin = parentEnvironment의 top-level origin으로 설정.

5. 새로운 environment 반환: id는 고유 불투명 문자열, target browsing context는 navigable의 active browsing context, creation URL은 url, top-level creation URL은 topLevelCreationURL, top-level origin은 topLevelOrigin.

create a cross-origin opener policy enforcement result for navigation: Document activeDocument와 origin initiatorOrigin이 주어졌을 때, 새 cross-origin opener policy enforcement result 반환:

url

activeDocument의 URL

origin

activeDocument의 origin

cross-origin opener policy

activeDocument의 cross-origin opener policy

current context is navigation source

activeDocument의 origin이 initiatorOrigin과 same origin이면 true, 아니면 false

create a navigation request: session history entry entry, environment settings object fetchClient, navigable container 또는 null container, boolean hasTransientActivation 주어졌을 때 아래 단계 수행:

1. documentResource = entry의 document state의 resource.

2. request를 새 request로 생성하며 구성:

   url

   entry의 URL

   policy container

   entry의 document state의 history policy container

   client

   fetchClient

   destination

   "document"

   credentials mode

   "include"

   use-URL-credentials flag

   설정됨

   redirect mode

   "manual"

   mode

   "navigate"

   referrer

   entry의 document state의 request referrer

   referrer policy

   entry의 document state의 request referrer policy

3. documentResource가 POST resource이면:

   1. request의 method를 `POST`로 설정.

   2. request의 body를 documentResource의 request body로 설정.

   3. Set `Content-Type`을 documentResource의 request content-type으로 request의 header list에 설정.

4. entry의 document state의 reload pending이 true면, request의 reload-navigation flag를 설정.

5. 아니면 entry의 document state의 ever populated가 true면, request의 history-navigation flag를 설정.

6. hasTransientActivation이 true면, request의 user-activation을 true로.

7. container가 null이 아니면:

   1. container에 browsing context scope origin이 있으면 request의 origin을 해당 browsing context scope origin으로 설정.

   2. request의 destination 및 initiator type을 container의 local name으로 설정.

8. request 반환.

1. 아래 두 조건 모두 true면:

   • entry의 URL의 scheme이 fetch scheme인 경우

   • documentResource가 null이거나, allowPOST가 true이고 documentResource의 request body가 실패(failure)가 아님

   이면:

   1. request = create a navigation request 결과. 인자: entry, sourceSnapshotParams의 fetch client, navigable의 container, sourceSnapshotParams의 has transient activation.

   2. request의 replaces client id = navigable의 active document의 relevant settings object의 id로 설정.

   3. prefetched = false로 둠.

   4. documentResource가 null이고 navigable이 top-level traversable면:

      1. prefetchRecord = wait for a matching prefetch record 결과. 인자: navigable, sourceSnapshotParams, entry의 URL.

      2. prefetchRecord가 null이 아니면:

         1. navigationParams = create navigation params from a prefetch record 결과. 인자: navigable, entry의 document state, navigationId, navTimingType, request, prefetchRecord, targetSnapshotParams, sourceSnapshotParams.

         2. Copy prefetch cookies: prefetchRecord의 isolated partition key, navigationParams의 reserved environment 인자로.

            이 복사는 계속 진행됩니다. 즉, 서브리소스 fetch, document.cookie 등이 쿠키를 관찰 가능. 프리페치가 cross-site URL에 도달하지 못했다면 복사할 쿠키 없음.

         3. prefetched = true로 설정.

         4. Trigger a prefetch status updated event 호출: navigable, prefetchRecord, "success" 상태.

         이 단계에 따라 prefetch는 오직 `GET` 요청에만 사용되고, 반드시 top-level traversable로 활성화됩니다.

   5. prefetched가 false이면 navigationParams = create navigation params by fetching 결과. 인자: request, entry, navigable, sourceSnapshotParams, targetSnapshotParams, cspNavigationType, navigationId, navTimingType.

create navigation params by fetching의 입력 값은 request request, session history entry entry, navigable navigable, source snapshot params sourceSnapshotParams, target snapshot params targetSnapshotParams, string cspNavigationType, navigation ID 또는 null navigationId, NavigationTimingType navTimingType, 그리고 선택적 prefetch record prefetchRecord 입니다. 다음 단계를 수행합니다.

1. 단언: 이 단계는 병렬로 실행 중임.

2. 단언: request의 URL이 entry의 URL임.

3. 단언: request의 mode가 "navigate"임.

4. 단언: request의 redirect mode가 "manual"임.

5. 단언: request의 reserved client가 null임.

6. response를 null로 둔다.

7. responseOrigin을 null로 둔다.

8. fetchController를 null로 둔다.

9. coopEnforcementResult를 탐색용 교차 오리진 오프너 정책 강제 결과 생성의 결과로 설정 navigable의 active document와 entry의 document state의 initiator origin 사용.

10. finalSandboxFlags를 빈 샌드박스 플래그 집합으로 둔다.

11. responsePolicyContainer를 null로 둔다.

12. responseCOOP를 새 교차 오리진 오프너 정책으로 둔다.

13. locationURL을 null로 둔다.

14. currentURL을 request의 current URL로 둔다.

15. commitEarlyHints를 null로 둔다.

16. isolationOrigin을 null로 둔다.

17. prefetchRecord가 주어졌다면:

    1. isolationSite를 prefetchRecord의 격리된 파티션 키[0]로 둔다.

    2. 단언: isolationSite는 불투명 오리진임.

    3. isolationOrigin을 isolationSite로 설정.

18. while true:

    1. request의 reserved client가 null이 아니고 currentURL의 origin이 request의 reserved client의 creation URL의 origin과 다르면:

       1. environment 폐기 절차를 request의 reserved client에 대해 실행.

       2. request의 reserved client를 null로.

       3. commitEarlyHints를 null로.

    2. request의 reserved client가 null이면:

       1. request의 reserved client를 예약 클라이언트 생성(navigable, currentURL, isolationOrigin) 결과로 설정.

       2. prefetchRecord가 주어졌다면, request의 reserved client의 네비게이션 프리페치 클라이언트 여부를 true로.

    3. Content Security Policy로 네비게이션 요청 차단 여부?(request, cspNavigationType)의 결과가 "Blocked"이면 response를 network error로 하고 break. [CSP]

    4. prefetchRecord가 주어졌다면:

       1. purpose를 List(Token prefetch 포함)로 둔다.

       2. 만약 prefetchRecord의 익명화 정책이 익명성 필요라면:

          1. anonymous-client-ip 키, 값 true인 파라미터를 prefetch token에 추가 (purpose에).

          2. 사용자 에이전트는 클라이언트 IP 익명화(예: 프록시)를 하여 request fetch 하거나, 불가하다면 response를 network error 및 break.

             IP 익명화 구현은 현재 불명확하며, 프록시·릴레이 등 구현자 정의 방식 예상. 장기적으론 연결 획득(obtain a connection)까지 연계 가능성 있음.

       3. prefetchRecord의 프리렌더링 traversable이 null이 아니면 prerender(값 true) 파라미터를 prefetch token에 추가.

       4. 구조화 필드 값 설정 (`Sec-Purpose`, purpose)을 request의 header list에 설정.

          구현체는 vendor별 헤더(Purpose/prefetch, X-moz/prefetch, X-Purpose/preview 등)도 전송할 수 있음. 시간이 지나면 이 표준 헤더로 통합 기대.

       5. request의 current URL의 origin이 same site인 경우 prefetchRecord의 URL의 origin과 비교:

          1. tags를 prefetchRecord의 tags의 각 항목을 매핑해 구성하는 List로 합니다. 이때 문자열은 Strings로, null은 Token null로 변환합니다.

          2. 구조화 필드 값 설정 (`Sec-Speculation-Tags`, tags)을 request의 header list에 설정.

       6. request의 current URL이 잠재적으로 신뢰할 수 있는 URL이 아니다? response를 network error로 하여 break.

          프리페치 트래픽이 공격자에게 노출되는 걸 막고, 공용망에서 암호화 스킴 사용을 유도하기 위함.

       7. proposedPartitionKey를 네트워크 파티션 키 결정(request의 reserved client) 결과로 둔다.

       8. proposedPartitionKey가 prefetchRecord의 source partition key와 다르고 request의 referrer policy가 충분히 엄격한 추론형 네비 referrer 정책 목록에 없다면 response를 network error 및 break.

          즉, 교차사이트 프리페치는 origin 이상 referrer 노출 막음.

       9. request가 prefetchRecord의 익명화 정책으로 구현체가 정의한 이유로 fetch 불가 시 response를 network error 및 break.

          구현체별로 더욱 제약 있을 수 있음, 예: 공개 라우팅 안되는 호스트·private prefetch 거부 호스트 등

       10. 추가: 새 exchange record(request, response=null) 를 prefetchRecord의 redirect chain에.

    5. response를 null로 둔다.

    6. fetchController가 null이라면, fetching request의 결과를 fetchController로 두고 processEarlyHintsResponse·processResponse는 아래와 같이, useParallelQueue는 true로 한다.

       processEarlyHintsResponse 알고리즘 (응답 earlyResponse):

       1. prefetchRecord가 주어졌고 commitEarlyHints가 null이면 commitEarlyHints=early hint 헤더 처리(earlyResponse, request의 reserved client)로 한다.

       processResponse 알고리즘(응답 fetchedResponse):

       1. response = fetchedResponse로 한다.

    7. 그 외에는 다음 수동 리다이렉트 처리를 fetchController에 대해 실행.

    8. response가 null 아니게 되거나, navigable의 진행 중 탐색이 navigationId와 달라질 때까지 대기.

       후자라면 abort fetchController 하고 return, 아니면 계속. 이렇게 하면 탐색 시작 즉시 프리페치 중단됨, 바람직하지 않을 수 있음.

    9. request의 body가 null이면 entry의 document state의 resource를 null로.

    10. responsePolicyContainer를 fetch 응답에서 정책 컨테이너 생성(response, request의 reserved client)으로 둔다.

    11. finalSandboxFlags를 합집합으로, targetSnapshotParams의 샌드박스 플래그와 responsePolicyContainer의 CSP 목록의 CSP 유도 샌드박스 플래그의 합집합으로 한다.

    12. responseOrigin을 오리진 결정(response의 URL, finalSandboxFlags, entry의 document state의 initiator origin, null)으로 둔다.

    13. navigable이 최상위 traversable이고 prefetchRecord가 없는 경우:

        1. responseCOOP를 교차 오리진 오프너 정책 획득(response, request의 reserved client) 결과로 한다.

        2. coopEnforcementResult를 응답의 교차 오리진 오프너 정책 강제(navigable의 active browsing context, request의 URL, responseOrigin, responseCOOP, coopEnforcementResult, request의 referrer) 결과로 한다.

        3. finalSandboxFlags이 비어있지 않고 responseCOOP의 value가 "unsafe-none"이 아니면 response를 network error로 하고 break.

        프리페치의 COOP 검사는 활성화 시점(대상 브라우징 컨텍스트 파악 시)에서 수행됨.

    14. response가 network error가 아니고 navigable이 child navigable이며 cross-origin resource policy check(navigable의 container document의 origin, navigable의 container document의 relevant settings object, request의 destination, response, true)이 blocked면 response를 network error로 하고 break.

    15. prefetchRecord가 주어졌다면:

        1. Update prefetchRecord의 redirect chain(request, response).

        2. 자격 증명 충돌 존재(response, navigable, prefetchRecord의 source partition key)라면 prefetchRecord의 충돌 자격 증명 있음을 true로.

           이 즉시 프리페치/리다이렉트 중단은 하지 않음. 즉시 중단시 사용자 외부 파티션 저장 여부 노출될 수 있음. 대신 계속하지만 실질적 사용은 불가. 이 경우 콘솔 경고 등으로 알릴 수 있음.

    16. locationURL을 response의 location URL(currentURL의 fragment)로 한다.

    17. locationURL이 failure 또는 null이면 break.

    18. 단언: locationURL은 URL임.

    19. entry의 serialized state를 StructuredSerializeForStorage(null)로 한다.

    20. oldDocState를 entry의 document state로 한다.

    21. entry의 document state를 새 document state로 지정 (구성:)

        history policy container

        oldDocState의 history policy container 복제

        request referrer

        oldDocState의 request referrer

        request referrer policy

        oldDocState의 request referrer policy

        origin

        oldDocState의 origin

        resource

        oldDocState의 resource

        ever populated

        oldDocState의 ever populated

        navigable target name

        oldDocState의 navigable target name

    22. locationURL의 scheme이 HTTP(S) scheme이 아니라면:

        1. entry의 document state의 resource를 null로.

        2. break.

    23. currentURL을 locationURL로 한다.

    24. entry의 URL을 currentURL로 한다.

19. locationURL이 URL이고, scheme이 fetch scheme이 아니면, 새 비fetch 스킴 navigation params를 반환 (내용:)

    initiator origin

    request의 current URL의 origin

20. 아래 중 하나라도 true이면:

    • response가 network error

    • locationURL이 failure임

    • locationURL이 URL이고, scheme이 fetch scheme

    null 반환

21. resultPolicyContainer를 네비게이션 파라미터 정책 컨테이너 결정 결과로 (response의 URL, entry의 document state의 history policy container, sourceSnapshotParams의 source policy container, null, responsePolicyContainer 인자).

22. 아래와 같은 새 navigation params 반환:

    id

    navigationId

    request

    request

    response

    response

    origin

    responseOrigin

    policy container

    resultPolicyContainer

    최종 샌드박스 플래그 집합

    finalSandboxFlags

    교차 오리진 오프너 정책

    responseCOOP

    COOP 강제 결과

    coopEnforcementResult

    예약 environment

    request의 reserved client

    navigable

    navigable

    navigation timing type

    navTimingType

    fetch controller

    fetchController

    early hints 커밋

    commitEarlyHints

1. navigationParams의 delivery type이 "prefetch"이면 swapGroup을 true로 설정(옵션).

   이렇게 하면 참조 사이트가 프리페치가 사용되었는지 로드 타이밍을 통해 판단하기 어렵게 되어, 목적지 사이트 정보 유출을 방지할 수 있습니다.

request가 비서브리소스 요청이고 request의 destination이 "report"가 아니며 그리고 reservedClient의 is navigational prefetch client가 false인 경우 e의 resultingClientId 속성을 reservedClient의 id로, 그 외에는 빈 문자열로 초기화.

프리페치 케이스에선 request가 이 시점에 reserved client를 갖고 있지만, 이는 스펙 상 허구로, 요청이 제대로 흐르도록 돕기 위한 것임. 실제 클라이언트(client)는 존재하지 않으며, 예시로 clients.matchAll() 등에서 보이지 않음. 실제 클라이언트 생성은 active 시점에, 즉 FetchEvent 실행 이후에 이뤄짐.

1. 단언: document의 node navigable이 최상위 traversable임.

   프리페치가 child navigable에서 지원되는 것은 복잡성이 있고 아직 정의되지 않았으며, 미래에 정의될 가능성은 존재합니다.

2. document가 매칭 프리페치 기록을 가질 경우 prefetchRecord로 return.

3. sourceSnapshotParams = source snapshot params 스냅샷(document).

4. targetSnapshotParams = target snapshot params 스냅샷(document의 node navigable).

5. prefetchRecord의 source partition key를 네트워크 파티션 키 결정(document의 relevant settings object)로 설정.

6. 단언: prefetchRecord의 URL의 scheme이 HTTP(S) scheme임.

7. 추가: prefetchRecord를 document의 prefetch records에.

8. prefetchRecord의 start time을 현재 고해상도 시간 (relevant global object 기준)로 설정.

9. 프리페치 상태 업데이트 이벤트 트리거(document의 node navigable, prefetchRecord, "pending" 상태).

10. referrerPolicy = prefetchRecord의 referrer policy가 빈 문자열이 아니면 그 값, 아니면 document의 policy container의 referrer policy.

11. documentState = 새 document state (구성:)

    request referrer policy

    referrerPolicy

    initiator origin

    document의 origin

12. entry = 새 session history entry (구성:)

    URL

    prefetchRecord의 URL

    document state

    documentState

13. request = 네비게이션 요청 생성(entry, document의 relevant settings object, document의 node navigable의 container, false).

14. global = document의 relevant global object.

15. 병렬로 수행:

    1. navigationParams = create navigation params by fetching(request, entry, document의 node navigable, sourceSnapshotParams, targetSnapshotParams, "other", null(navigationId), "navigate", prefetchRecord prefetchRecord).

       여기 프리페치 시 사용된 navigable은 (즉, document의 node navigable) 활성화 시 실제 사용하는 것, 즉 최종적으로 프리페치 기록에서 탐색 매개변수 생성을 호출하는 탐색 알고리즘에 전달된 것과 다를 수 있음.

       이건 문제되지 않음. 프리페치 활성화로 이어지는 네비게이션 중 target navigable은 주요 검사를 할 때 사용되고, 히스토리 엔트리의 문서 채우기 시도 호출 전 과정에서 이미 검사가 끝남. 그리고 navigable이 프리페치 시 페치하여 탐색 매개변수 생성에 영향을 미치는 모든 방식을 살펴보면:

       • 프리페치 요청의 reserved client를 document의 node navigable에서 설정하는 것은 명백히 적절함.

         (reserved client의 유일 잠재 문제는 target browsing context임. 프리페치는 오직 최상위 traversable에서만 지원되고 client의 execution ready flag는 설정되지 않아 영향 제한.)

       • Cross-Origin-Resource-Policy 관련 검사는 해당되지 않음(최상위 traversable만 프리페치 지원).

       • Cross-Origin-Opener-Policy 검사는 프리페치가 아니라 활성화 시점에 수행.

       또한, 이 알고리즘 내에서 navigationParams는 단순히 프리페치 응답 래퍼 역할만 하며 장기 저장되지 않기 때문에, navigationParams의 navigable 값이 시스템에 노출되지 않음. 활성화 시엔 create navigation params from a prefetch record로 새 navigation params가 만들어져, 올바른 target navigable 포함.

    2. navigationParams의 response가 프리페치 지원이 아니면 navigationParams = null.

    3. prefetchRecord의 충돌 자격증명 존재가 true면 navigationParams를 null로.

       즉, 리다이렉트 체인 어느 한 크로스 파티션 오리진이라도 자격 증명이 있으면 프리페치가 폐기됨. 사용자가 로그인 상태임에도 로그아웃 페이지를 볼 위험을 줄임.

    4. 글로벌 태스크를 네트워킹 태스크 소스에 큐잉(global, 아래 내용):

       1. navigationParams가 navigation params 타입이 아니라면 취소 및 폐기(prefetchRecord, document) 및 중단.

       2. 단언: navigationParams의 response는 리다이렉트 체인 마지막 응답임.

       3. 프리페치 기록 완료(prefetchRecord, document).

1. status = response의 status.

2. 단언: status가 리다이렉트 status가 아님.

3. status가 ok status가 아니면 false 반환.

   즉, 오류 응답은 저장되지 않고 탐색 실행 시 다시 시도됨. 이는 오류가 일시적이거나 프리페치로 인해 발생 시 성공 가능성을 높여줌. 또 prefetch를 명시하는 Sec-Purpose 헤더가 있을 때 서버가 요청 거절 쉽게 하도록 함.

4. true 반환.

1. isolatedCookieStore를 isolatedPartitionKey에 연관된 쿠키 저장소로 둡니다.

2. 쿠키 cookie를 isolatedCookieStore에서 반복합니다.

   1. cookie를 isolatedCookieStore에서 제거합니다.

   2. 사용자 에이전트는 쿠키를 완전히 무시할 수 있습니다. 그런 경우 continue.

      이는 [COOKIES] 에서 쿠키 수신시에 이 동작을 허용하기 때문입니다.

   3. topLevelSite를 null로 둡니다.

   4. environment의 target browsing context가 최상위 브라우징 컨텍스트라면:

      1. topLevelSite를 사이트 획득 결과값으로 둡니다. 인자는 튜플 오리진("https", cookie의 domain, null, null).

         여기서 "https" 스킴과 null 포트는 관례상 선택된 것으로, 실제로 쿠키는 스킴 및 포트에 구애받지 않으므로 쿠키 저장소 연결에는 영향이 없습니다.
      최상위 브라우징 컨텍스트에서 프리페치를 할 때(리다이렉트 포함), 해당 요청은 최상위 네비게이션 준비를 의미합니다. environment의 최상위 사이트는 리다이렉트 따라 변경될 수 있지만, 탐색이 최상위일 경우 쿠키를 전달하는 오리진이 바로 그 시점의 최상위 사이트입니다. 쿠키의 domain이 해당 오리진과 same-site여야 하므로, 이를 통해 올바른 최상위 사이트를 결정할 수 있습니다.

   5. 그렇지 않으면:

      1. topLevelOrigin을 environment의 최상위 오리진으로 둡니다.

      2. topLevelOrigin이 null이면, environment의 최상위 생성 URL의 오리진으로 설정.

      3. 단언: topLevelOrigin은 오리진임.

      4. topLevelSite = 사이트 획득(topLevelOrigin) 결과로 설정.

      child navigable에서 프리페치 처리 시, 최상위 사이트는 자신을 포함하는 최상위 traversable로 정해집니다. 이는 리다이렉트로도 변하지 않으므로 environment로 판단 가능합니다.

   6. secondKey를 null 또는 구현자 정의 값으로 둡니다.

      secondKey는 이 응답이 environment의 대상 브라우징 컨텍스트에서 일반 탐색의 일부로 처리되었을 때의 값과 같아야 합니다.

   7. destinationPartitionKey = (topLevelSite, secondKey)로 설정합니다.

   8. cookieStore를 destinationPartitionKey와 연결된 쿠키 저장소로 둡니다.

   9. newCookie를 cookie 복제본으로 만듭니다.

   10. newCookie의 생성 시간과 마지막 접근 시간을 현재 날짜/시간으로 설정합니다.

   11. cookieStore에 같은 이름, 도메인, 경로를 가진 existingCookie가 있다면:

       1. newCookie의 생성 시간을 existingCookie의 생성 시간으로 맞춥니다.

       2. existingCookie를 cookieStore에서 제거합니다.

   12. newCookie를 cookieStore에 삽입합니다.

       이와 같이 remove 후 insert하는 패턴은 쿠키 수신 처리와 같습니다.

1. params를 speculation.PrefetchStatusUpdatedParameters 타입 맵으로 만들고, context 필드를 navigable의 최상위 traversable의 navigable id로, url 필드를 prefetchRecord의 URL로, status 필드를 preloadingStatus로 설정.

2. body를 speculation.PrefetchStatusUpdatedParameters 타입의 맵으로 만들고, params 필드를 params로 설정.

3. relatedNavigables를 navigable을 포함한 set으로 둠.

4. "speculation.prefetchStatusUpdated" 이벤트와 relatedNavigables에 대해 이벤트가 활성화된 세션 집합의 각 session을 반복:

   1. 이벤트 emit(session, body).