프리페치

커뮤니티 그룹 초안 보고서,

이 버전:
https://wicg.github.io/nav-speculation/prefetch.html
이슈 추적:
GitHub
명세 내 인라인
편집자:
(Google)
(Google)

초록

탐색 프리페칭을 위한 명세

문서 상태

이 명세는 웹 플랫폼 인큐베이터 커뮤니티 그룹에서 발행하였습니다. W3C 표준이 아니며, W3C 표준 트랙에도 포함되어 있지 않습니다. W3C 커뮤니티 기여자 라이선스 계약 (CLA)에 따라 제한적 옵트아웃 및 기타 조건이 적용됩니다. W3C 커뮤니티 및 비즈니스 그룹에 대해 더 알아보세요.

1. 개념

스토리지 파티셔닝을 고려하여, 이 명세는 동일 파티션 내에서 발생하는 탐색(예: 동일 사이트 내 최상위 탐색)과 별도 파티션에서 발생하는 탐색(예: 다른 사이트로의 최상위 탐색)에 대한 프리페치를 정의합니다.

충돌하는 자격 증명이 존재한다 response response에게 navigable navigable네트워크 파티션 키 sourcePartitionKey를 주었을 때 아래 단계가 true를 반환하면:
  1. hypotheticalEnvironment예약 클라이언트 생성하기의 결과로 생성한다. 매개값으로 navigable, responseURL, 그리고 null을 전달한다.

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

  3. 만약 hypotheticalPartitionKeysourcePartitionKey와 같거나, 자격 증명URLhypotheticalPartitionKey를 기준으로 연관되지 않은 경우 false를 반환한다.

  4. true를 반환한다.


교환 기록구조체이며, 다음 항목들을 가집니다:

이 기록들은 원래는 navigate fetch 과정에서 수행되는 검사들을 지연시킬 때, 혹은 자격 증명이 변경되었는지를 검사하는 데 사용할 수 있습니다.

리다이렉트 체인리스트 형태의 교환 기록입니다.

업데이트리다이렉트 체인 redirectChain, request request, response response가 주어졌을 때 실행합니다:
  1. 단언: redirectChain비어있지 않음입니다.

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

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

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

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

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


Document 객체는 프리페치 기록을 가지며, 이는 리스트 형태의 프리페치 기록입니다.

프리페치 기록구조체이며, 다음 항목들을 가집니다:

이 구조체는 프리페치 시작부터 실제 사용 또는 폐기까지의 상태를 추적합니다. 그 결과, 일부 필드는 불변이고, 일부는 현재 진행 중인 작업에 관한 것이며(fetch controller 등), 그리고 일부는 프리페치가 완료될 때 채워집니다(만료 시간 등).

자격 증명을 원래 전송했어야 했지만, 크로스 파티션 프리페치로 인해 전송할 수 없을 때 프리페치는 폐기됩니다.

프리페치 기록response는 그 redirect chain의 마지막 요소의 response이거나, 그 리스트가 비어있으면 null입니다.

사용자 에이전트는 프리페치 기록 취소 및 폐기프리페치 기록에서 만료되지 않았더라도(자원 제약 등으로 인해) 할 수 있습니다. 완료된 기록 중 만료 시간이 지난 기록은 프리페치 검색 대상이 아니므로, 삭제해도 문제가 없습니다.

프리페치 기록 prefetchRecordURL에 매칭된다는 아래 알고리즘이 true를 반환할 때입니다:
  1. prefetchRecordURLurl과 같으면 true를 반환한다.

  2. prefetchRecordresponse가 null이 아니라면:

    1. searchVarianceURL 검색 변동성 얻기prefetchRecordredirect chain[0]의 response에 대해 실행한 결과로 설정한다.

      첫 response(prefetchRecordresponse가 아니라)의 No-Vary-Search 헤더만 매칭에 영향을 주므로, 꼭 0번째 response를 체크해야 합니다.

    2. prefetchRecordURLurl검색 변동성 기준으로 동등(equivalent modulo search variance)하면 true를 반환한다.

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

프리페치 기록 prefetchRecordURL에 매칭될 것으로 예상된다는 아래 알고리즘이 true를 반환할 때입니다:
  1. prefetchRecordURL에 매칭된다면 true를 반환한다.

  2. prefetchRecordresponse가 null일 경우:

    1. searchVarianceprefetchRecordNo-Vary-Search 힌트로 한다.

    2. prefetchRecordURLurl검색 변동성 기준으로 동등하면 true 반환.

  3. 그 외에는 false 반환.

프리페치 기록 취소 및 폐기프리페치 기록 prefetchRecordDocument document가 주어졌을 때 아래를 수행합니다.
  1. 단언: prefetchRecorddocument프리페치 기록에 포함되어 있음.

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

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

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

  5. prefetchRecordprerendering traversabletraversable navigable이면 파괴(destroy)한다.

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

  7. 프리페치 상태 갱신 이벤트 트리거documentnode navigable, prefetchRecord, 그리고 "실패" 상태로 호출한다.

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

프리페치 기록 완료프리페치 기록 prefetchRecordDocument document가 주어졌을 때 아래를 수행합니다.
  1. 단언: document완전히 활성화됨.

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

  3. expiryTimecurrentTime + 300000(즉, 5분)으로 설정.

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

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

  6. 프리페치 상태 갱신 이벤트 트리거documentnode navigable, prefetchRecord, 그리고 "준비됨" 상태로 호출.

완료된 프리페치 기록 찾기최상위 traversable navigable, source snapshot params sourceSnapshotParams, URL url가 주어졌을 때:
  1. exactRecord를 null로 초기화.

  2. inexactRecord를 null로 초기화.

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

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

    2. recordURLurl과 같다면:

      1. exactRecordrecord로 설정.

      2. 반복 종료.

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

      1. inexactRecordrecord로 설정.

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

  5. recordToUse가 null이 아니면:

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

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

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

      2. null 반환.

    3. exchangeRecord에 대해 recordToUseredirect chain에서 반복:

      1. 충돌하는 자격 증명이 존재하면, exchangeRecordresponse, navigable, recordToUsesource partition key를 기준으로:

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

        2. null 반환.

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

  6. null 반환.

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

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

일치하는 프리페치 기록 대기최상위 traversable navigable, source snapshot params sourceSnapshotParams, URL url가 주어졌을 때:
  1. 단언: 병렬로 실행중인지 확인(in parallel).

  2. timeout을 null로 초기화.

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

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

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

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

    1. 반복:

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

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

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

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

        1. 아래 모두 true이면:

          조건 충족 시 리스트에 추가: recordpotentialRecords에 추가.

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

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

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

  6. null 반환.

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

프리페치 기록 prefetchRecord아직 추측 중인 경우는 추측적 로드 후보 리스트 candidates에 대해서 아래 단계가 true를 반환하면 해당합니다:
  1. candidatecandidates에서 반복:

    1. prefetchRecordURL에 매칭되지 않으면 candidateURL에 대해 다음으로 계속.

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

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

    4. true 반환.

  2. false 반환.

Document document매칭되는 프리페치 기록을 가진다프리페치 기록 recordUnderConsideration과 선택적 boolean checkPrerender (기본값 false)가 주어졌을 때 아래 알고리즘이 true를 반환하면 해당합니다:
  1. recorddocument프리페치 기록에서 반복:

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

    2. checkPrerender가 true이면:

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

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

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

    3. recordNVS를 null로 둡니다.

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

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

    6. recordUnderConsiderationNo-Vary-Search 힌트recordNVS와 다르면 다음으로 계속.

    7. recordUnderConsiderationURLrecordURL검색 변동성 기준으로 동등(recordUnderConsiderationNo-Vary-Search 힌트 기준)이면 true 반환.

  2. false 반환.

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

프리페치 기록에서 네비게이션 파라미터 생성최상위 traversable navigable, 문서 상태 documentState, navigation id navigationId, NavigationTimingType navTimingType, request request, 프리페치 기록 record, target snapshot params targetSnapshotParams, source snapshot params sourceSnapshotParams로 아래 단계 수행.
  1. responseOrigin을 null로.

  2. responseCOOP을 null로.

  3. coopEnforcementResult탐색용 COOP enforcement 결과 생성의 결과로 함. navigableactive document, documentStateinitiator origin 사용.

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

  5. responsePolicyContainer를 null로.

  6. urlList를 빈 리스트로.

  7. responserecordresponse로.

  8. exchangeRecord에 대해 recordredirect chain 반복:

    1. redirectChainRequestexchangeRecordrequest로.

    2. redirectChainResponseexchangeRecordresponse로.

    3. 추가: redirectChainRequestURLurlList에.

    4. responsePolicyContainerfetch response로 정책 컨테이너 만들기 결과로 설정. redirectChainResponse, redirectChainRequestreserved client 사용.

    5. finalSandboxFlags합집합으로, targetSnapshotParams샌드박스 플래그responsePolicyContainerCSP listCSP 파생 샌드박스 플래그.

    6. responseOriginorigin 결정 결과로, redirectChainResponseURL, finalSandboxFlags, documentStateinitiator origin, null 사용.

    7. responseCOOPcross-origin opener policy 획득 결과로, redirectChainResponse, redirectChainRequestreserved client 사용.

    8. coopEnforcementResultcross-origin opener policy enforcement 결과로 수정, navigableactive browsing context, redirectChainResponseURL, responseOrigin, responseCOOP, coopEnforcementResultredirectChainRequestreferrer 사용.

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

  9. requestURLurlList[0]과 다르면 requestURL0번째 항목 뒤에 urlList에 삽입.

    이 경우, 탐색은 requestURL로가지만, 프리페치는 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 »가 되어, 생성된 DocumentURL/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/ »가 되어, 최종 DocumentURLhttps://other.example/가 됨.

  10. requestURL 리스트urlList로 설정.

  11. requestreserved clientreserved client 생성 결과로, navigable, requestURL 사용.

    이 환경은 Document 등 생성에 쓰이는 environment settings object임. 프리페치 기록 소비 때마다 별도 환경 필요. 기록의 redirect chain 마지막 항목의 requestreserved client 쓰면 다중 탐색에서 id가 중복되어 혼동 유발.

  12. requestreserved clientactive service workerrecordredirect chain 마지막 항목의 requestreserved clientactive service worker로 설정.

    여기서 생성될 Document의 Service Worker로 프리페치 처리 중 최종 응답을 가로챈 SW 또는 탐색된 URL의 등록 SW 중 선택 가능. 대부분 같지만, No-Vary-Search+경로 별 SW 등록 시 다름.

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

  13. resultPolicyContainernavigation params 정책 컨테이너 결정 결과로, recordresponseURL, documentStatehistory policy container, sourceSnapshotParamssource policy container, null, responsePolicyContainer 사용.

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

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

      향후 프리페치가 프리렌더로 소비될 경우 등, 프리렌더 traversable이 삭제되어도 응답을 계속 쓰려면 클론 필요. [PRERENDERING-REVAMPED]

    2. 직전 단계를 하지 않았다면, 반드시 제거: recordnavigableactive 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

    requestreserved client

    navigable

    navigable

    navigation timing type

    navTimingType

    fetch controller

    recordfetch controller

    위 optional 단계를 수행하여 record가 다수 navigation params를 생성한 경우, 모든 navigation params에서 동일 fetch controller를 공유해도 무방. fetch controller는 navigation timing 정보 계산에만 쓰이므로 reuse해도 문제 없음.

    commit early hints

    null

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

    delivery type

    "navigational-prefetch"

프리페치 IP 익명화 정책 policy익명 필요인 경우는 request request에 대해 아래 단계가 true를 반환할 때 입니다:
  1. policy크로스 오리진 프리페치 IP 익명화 정책이면:

    1. requestURLoriginpolicyorigin동일이면 false 반환.

    2. true 반환.

  2. 단언: policy는 null.

  3. false 반환.

2. HTML 패치

이 섹션은 [HTML]에 대한 패치를 포함합니다.

environment에 다음 항목을 추가하세요:

is navigational prefetch client

boolean (기본값: false)

navigation params에 다음 항목을 추가하세요:

delivery type

string (PerformanceResourceTiming delivery type과 대응)

모든 생성 사이트를 업데이트하여 기본값으로 빈 문자열을 제공하세요. 단, 이 문서 내에서 다른 값을 제공하는 경우(create navigation params from a prefetch record)는 예외입니다.


source snapshot params에 다음 항목을 추가하세요:

prefetch records

list 형태의 prefetch records입니다.

snapshot source snapshot params 알고리즘을 수정하여 반환값의 prefetch recordssourceDocumentprefetch recordsclone으로 설정합니다.


이 내용은 create navigation params by fetching에서 추출되었습니다.

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

  1. topLevelCreationURL = url로 둡니다.

  2. topLevelOrigin = null로 둡니다.

  3. isolationOrigin이 null이 아니면:

    1. topLevelCreationURLabout:blank로 설정

    2. topLevelOriginisolationOrigin으로 설정

  4. 아니면, navigabletop-level traversable이 아니면:

    1. parentEnvironment = navigableparentactive documentrelevant settings object로 둡니다.

    2. topLevelCreationURL = parentEnvironmenttop-level creation URL로 설정.

    3. topLevelOrigin = parentEnvironmenttop-level origin으로 설정.

  5. 새로운 environment 반환: id는 고유 불투명 문자열, target browsing contextnavigableactive browsing context, creation URLurl, top-level creation URLtopLevelCreationURL, top-level origintopLevelOrigin.


이 내용은 create navigation params by fetching에서 추출되었습니다.

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

url

activeDocumentURL

origin

activeDocumentorigin

cross-origin opener policy

activeDocumentcross-origin opener policy

current context is navigation source

activeDocumentorigininitiatorOriginsame origin이면 true, 아니면 false


이 내용은 create navigation params by fetching에서 추출되었습니다.

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

  1. documentResource = entrydocument stateresource.

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

    url

    entryURL

    policy container

    entrydocument statehistory policy container

    client

    fetchClient

    destination

    "document"

    credentials mode

    "include"

    use-URL-credentials flag

    설정됨

    redirect mode

    "manual"

    mode

    "navigate"

    referrer

    entrydocument staterequest referrer

    referrer policy

    entrydocument staterequest referrer policy

  3. documentResourcePOST resource이면:

    1. requestmethod`POST`로 설정.

    2. requestbodydocumentResourcerequest body로 설정.

    3. Set `Content-Type`documentResourcerequest content-type으로 requestheader list에 설정.

  4. entrydocument statereload pending이 true면, requestreload-navigation flag를 설정.

  5. 아니면 entrydocument stateever populated가 true면, requesthistory-navigation flag를 설정.

  6. hasTransientActivation이 true면, requestuser-activation을 true로.

  7. container가 null이 아니면:

    1. containerbrowsing context scope origin이 있으면 requestorigin을 해당 browsing context scope origin으로 설정.

    2. requestdestinationinitiator typecontainerlocal name으로 설정.

  8. request 반환.


히스토리 엔트리의 문서 채우기 시도에서 create navigation params by fetching을 호출하는 단계를 다음으로 대체합니다:
  1. 아래 두 조건 모두 true면:

    • entryURLschemefetch scheme인 경우

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

    이면:

    1. request = create a navigation request 결과. 인자: entry, sourceSnapshotParamsfetch client, navigablecontainer, sourceSnapshotParamshas transient activation.

    2. requestreplaces client id = navigableactive documentrelevant settings objectid로 설정.

    3. prefetched = false로 둠.

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

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

      2. prefetchRecord가 null이 아니면:

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

        2. Copy prefetch cookies: prefetchRecordisolated partition key, navigationParamsreserved 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 알고리즘의 업데이트입니다.

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. 단언: requestURLentryURL임.

  3. 단언: requestmode가 "navigate"임.

  4. 단언: requestredirect mode가 "manual"임.

  5. 단언: requestreserved client가 null임.

  6. response를 null로 둔다.

  7. responseOrigin을 null로 둔다.

  8. fetchController를 null로 둔다.

  9. coopEnforcementResult탐색용 교차 오리진 오프너 정책 강제 결과 생성의 결과로 설정 navigableactive documententrydocument stateinitiator origin 사용.

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

  11. responsePolicyContainer를 null로 둔다.

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

  13. locationURL을 null로 둔다.

  14. currentURLrequestcurrent URL로 둔다.

  15. commitEarlyHints를 null로 둔다.

  16. isolationOrigin을 null로 둔다.

  17. prefetchRecord가 주어졌다면:

    1. isolationSiteprefetchRecord격리된 파티션 키[0]로 둔다.

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

    3. isolationOriginisolationSite로 설정.

  18. while true:

    1. requestreserved client가 null이 아니고 currentURLoriginrequestreserved clientcreation URLorigin과 다르면:

      1. environment 폐기 절차requestreserved client에 대해 실행.

      2. requestreserved client를 null로.

      3. commitEarlyHints를 null로.

    2. requestreserved client가 null이면:

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

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

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

    4. prefetchRecord가 주어졌다면:

      1. purposeList(Token prefetch 포함)로 둔다.

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

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

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

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

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

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

        구현체는 vendor별 헤더(Purpose/prefetch, X-moz/prefetch, X-Purpose/preview 등)도 전송할 수 있음. 시간이 지나면 이 표준 헤더로 통합 기대.
      5. requestcurrent URLoriginsame site인 경우 prefetchRecordURLorigin과 비교:

        1. tagsprefetchRecordtags 각각을 item 별로 문자열/Token 변환해 List 생성.

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

      6. requestcurrent URL잠재적으로 신뢰할 수 있는 URL이 아니다? responsenetwork error로 하여 break.

        프리페치 트래픽이 공격자에게 노출되는 걸 막고, 공용망에서 암호화 스킴 사용을 유도하기 위함.
      7. proposedPartitionKey네트워크 파티션 키 결정(requestreserved client) 결과로 둔다.

      8. proposedPartitionKeyprefetchRecordsource partition key와 다르고 requestreferrer policy충분히 엄격한 추론형 네비 referrer 정책 목록에 없다면 responsenetwork errorbreak.

        즉, 교차사이트 프리페치는 origin 이상 referrer 노출 막음.
      9. requestprefetchRecord익명화 정책으로 fetch 불가 시 responsenetwork errorbreak.

        구현체별로 더욱 제약 있을 수 있음, 예: 공개 라우팅 안되는 호스트·private prefetch 거부 호스트 등
      10. 추가: 새 exchange record(request, response=null) 를 prefetchRecordredirect chain에.

    5. response를 null로 둔다.

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

      processEarlyHintsResponse 알고리즘 (earlyResponse):

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

      processResponse 알고리즘(fetchedResponse):

      1. response = fetchedResponse로 한다.

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

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

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

    9. requestbody가 null이면 entrydocument stateresource를 null로.

    10. responsePolicyContainerfetch 응답에서 정책 컨테이너 생성(response, requestreserved client)으로 둔다.

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

    12. responseOrigin오리진 결정(response의 URL, finalSandboxFlags, entrydocument stateinitiator origin, null)으로 둔다.

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

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

      2. coopEnforcementResult응답의 교차 오리진 오프너 정책 강제(navigableactive browsing context, requestURL, responseOrigin, responseCOOP, coopEnforcementResult, requestreferrer) 결과로 한다.

      3. finalSandboxFlags이 비어있지 않고 responseCOOPvalue가 "unsafe-none"이 아니면 responsenetwork error로 하고 break.

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

    14. responsenetwork error가 아니고 navigablechild navigable이며 cross-origin resource policy check(navigablecontainer documentorigin, navigablecontainer documentrelevant settings object, requestdestination, response, true)이 blocked면 responsenetwork error로 하고 break.

    15. prefetchRecord가 주어졌다면:

      1. Update prefetchRecordredirect chain(request, response).

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

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

    16. locationURLresponselocation URL(currentURLfragment)로 한다.

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

    18. 단언: locationURLURL임.

    19. entryserialized stateStructuredSerializeForStorage(null)로 한다.

    20. oldDocStateentrydocument state로 한다.

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

      history policy container

      oldDocStatehistory policy container 복제

      request referrer

      oldDocStaterequest referrer

      request referrer policy

      oldDocStaterequest referrer policy

      origin

      oldDocStateorigin

      resource

      oldDocStateresource

      ever populated

      oldDocStateever populated

      navigable target name

      oldDocStatenavigable target name

    22. locationURLschemeHTTP(S) scheme이 아니라면:

      1. entrydocument stateresource를 null로.

      2. break.

    23. currentURLlocationURL로 한다.

    24. entryURLcurrentURL로 한다.

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

    initiator origin

    requestcurrent URLorigin

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

    null 반환
  21. resultPolicyContainer네비게이션 파라미터 정책 컨테이너 결정 결과로 (responseURL, entrydocument statehistory policy container, sourceSnapshotParamssource policy container, null, responsePolicyContainer 인자).

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

    id

    navigationId

    request

    request

    response

    response

    origin

    responseOrigin

    policy container

    resultPolicyContainer

    최종 샌드박스 플래그 집합

    finalSandboxFlags

    교차 오리진 오프너 정책

    responseCOOP

    COOP 강제 결과

    coopEnforcementResult

    예약 environment

    requestreserved client

    navigable

    navigable

    navigation timing type

    navTimingType

    fetch controller

    fetchController

    early hints 커밋

    commitEarlyHints


Document 객체 생성 및 초기화 단계에 내비게이션 타이밍 엔트리 생성의 추가 인자를 아래와 같이 포함: navigationParamsdelivery type.

탐색 응답에 사용할 브라우징 컨텍스트 획득 단계에서 sourceOriginsame site가 아닌지 검사할 때, 다음 하위 단계를 삽입:
  1. navigationParamsdelivery type이 "prefetch"이면 swapGroup을 true로 설정(옵션).

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

이 섹션은 [NAVIGATION-TIMING]에 대한 패치를 포함합니다.

내비게이션 타이밍 엔트리 생성string deliveryType 매개변수를 추가하고, 리소스 타이밍 엔트리 설정에 추가 인자로 넘깁니다.

4. 서비스 워커 패치

이 섹션은 [SERVICE-WORKERS]에 대한 패치를 포함합니다.

Fetch 이벤트 생성 및 디스패치에서 resultingClientId 를 설정하는 단계를 아래와 같이 변경:
request비서브리소스 요청이고 requestdestination이 "report"가 아니며 그리고 reservedClientis navigational prefetch client가 false인 경우 eresultingClientId 속성을 reservedClientid로, 그 외에는 빈 문자열로 초기화.

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

5. 사이트 데이터 지우기 패치

Clear Site Data § 3.1 The Clear-Site-Data HTTP Response Header Field에 아래 헤더 값 설명을 추가하세요:

"prefetchCache"

"prefetchCache" 타입은 서버가 특정 originresponseURL에 의해 시작된 모든 프리페치를 제거하고자 함을 나타냅니다.

이 타입은 "cache" 타입의 부분집합입니다.

구현 세부사항은 아래를 참조하세요.

parse response’s Clear-Site-Data header의 파싱 단계에서 아래와 같이 수정하세요:

clear site data for response의 switch 문에 "prefetchCache"를 처리하는 케이스를 추가하고, clear prefetch cacheorigin에 대해 실행하세요.

프리페치 캐시 삭제는 아래와 같이 origin origin를 인자로 합니다:
  1. 최상위 traversable traversable에 대해, 사용자 에이전트의 최상위 traversable set에서 반복:

    1. navigables포함 자손 navigables로, traversableactive document 기준으로.

    2. navigablenavigables에서 반복:

      1. activeDocumentnavigableactive document로 둡니다.

      2. activeDocumentoriginoriginsame origin이 아니면 다음으로 계속.

      3. prefetchRecordactiveDocumentprefetch records에서 반복:

        1. prefetchRecordprerendering traversable이 null이 아니면 다음으로 계속.

        2. 취소 및 폐기prefetchRecord, activeDocument 인자로 실행.

6. 프리페치 알고리즘

충분히 엄격한 추측 네비게이션 리퍼러 정책 목록은 다음 값을 포함한 리스트입니다: "", "strict-origin-when-cross-origin", "strict-origin", "same-origin", "no-referrer".

리퍼러 기반 네비게이션 프리페치 시작Document documentprefetch record prefetchRecord가 주어졌을 때 아래 순서를 따릅니다.
  1. 단언: documentnode navigable최상위 traversable임.

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

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

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

  4. targetSnapshotParams = target snapshot params 스냅샷(documentnode navigable).

  5. prefetchRecordsource partition key네트워크 파티션 키 결정(documentrelevant settings object)로 설정.

  6. 단언: prefetchRecordURLschemeHTTP(S) scheme임.

  7. 추가: prefetchRecorddocumentprefetch records에.

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

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

  10. referrerPolicy = prefetchRecordreferrer policy가 빈 문자열이 아니면 그 값, 아니면 documentpolicy containerreferrer policy.

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

    request referrer policy

    referrerPolicy

    initiator origin

    documentorigin

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

    URL

    prefetchRecordURL

    document state

    documentState

  13. request = 네비게이션 요청 생성(entry, documentrelevant settings object, documentnode navigablecontainer, false).

  14. global = documentrelevant global object.

  15. 병렬로 수행:

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

      여기 프리페치 시 사용된 navigable은 (즉, documentnode navigable) 활성화 시 실제 사용하는 것과 다를 수 있음.

      이건 문제되지 않음. 프리페치 활성화로 이어지는 네비게이션 중 target navigable은 주요 검사를 할 때 사용되고, 히스토리 엔트리의 문서 채우기 시도 호출 전 과정에서 이미 검사가 끝남.

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

    2. navigationParamsresponse프리페치 지원이 아니면 navigationParams = null.

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

      즉, 리다이렉트 체인 어느 한 크로스 파티션 오리진이라도 자격 증명이 있으면 프리페치가 폐기됨. 사용자가 로그인 상태임에도 로그아웃 페이지를 볼 위험을 줄임.
    4. 글로벌 태스크를 네트워킹 태스크 소스에 큐잉(global, 아래 내용):

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

      2. 단언: navigationParamsresponse리다이렉트 체인 마지막 응답임.

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

response response프리페치 지원하는 경우는 아래 단계가 true를 반환할 때입니다:
  1. status = responsestatus.

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

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

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

103은 ok status가 아니지만 early hints는 프리페치를 막지 않음. supports prefetch 판정은 실제 response에서만 쓰이며, 1xx status는 오지 않음.

단, 다른 곳에서 언급했다시피 현재 프리페치 시 early hints는 무시됨.

7. 쿠키

[COOKIES] 는 `Set-Cookie` 응답 헤더 필드를 사용하여 설정할 수 있는 "쿠키"를 정의합니다. "uncredentialed" 파티셔닝 방식을 사용하면 별도의 네트워크 파티션 키가 적용되기 때문에, 이러한 쿠키를 탐색 시점에서 수신된 것처럼 일반 파티션에 복사하는 처리가 필요합니다.

정확성에는 꼭 필요하지 않지만 캐시도 복사하면 도움이 됩니다.
교차 사이트 상황에서 인증 정보가 획득될 수 있습니다(예: 리다이렉트 대상으로 URL 인증정보 포함시). 이 또한 복사 가능하겠지만 반드시 권장하는지 불확실합니다.
프리페치 쿠키 복사네트워크 파티션 키 isolatedPartitionKeyenvironment environment가 주어졌을 때 아래 절차를 따릅니다.
포멀하게 쿠키 저장소는 [COOKIES] 기준으로 하나이지만 실제 일부 브라우저는 사이트별로 쿠키를 파티셔닝합니다. 예를 들어, 동일 도메인 쿠키라도 최상위 사이트가 다르면 분리될 수 있습니다. 참고: Client-Side Storage Partitioning (Privacy CG).
  1. isolatedCookieStoreisolatedPartitionKey에 연관된 쿠키 저장소로 둡니다.

  2. 쿠키 cookieisolatedCookieStore에서 반복합니다.

    1. cookieisolatedCookieStore에서 제거합니다.

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

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

    4. environmenttarget browsing context최상위 브라우징 컨텍스트라면:

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

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

      1. topLevelOriginenvironment최상위 오리진으로 둡니다.

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

      3. 단언: topLevelOrigin오리진임.

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

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

      secondKey는 이 응답이 일반 네비게이션 처리일 경우와 동일하게 처리될 수 있도록 예상 값을 갖습니다.
    7. destinationPartitionKey = (topLevelSite, secondKey)로 설정합니다.

    8. cookieStoredestinationPartitionKey와 연결된 쿠키 저장소로 둡니다.

    9. newCookiecookie 복제본으로 만듭니다.

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

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

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

      2. existingCookiecookieStore에서 제거합니다.

    12. newCookiecookieStore에 삽입합니다.

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

8. `Sec-Purpose` HTTP 요청 헤더

이 섹션은 Sec-Purpose HTTP 요청 헤더의 [FETCH] 정의를 오버라이드합니다.

`Sec-Purpose` HTTP 요청 헤더는 해당 요청이 즉시 사용자에게 리소스를 제공하지 않고 다른 목적을 위해 사용된다는 것을 지정합니다.

헤더 필드는 [RFC9651]의 Structured Header이며 값은 List 타입이어야 합니다.

구성원 중 ItemToken prefetch라면, 곧 요청될 것으로 예상되는 리소스 다운로드 목적으로 사용됨을 의미합니다.

prefetch 토큰의 매개변수 정의:

9. 자동화 테스트

사용자 에이전트 자동화 및 애플리케이션 테스트를 위해, 본 문서는 [WebDriver-BiDi] 명세에 대한 확장 규정도 포함합니다.

CDDL 스니펫은 "browsingContext.BrowsingContext" 대신 "text" 타입을 사용하여 CDDL 스니펫을 독립적으로 프로그래밍 처리 할 수 있게 합니다. 현재는 다른 모듈 참조가 불가능합니다.

9.1. speculation 모듈

speculation 모듈은 프리페치, 프리렌더, 추측 규칙의 remote end 처리를 관리하는 명령을 포함합니다.

9.1.1. 정의

local end definition

speculation.PreloadingStatus = "pending" / "ready" / "success" / "failure"

speculation.PreloadingStatus 타입은 프리로딩 상태 종류를 표기합니다. 프리페치와 프리렌더에 대해 공통적으로 사용됩니다.

"pending"
prefetch 기록 prefetchRecord리퍼러 기반 네비게이션 프리페치 시작 단계로 진입.
"ready"
prefetch 기록 prefetchRecord완료됨.
"success"
prefetch 기록 prefetchRecord가 사용자 에이전트의 네비게이션 등으로 활성화됨.
"failure"
prefetch 기록 prefetchRecord가 만료 등으로 실패함.

9.1.2. 이벤트

SpeculationEvent = (
  speculation.PrefetchStatusUpdated
)
9.1.2.1. speculation.prefetchStatusUpdated 이벤트
speculation.PrefetchStatusUpdated = (
   method: "speculation.prefetchStatusUpdated",
   params: speculation.PrefetchStatusUpdatedParameters
)

speculation.PrefetchStatusUpdatedParameters = {
   context: text,
   url: text,
   status: speculation.PreloadingStatus
}
speculation.prefetchStatusUpdated 이벤트 트리거navigable navigable, prefetch 기록 prefetchRecord, speculation.PreloadingStatus preloadingStatus가 주어졌을 때 다음 절차로 실행합니다:
  1. paramsspeculation.PrefetchStatusUpdatedParameters 타입 맵으로 만들고, context 필드를 navigable최상위 traversablenavigable id로, url 필드를 prefetchRecordURL로, status 필드를 preloadingStatus로 설정.

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

  3. relatedNavigablesnavigable을 포함한 set으로 둠.

  4. "speculation.prefetchStatusUpdated" 이벤트가 enable된 relatedNavigables에 대해 session 반복:

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

10. 보안 고려 사항

자세한 내용은 HTML § 7.6.5 보안 고려 사항 참고.

11. 개인정보 고려 사항

자세한 내용은 HTML § 7.6.6 개인정보 고려 사항 참고.

색인

이 명세서에 정의된 용어

참조로 정의된 용어

참고문헌

규범 참고문헌

[CLEAR-SITE-DATA]
Mike West. Clear Site Data. URL: https://w3c.github.io/webappsec-clear-site-data/
[COOKIES]
A. Barth. HTTP State Management Mechanism. April 2011. Proposed Standard. URL: https://httpwg.org/specs/rfc6265.html
[CSP]
Mike West; Antonio Sartori. Content Security Policy Level 3. URL: https://w3c.github.io/webappsec-csp/
[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HR-TIME-3]
Yoav Weiss. High Resolution Time. URL: https://w3c.github.io/hr-time/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[NAVIGATION-TIMING-2]
Yoav Weiss; Noam Rosenthal. Navigation Timing Level 2. URL: https://w3c.github.io/navigation-timing/
The No-Vary-Search HTTP Response Header Field. Editor's Draft. URL: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-no-vary-search
[PRERENDERING-REVAMPED]
Prerendering Revamped. Draft Community Group Report. URL: https://wicg.github.io/nav-speculation/prerendering.html
[REFERRER-POLICY]
Jochen Eisinger; Emily Stark. Referrer Policy. URL: https://w3c.github.io/webappsec-referrer-policy/
[RESOURCE-TIMING]
Yoav Weiss; Noam Rosenthal. Resource Timing. URL: https://w3c.github.io/resource-timing/
[RFC8610]
H. Birkholz; C. Vigano; C. Bormann. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures. June 2019. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8610
[RFC9651]
M. Nottingham; P-H. Kamp. Structured Field Values for HTTP. September 2024. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9651
[SECURE-CONTEXTS]
Mike West. Secure Contexts. URL: https://w3c.github.io/webappsec-secure-contexts/
[SERVICE-WORKERS]
Monica CHINTALA; Yoshisato Yanagisawa. Service Workers Nightly. URL: https://w3c.github.io/ServiceWorker/
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WebDriver-BiDi]
James Graham; Alex Rudenko; Maksim Sadym. WebDriver BiDi. URL: https://w3c.github.io/webdriver-bidi/

비규범 참고문헌

[CONSOLE]
Dominic Farolino; Robert Kowalski; Terin Stock. Console Standard. Living Standard. URL: https://console.spec.whatwg.org/
[NAVIGATION-TIMING]
Zhiheng Wang. Navigation Timing. 17 December 2012. REC. URL: https://www.w3.org/TR/navigation-timing/

CDDL 색인

이슈 색인

캐시 응답 헤더를 사용해서 응답이 여러 번 사용 가능한지 판단하는 것도 가능할 수 있으나, 프리페치 버퍼의 수명이 짧은 점을 고려하면 가치가 있을지 불확실합니다.
현재 IP 익명화의 구체 구현 방식은 정해져 있지 않습니다. 아마도 proxy 또는 relay를 사용하는 구현자 정의 방식을 쓸 가능성이 높습니다. 이상적으로는 연결 획득까지 연동되며, 추가로 메커니즘 표준화도 가능성이 있습니다.
프리페치는 탐색이 시작되면 즉시 중단됩니다. 이는 바람직하지 않을 수 있습니다.
정확성에는 꼭 필요하지 않으나 캐시도 복사하면 도움이 됩니다.
교차 사이트 상황에서 인증 정보가 획득될 수 있습니다(예: 리다이렉트 대상으로 URL 인증정보 포함시). 이 또한 복사 가능하겠지만 반드시 권장하는지 불확실합니다.
CDDL 코드 조각은 "browsingContext.BrowsingContext" 대신 "text" 타입을 사용하여 CDDL 코드 조각을 독립적으로 프로그래밍 처리할 수 있게 합니다. 현재는 다른 모듈 참조가 불가능합니다.