Ogólne#

Fetch#

W tym miejscu umieszczam powtarzające się specyficzne pojęcia i algorytmy w dziale FETCH, czyli mogą mieć one zastosowanie dla wszystkich interfejsów z tego działu.

Infrastructure#

Niektóre terminy użyte w specyfikacji fetch są definiowane przez standardy Encoding, URL oraz HTML.

Sekwencja bajtów z bajtami w zakresie 0x00 do 0x7F jest reprezentowana przez łańcuch znaków zakodowany w utf-8, z punktami kodowymi w zakresie U+0000 do U+007F. Aby uniknąć nieporozumień między zapisem sekwencji bajtów i łańcuchów znakowych, to przy zapisie sekwencji bajtów stosowane są odwrócone apostrofy.

Następujący zapis "true" jest łańcuchem znakowym, kiedy zapis `true` jest sekwencją bajtów.

byte case-insensitive

Porównanie dwóch sekwencji bajtów pod względem nieczułości na wielkości znaków bajtu # (byte case-insensitive) oznacza ich dokładne porównanie, tj. bajt do bajtu, z wyjątkiem bajtów w zakresie 0x41 do 0x5A, które uważa się za zgodne z ich odpowiadającymi bajtami w zakresie 0x61 do 0x7A.

case-insensitive byte sequence

Sekwencja bajtów nieczuła na wielkość znaków # (case-insensitive byte sequence) jest sekwencją bajtów, której porównanie z inną sekwencją bajtów odbywa się pod względem nieczułości na wielkość znaków bajtu.

Następujące sekwencje bajtów nieczułe na wielkość znaków `Content-Type` i `content-TYPE` są równoważne.

byte lowercase

Aby zamienić bajt na małe znaki # (byte lowercase) w sekwencji bajtów należy zwiększyć każdy bajt z sekwencji bajtów będący w zakresie 0x41 do 0x5A o 0x20.

byte lowercase

Aby zamienić bajt na duże znaki # (byte uppercase) w sekwencji bajtów należy zmniejszyć każdy bajt z sekwencji bajtów będący w zakresie 0x61 do 0x7A o 0x20.

queue a fetch task

Aby zakolejkować zadanie feczu # (queue a fetch task) na żądaniu request w celu uruchomienia operacji run an operation należy zakolejkować zadanie dla run an operation na responsywnej pętli zdarzeń skojarzonej z klientem w request z użyciem sieciowego źródła zadań.

HTTP#

Kiedy feczowanie obejmuje więcej niż tylko HTTP, to zapożycza wiele pojęć z HTTP i stosuje je do zasobów o innym znaczeniu (np. dla adresów URL ze schematem data).

Methods#
method

Metoda # (method) to sekwencja bajów, która pasuje do wzorca słowa Method.

simple method

Metoda prosta # (simple method) to metoda, którą jest `GET`, `HEAD` lub `POST`.

forbidden method

Metoda zabroniona # (forbidden method) to metoda, której porównanie pod względem nieczułości na wielkości znaków bajtu pasuje do `CONNECT`, `TRACE` lub `TRACK` (zgodnie z wymienionymi materiałami).

normalize

Aby znormalizować # (normalize) daną metodę jeśli pasuje ona pod względem nieczułości na wielkości znaków bajtu do `DELETE`, `GET`, `HEAD`, `OPTIONS`, `POST` lub `PUT`, to należy przeprowadzić na niej zamianę bajtu na duże znaki.

Headers#
header list

Lista nagłówków # (header list) zawiera zero lub większą liczbę nagłówków.

append

Aby dodać # (append) parę nazwa/wartość name/value do listy nagłówków list należy dodać do list nowy nagłówek, którego nazwą jest name (z zamienionymi bajtami na małe znaki) i którego wartością jest value.

delete

Aby usunąć # (delete) nazwę name z listy nagłówków list należy usunąć z list wszystkie nagłówki, których nazwą jest name (z zamienionymi bajtami na małe znaki).

set

Aby ustawić # (set) parę nazwa/wartość name/value w liście nagłówków list należy wykonać następujące kroki:

  1. Wykonaj zamianę bajtu na małe znaki w name.
  2. Jeśli istnieją jakiekolwiek nagłówki w list, których nazwą jest name, to ustaw wartość pierwszego takiego nagłówka na value i usuń pozostałe duplikaty.
  3. W przeciwnym razie dodaj do list nowy nagłówek, którego nazwą jest name i którego wartością jest value.
combine

Aby połączyć # (combine) parę nazwa/wartość name/value w liście nagłówków list należy wykonać następujące kroki:

  1. Wykonaj zamianę bajtu na małe znaki w name.
  2. Jeśli istnieją jakiekolwiek nagłówki w list, których nazwą jest name, to ustaw wartość pierwszego takiego nagłówka na połączenie wartości, po której następują 0x2C 0x20 (`,` i ` `), po których następuje value.
  3. W przeciwnym razie dodaj do list nowy nagłówek, którego nazwą jest name i którego wartością jest value.

Algorytm połączenia istnieje tylko i wyłącznie dla metody XMLHttpRequest.setRequestHeader().

header

Nagłówek # (header) składa się z nazwy # (name) i wartości # (value). Nazwa jest sekwencją bajtów nieczułą na wielkość znaków, która pasuje do wzorca słowa field-name. Wartość jest sekwencją bajtów, która pasuje do wzorca słowa field-value i nie zawiera bajtów 0x0A lub 0x0D.

Zezwolenie na stosowanie bajtów 0x0A i 0x0D może prowadzić do błędów reparsowania.

simple header

Nagłówek prosty # (simple header) to nagłówek, którego nazwą jest `Accept`, `Accept-Language` i `Content-Language`, lub którego nazwą jest `Content-Type` i którego wartością (po sparsowaniu) jest typ MIME (pomijając parametry) w postaci `application/x-www-form-urlencoded`, `multipart/form-data` i `text/plain`.

forbidden header name

Zabronioną nazwą nagłówka # (forbidden header name) jest nazwa dla nagłówka z następującej listy:

Zabronienie powyższych nazw gwarantuje, że aplikacja kliencka przejmuje pełną kontrolę nad nimi. Nazwy zaczynające się od `Sec-` zostały zarezerwowane w celu umożliwienia nowym nagłówkom sygnalizacji, że pochodzą z bezpiecznych API używających feczu, który pozwala deweloperom przejąć kontrolę nad nagłówkami, jak w przypadku obiektu XMLHttpRequest.

forbidden response header name

Zabronioną nazwą nagłówka odpowiedzi # (forbidden response header name) jest nazwa dla nagłówka z następującej listy:

parse a header value

Aby sparsować wartość nagłówka # (parse a header value) z przekazaniem nazwy name i nagłówka lub listy nagłówków headers należy wykonać następujące kroki:

  1. Jeśli nazwa nie znajduje się w headers, to zwróć wartość null.

  2. Jeśli gramatyka ABNF dla name zezwala na jeden nagłówek i headers zawiera więcej niż jeden, to zwróć błąd.

    Jeśli potrzeba innej obsługi błędów to najpierw należy wyodrębnić żądany nagłówek.

  3. Jeśli sparsowanie wszystkich nazw name z headers zawiedzie (zgodnie z wymogami gramatyki ABNF dla name), to zwróć błąd.
  4. Zwróć jedną lub większą liczbę wartości otrzymanych ze sparsowania wszystkich nazw name z headers (zgodnie z wymogami gramatyki ABNF dla name).
extract a MIME type

Aby wydobyć typ MIME # (extract a MIME type) z listy nagłówków headers należy wykonać następujące kroki:

  1. Niech MIMEType będzie wynikiem parsowania wartości nagłówka z przekazaniem `Content-Type` i headers.
  2. Jeśli MIMEType jest wartością null lub błędem, to zwróć pustą sekwencję bajtów.
  3. Zwróć MIMEType (z zamienionymi bajtami na małe znaki).
Bodies#
body

Ciało # (body) to strumień bajtów. Jest ono skojarzone z transmitowaniem # (transmitted) [z wartością początkową 0], długością # (length) [z wartością początkową 0] i flagą błędu # (error flag) [początkowo nieustawioną].

handle content codings

Aby przechwycić kodowania zawartości # (handle content codings) z przekazaniem kodowań codings i bajtów bytes należy wykonać następujące kroki:

  1. Jeśli codings nie są wspierane, to zwróć bytes.
  2. Zwróć wynik dekodowania bytes z przekazaniem codings (zgodnie z wytycznymi standardu RFC 2616 - "Hypertext Transfer Protocol -- HTTP/1.1").
Requests#
request

Wejściem dla feczu jest żądanie # (request).

method

Żądanie jest skojarzone z metodą # (method) [jakaś metoda]. Jeśli nie określono inaczej to początkowo jest nią `GET`.

url

Żądanie ma przypisany url # (url) [jakiś adres URL].

To jest aktualizowane w czasie przekierowań opisanych w feczu HTTP.

sandboxed storage area URLs flag

Żądanie jest skojarzone z flagą umieszczenia obszaru magazynowania URL-ów w piaskownicy # (sandboxed storage area URLs flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

header list

Żądanie jest skojarzone z listą nagłówków # (header list) [jakaś lista nagłówków]. Jeśli nie określono inaczej to początkowo jest ona pusta.

unsafe request flag

Żądanie jest skojarzone z flagą niebezpiecznego żądania # (unsafe request flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

Flaga niebezpiecznego żądania jest ustawiana przez mechanizmy, takie jak GlobalFetch.fetch() i XMLHttpRequest w celu zapewnienia, że fecz z wstępną inspekcją CORS jest wykonywany w oparciu o przekazaną metodę i listę nagłówków. To nie zwalnia poleceń od zakazu stosowania metod zabronionych i zabronionych nazw nagłówków.

body

Żądanie jest skojarzone z ciałem # (body) [jakieś ciało lub wartość null]. Jeśli nie określono inaczej to początkowo jest ono wartością null.

client

Żądanie jest skojarzone z klientem # (client) [jakiś obiekt ustawień środowiska].

skip service worker flag

Żądanie jest skojarzone z flagą pominięcia wątku serwisu # (skip service worker flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

context

Żądanie jest skojarzone z kontekstem # (context), którym jest jeden z audio, beacon, cspreport, download, embed, eventsource, favicon, fetch, font, form, frame, hyperlink, iframe, image, imageset, import, internal, location, manifest, object, ping, plugin, prefetch, script, serviceworker, sharedworker, subresource, style, track, video, worker, xmlhttprequest i xslt.

context frame type

Żądanie jest skojarzone z typem ramki kontekstu # (context frame type), którym jest jeden z auxiliary, top-level, nested i none. Jeśli nie określono inaczej to początkowo jest nim none.

Poniższa tabela wyraża zależność pomiędzy kontekstem i typem ramki kontekstu w żądaniu a dyrektywami CSP.

konteksttyp ramki kontekstudyrektywa CSPPrzykładowe użycie w platformie
audiononemedia-srcHTML's audio element
beaconnoneconnect-srcnavigator.sendBeacon()
cspreportnoneconnect-srcCSP's report feature
downloadnone—HTML's a element when its download attribute is set
embednoneobject-srcHTML's embed element
eventsourcenoneconnect-srcEventSource
faviconnone—/favicon.ico resource
fetchnoneconnect-srcGlobalFetch.fetch()
fontnonefont-srcCSS' @font-face
formwszystkie prócz noneform-action, potencjalnie child-srcHTML's form element
framenestedchild-srcHTML's frame element
hyperlinkwszystkie prócz nonepotencjalnie child-srcHTML's a element
iframenestedchild-srcHTML's iframe element
imagenoneimg-srcSVG's image element
imagesetnoneimg-srcHTML's picture element
importnonescript-srcHTML's link element when its rel attribute is set to "import"
internalany—User agent actions such as refresh, back, forward; other user agent usage
locationwszystkie prócz nonepotencjalnie child-srcwindow.location
manifestnone—HTML's link element when its rel attribute is set to "manifest"
objectnoneobject-srcHTML's object element
pingnoneconnect-srcHTML's ping attribute
pluginnone—A fetch from a plugin
prefetchnone—HTML's link element when its rel attribute is set to "prefetch"
scriptnonescript-srcHTML's script element
serviceworkernone—navigator.serviceWorker.register()
sharedworkernonechild-srcSharedWorker
subresourcenone—HTML's link element when its rel attribute is set to "subresource"
stylenonestyle-srcHTML's link element when its rel attribute is set to "stylesheet"
tracknonemedia-srcHTML's track element
videononemedia-srcHTML's video element
workernonechild-srcWorker
xmlhttprequestnonechild-srcXMLHttpRequest
xsltnonescript-src<?xml-stylesheet>
origin

Żądanie jest skojarzone z pochodzeniem # (origin) [jakieś pochodzenie]. Jeśli nie określono inaczej to początkowo jest ono nieprzezroczystym identyfikatorem.

force Origin header flag

Żądanie jest skojarzone z flagą silnego nagłówka Origin # (force Origin header flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

same-origin data URL flag

Żądanie jest skojarzone z flagą danych URL tego samego pochodzenia # (same-origin data URL flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

referrer

Żądanie jest skojarzone z referrerem # (referrer), którym jest jeden z no referrer, client lub adres URL. Jeśli nie określono inaczej to początkowo jest nim client.

authentication flag

Żądanie jest skojarzone z flagą poświadczenia # (authentication flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

synchronous flag

Żądanie jest skojarzone z flagą synchroniczności # (synchronous flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

mode

Żądanie jest skojarzone z trybem # (mode), którym jest jeden z same-origin, no CORS, CORS lub CORS-with-forced-preflight. Jeśli nie określono inaczej to początkowo jest nim no CORS.

credentials mode

Żądanie jest skojarzone z trybem uwierzytelnienia # (credentials mode), którym jest jeden z omit, same-origin lub include. Jeśli nie określono inaczej to początkowo jest nim omit.

use URL credentials flag

Żądanie jest skojarzone z flagą użycia uwierzytelnienia URL # (use URL credentials flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

cache mode

Żądanie jest skojarzone z trybem pamięci podręcznej # (cache mode), którym jest jeden z default, no-store, reload, no-cache, force cache lub only-if-cached. Jeśli nie określono inaczej to początkowo jest nim default.

Jeśli lista nagłówków zawiera nagłówek, którego nazwą jest `If-Modified-Since`, `If-None-Match`, `If-Unmodified-Since`, `If-Match` lub `If-Range`, to fecz ustawi tryb pamięci podręcznej na no-store jeśli jest nim default.

manual redirect flag

Żądanie jest skojarzone z flagą manualnego przekierowania # (manual redirect flag). Jeśli nie określono inaczej to początkowo jest ona nieustawiona.

redirect count

Żądanie jest skojarzone z licznikiem przekierowań # (redirect count). Jeśli nie określono inaczej to jego początkową wartością jest 0.

response tainting

Żądanie jest skojarzone ze skażeniem odpowiedzi # (response tainting), którym jest jedno z basic, CORS lub opaque. Jeśli nie określono inaczej to początkowo jest nim basic.

Licznik przekierowań i skażenie odpowiedzi kojarzone z żądaniem są używane przez algorytm feczu w formie zaksięgowanych szczegółów.

Responses#
response

Rezultatem przeprowadzenia feczu jest odpowiedź # (response), która zmienia się wraz z upływem czasu. Oznacza to, że nie wszystkie jej właściwości są dostępne od razu.

type

Odpowiedź jest skojarzona z typem # (type), którym jest jeden z basic, CORS, default, error lub opaque. Jeśli nie określono inaczej to początkowo jest nim default.

termination reason

Odpowiedź może być skojarzona z powodem zakończenia # (termination reason), którym jest jeden z end-user abort, fatal lub timeout.

url

Odpowiedź jest skojarzona z url # (url) [jakiś adres URL lub wartość null]. Jeśli nie określono inaczej to początkowo jest nim wartość null.

status

Odpowiedź jest skojarzona ze statusem # (status). Jeśli nie określono inaczej to początkowo jest nim 200.

status message

Odpowiedź jest skojarzona z wiadomością statusu # (status message). Jeśli nie określono inaczej to początkowo jest nią `OK`.

header list

Odpowiedź jest skojarzona z listą nagłówków # (header list) [jakaś lista nagłówków]. Jeśli nie określono inaczej to początkowo jest ona pusta.

body

Odpowiedź jest skojarzona z ciałem # (body) [jakieś ciało lub wartość null]. Jeśli nie określono inaczej to początkowo jest ono wartością null.

cache state

Odpowiedź jest skojarzona ze stanem pamięci podręcznej # (cache state), którym jest jeden z none, local, validated lub partial. Jeśli nie określono inaczej to początkowo jest nim none.

TLS state

Odpowiedź jest skojarzona ze stanem TLS # (TLS state), którym jest jeden z unauthenticated, deprecated authentication lub authenticated. Jeśli nie określono inaczej to początkowo jest nim unauthenticated.

Odpowiedź dostarczona przez TLS najczęściej będzie miała stan TLS ustawiany na authenticated.

network error

Błąd sieci # (network error) to odpowiedź z typem error, gdzie statusem jest zawsze 0, wiadomością statusu jest zawsze pusta sekwencja bajtów, lista nagłówków jest zawsze pusta, ciałem jest zawsze wartość null i stanem pamięci podręcznej jest zawsze none.

filtered response

Odpowiedź przefiltrowana # (filtered response) to ograniczony widok na odpowiedź, która nie jest błędem sieci. Jest ona wskazywana jako odpowiedź wewnętrzna # (internal response) skojarzona z odpowiedzią przefiltrowaną.

Algorytm feczu zwraca taki widok w celu zagwarantowania, aby różne API nie powodowały przypadkowego wycieku informacji. Jeśli informacja jest wymagana, np. przy dostarczaniu danych graficznych do dekodera, to skojarzona odpowiedź wewnętrzna może zostać użyta, która jest "dostępna" tylko dla wewnętrznych algorytmów specyfikacji.

basic filtered response

Odpowiedź przefiltrowania bazowego # (basic filtered response) to odpowiedź przefiltrowana z typem basic, gdzie lista nagłówków wyklucza wszelkie nagłówki w liście nagłówków skojarzonej z odpowiedzią wewnętrzną, której nazwą jest `Set-Cookie` lub `Set-Cookie2`.

CORS filtered response

Odpowiedź przefiltrowania CORS # (CORS filtered response) to odpowiedź przefiltrowana z typem CORS, gdzie lista nagłówków wyklucza wszelkie nagłówki w liście nagłówków skojarzonej z odpowiedzią wewnętrzną, z wyjątkiem tych, których nazwą jest `Cache-Control`, `Content-Language`, `Content-Type`, `Expires`, `Last-Modified` lub `Pragma`, a także z wyjątkiem tych, których nazwą jest jedna z wartości otrzymanych poprzez sparsowania wartości nagłówka z przekazaniem `Access-Control-Expose-Headers` i listy nagłówków skojarzonej z odpowiedzią wewnętrzną.

opaque filtered response

Odpowiedź przefiltrowania nieprzezroczystego # (opaque filtered response) to odpowiedź przefiltrowana z typem opaque, gdzie statusem jest 0, wiadomością statusu jest pusta sekwencja bajtów, listą nagłówków jest pusta lista, ciałem jest wartość null i stanem pamięci podręcznej jest none.

Innymi słowy odpowiedź przefiltrowania nieprzezroczystego niewiele różni się od błędu sieci. Przy wprowadzaniu nowych API nie należy używać odpowiedzi wewnętrznej dla algorytmów wewnętrznych specyfikacji jeśli chcemy spowodować wyciek informacji.

Authentication entries#

Wejście poświadczenia # (authentication entry) i proxy wejścia poświadczenia # (proxy authentication entry) są krotkami w postaci nazwy użytkownika (username), hasła (password) oraz sfery (relam), skojarzonymi z jednym lub większą liczbą żądań.

Aplikacje klienckie powinny zezwalać na czyszczenie obydwu wejść razem z ciasteczkami HTTP i podobnymi funkcjonalnościami śledzenia.

Dalsze szczegóły są definiowane przez standard RFC 2617 - "HTTP Authentication: Basic and Digest Access Authentication".

HTTP extensions#

`Origin` header#

Nagłówek `Origin` # (`Origin`) w żądaniu wskazuje, skąd pochodzi fecz.

Nagłówek `Origin` jest odmianą nagłówka `Referer`, ale nie ujawnia ścieżki w adresie URL. Stosowany jest dla wszystkich feczów HTTP, których flaga CORS flag jest ustawiona oraz tych, których metodą w żądaniu jest `POST`. Ze względu na kompatybilność nie jest on dołączany we wszystkich feczach.

Gramatyka ABNF dla wartości nagłówka `Origin` jest następująca:

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
Origin                           = origin-or-null

origin-or-null                   = origin / %x6E.75.6C.6C ; "null", case-sensitive
origin                           = scheme "://" host [ ":" port ]

Powyższa definicja nagłówka `Origin` zastępuje definicję ze standardu RFC 6454 - "The Web Origin Concept".

CORS protocol#

W celu umożliwienia współdzielenia zasobów między różnymi pochodzeniami (cross-origin) i zezwolenia na bardziej wszechstronne żądania HTTP niż umożliwiają to formularze HTML, platform posiada protokół CORS # (CORS protocol) umieszczany na górnej warstwie HTTP. Pozwala on zadeklarować zasobom, że mogą być współdzielone z zasobami znajdującymi się w innym pochodzeniu.

To musi być mechanizm opt-in, aby zapobiec wyciekowi danych z zasobów znajdujących się za firewallem (intranetami). Dodatkowo, dla akredytowanych żądań HTTP koniecznie musi on być opt-in, aby zapobiec wyciekowi potencjalnie wrażliwych danych.

Sekcja ta wyjaśnia protokół CORS i ma zastosowanie dla serwerów. Wymagania stawiane aplikacjom klienckim są częścią algorytmu feczu.

General#

Protokół CORS składa się z zestawu nagłówków, które wskazują, czy konkretny zasób może być współdzielony między różnymi pochodzeniami.

Dla żądań HTTP, które są bardziej złożone niż to, co umożliwiają elementy formularzy HTML preferowany jest fecz z wstępną inspekcją CORS, który zapewni zrozumienie protokołu CORS przez zasób.

HTTP requests#
CORS request

Żądanie HTTP może być identyfikowane jako odniesienie do protokołu CORS jeśli zawiera nagłówek `Origin`. W takiej sytuacji mamy do czynienia z żądaniem CORS # (CORS request).

Żądanie HTTP może być identyfikowane w formie testu, aby zobaczyć, czy protokół CORS jest zrozumiały jeśli jest ono żądaniem CORS, używa metody `Options` i zawiera następujące nagłówki:

`Access-Control-Request-Method` #

Wskazuje, która metoda może zostać użyta w kolejnym żądaniu CORS do tego samego zasobu.

`Access-Control-Request-Headers` #

Wskazuje, które nagłówki mogą zostać użyte w kolejnym żądaniu CORS do tego samego zasobu.

CORS preflight request

Nosi to nazwę żądania z wstępną inspekcją CORS # (CORS preflight request).

HTTP responses#

Odpowiedź HTTP na żądanie CORS może zawierać następujące nagłówki:

`Access-Control-Allow-Origin` #

Wskazuje, czy zasób może być dzielony poprzez zwrócenie w odpowiedzi literalnej wartości nagłówka `Origin` z żądania (którym może być `null`) lub `*`.

`Access-Control-Allow-Credentials` #

Wskazuje, czy zasób może być dzielony, gdy trybem uwierzytelnienia w żądaniu jest include.

Dla żądania z wstępną inspekcją CORS skojarzonym trybem uwierzytelnienia jest zawsze omit, ale dla wszystkich późniejszych żądań CORS nie musi tak być. Obsługa musi być zatem wskazywana jako część odpowiedzi HTTP, jak również i żądania z wstępną inspekcją CORS.

Odpowiedź HTTP na żądanie z wstępną inspekcją CORS może zawierać następujące nagłówki:

`Access-Control-Allow-Methods` #

Wskazuje, które metody są obsługiwane przez zasób dla celów z protokołem CORS.

Nagłówek `Allow` nie ma znaczenia w przypadku celów z protokołem CORS.

`Access-Control-Allow-Headers` #

Wskazuje, które nagłówki są obsługiwane przez zasób dla celów z protokołem CORS.

`Access-Control-Max-Age` #

Wskazuje, jak długo informacje dostarczone przez nagłówki `Access-Control-Allow-Methods` i `Access-Control-Allow-Headers` mogą być buforowane.

Odpowiedź HTTP na żądanie CORS, które nie jest żądaniem z wstępną inspekcją CORS może zawierać następujący nagłówek:

`Access-Control-Expose-Headers` #

Wskazuje, które nagłówki mogą być eksponowane w ramach odpowiedzi HTTP, poprzez wymienienie ich nazw.

HTTP new header syntax#

Gramatyka ABNF dla wartości w nagłówkach używanych przez protokół CORS jest następująca:

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
Access-Control-Request-Method		= Method
Access-Control-Request-Headers		= #field-name

Access-Control-Allow-Origin			= origin-or-null / "*"
Access-Control-Allow-Credentials	= %x74.72.75.65 ; "true", case-sensitive
Access-Control-Expose-Headers		= #field-name
Access-Control-Max-Age				= delta-seconds
Access-Control-Allow-Methods		= #Method
Access-Control-Allow-Headers		= #field-name

Fetching#

Poniższy algorytm definiuje feczowanie. W ogólnym ujęciu pobiera on żądanie i zwraca odpowiedź.

Oznacza to, że albo zwraca odpowiedź jeśli flaga synchroniczności w żądaniu była ustawiona, albo kolejkuje zadania odnotowanego przetworzenia odpowiedzi, przetworzenia ciała odpowiedzi i przetworzenia końca pliku odpowiedzi dla odpowiedź.

Aby przechwycić przesyłanie danych jeśli flaga synchroniczności w żądaniu była nieustawiona, zadania odnotowanego przetworzenia ciała żądania i przetworzenia końca pliku żądania dla żądania mogą być kolejkowane.

fetch

Aby przeprowadzić fecz # (fetch) z przekazaniem żądania request i opcjonalnej flagi CORS flag należy wykonać poniższe kroki. W trakcie wykonywania fecz może być przerwany # (terminated) z powodu reason, którym może być jeden z end-user abort, fatal lub timeout.

Flaga CORS flag jest zaksięgowanym szczegółem dla obsługi przekierowań. W innych standardach należy używać jedynie parametru request.

  1. Jeśli url w request zawiera Znany Host HSTS (Known HSTS Host), to zmodyfikuj go zgodnie z wymogami rozdziału "URI [sic] Loading and Port Mapping" ze standardu RFC 6797 "HTTP Strict Transport Security (HSTS)".

  2. Jeśli referrerem w request nie jest no referrer, to ustaw referrer w request na wynik ustalenia referrera w request.

    Zgodnie ze specyfikacją "Referrer Policy" aplikacje klienckie mogą zapewnić użytkownikowi końcowemu opcje nadpisujące referrer w request do stanu no referrer lub eksponować go z mniej wrażliwymi informacjami.

  3. Jeśli flaga synchroniczności w request jest nieustawiona i fecz nie został wywołany rekursywnie, to wykonaj pozostałe kroki równolegle.

  4. Niech response będzie wartością odpowiadającą pierwszemu dopasowanemu warunkowi:

    Czy feczowanie request powinno być zablokowane z uwagi na zawartość mieszaną zwraca blocked
    Czy feczowanie request powinno być zablokowane z uwagi na bezpieczeństwo zawartości zwraca blocked
    Błąd sieci.
    Pochodzeniem w url skojarzonym z request jest pochodzenie w request i CORS flag jest nieustawiona
    Schematem w url skojarzonym z request jest "data" i flaga danych URL tego samego pochodzenia w request jest ustawiona
    Schematem w url skojarzonym z request jest "about"
    Wynik przeprowadzenia bazowego feczu z przekazaniem request.
    Trybem w request jest same-origin
    Błąd sieci.
    Trybem w request jest no CORS

    Ustaw skażenie odpowiedzi w request na opaque.

    Wynik przeprowadzenia bazowego feczu z przekazaniem request.

    Schematem w url skojarzonym z request nie jest "http" lub "https"
    Błąd sieci.
    Trybem w request jest CORS-with-forced-preflight
    Flaga niebezpiecznego żądania w request jest ustawiona i metodą w request nie jest metoda prosta lub nagłówek w liście nagłówków skojarzonej z request nie jest nagłówkiem prostym

    Ustaw skażenie odpowiedzi w request na CORS.

    Wynik przeprowadzenia feczu HTTP z przekazaniem request oraz ustawionymi flagami CORS flag i CORS preflight flag.

    W przeciwnym razie

    Ustaw skażenie odpowiedzi w request na CORS.

    Wynik przeprowadzenia feczu HTTP z przekazaniem request oraz ustawioną flagą CORS flag.

  5. Jeśli fecz został wywołany rekursywnie, to zwróć response.
  6. Ustaw url w response na url w request.
  7. Jeśli czy feczowanie request powinno być zablokowane z uwagi na treść mieszaną zwraca blocked, to ustaw response na błąd sieci.

  8. Jeśli response nie jest błędem sieci, to w zależności od skażenia odpowiedzi w request ustaw response na poniższą odpowiedź przefiltrowaną z response będącą odpowiedzią wewnętrzną:

    basic
    odpowiedź przefiltrowania bazowego
    CORS
    odpowiedź przefiltrowania CORS
    opaque
    odpowiedź przefiltrowania nieprzezroczystego

  9. Jeśli flaga synchroniczności w request jest ustawiona, to poczekaj na dołączenie końca pliku do ciała w response lub wystąpienie powodu zakończenia w response, a następnie zwróć response.

    Krok ten przerywa fecz.

  10. Jeśli ciało w request nie jest wartością null i schematem w url skojarzonym z request jest "http" lub "https", to kolejkuj zadanie feczu na request w celu przetworzenia końca pliku żądania # (process request end-of-file) dla request.
  11. Kolejkuj zadanie feczu na request w celu przetworzenia odpowiedzi # (process response) dla response.

  12. Jeśli ciało w response jest wartością null, to wykonaj poniższe podkroki:

    1. Kolejkuj zadanie feczu na request w celu przetworzenia ciała odpowiedzi # (process response body) dla response.
    2. Kolejkuj zadanie feczu na request w celu przetworzenia końca pliku odpowiedzi # (process response end-of-fil) dla response.

  13. W przeciwnym razie, jeśli ciało w response nie jest wartością null, to wykonaj poniższe podkroki:

    1. Ilekroć do ciała w response jest coś dołączane, i tak długo jak nie wystąpił powód zakończenia dla response i koniec pliku nie został dołączony, to kolejkuj zadanie feczu na request w celu przetworzenia ciała odpowiedzi dla response.

    2. Kiedy koniec pliku zostanie dołączony do ciała w response lub wystąpił powód zakończenia dla response, to kolejkuj zadanie feczu na request w celu przetworzenia końca pliku odpowiedzi dla response.

      Idealnie jeśli standardy FTP/HTTP definiowałyby to bardziej szczegółowo i stałoby się to zestawem prostych uchwytów.

    Użyj sieciowego źródła zadań dla tych zadań.

basic fetch

Aby przeprowadzić bazowy fecz # (basic fetch) z przekazaniem żądania request należy, w oparciu o wartość schematu w url skojarzonym z request, należy wykonać następujące kroki:

"about"
  1. Jeśli dane schematu w url skojarzonym z request mają wartość "blank", to zwróć odpowiedź, której lista nagłówków składa się z pojedynczego nagłówka z nazwą `Content-Type` i wartością `text/html;charset=utf-8`, ciałem jest pusta sekwencja bajtów i stanem TLS jest stan TLS w kliencie skojarzonym z request.
  2. W przeciwnym razie zwróć błąd sieci.

Adresy URL takie jak "about:config" są obsługiwane w trakcie nawigacji i w kontekście feczowania powodują błąd sieci.

"blob"
  1. Niech blob będzie obiektem w url skojarzonym z request.
  2. Jeśli blob jest wartością null, to zwróć błąd sieci.
  3. Niech length będzie wartością atrybutu size w blob i type będzie wartością atrybutu type w blob.
  4. Niech response będzie nową odpowiedzią.
  5. Dodaj parę `Content-Length`/length do listy nagłówków w response.
  6. Dodaj parę `Content-Type`/type do listy nagłówków w response.
  7. Ustaw stan TLS w response na stan TLS w kliencie skojarzonym z request.
  8. Ustaw ciało w response na wynik operacji odczytu na blob.
  9. Zwróć response.
"data"
  1. Jeśli metodą w request jest `GET` i uzyskanie zasobu z url w request nie zwraca błędu, to zwróć odpowiedź, której lista nagłówków składa się z pojedynczego nagłówka z nazwą `Content-Type` i wartością będącą typem MIME oraz parametrami zwróconymi przez uzyskanie zasobu, ciałem są dane zwrócone przez uzyskanie zasobu i stanem TLS jest stan TLS w kliencie skojarzonym z request.
  2. W przeciwnym razie zwróć błąd sieci.
"file"
"ftp"
  1. Na dzień dzisiejszy adresy URL typu file i ftp pozostawiono w ramach ćwiczenia dla czytelnika.
  2. W razie wątpliwości zwróć błąd sieci.
"filesystem"
  1. Jeśli flaga umieszczenia obszaru magazynowania URL-ów w piaskownicy jest ustawiona, to zwróć błąd sieci.
  2. W przeciwnym razie... (schemat ten wciąż wymaga zdefiniowania).
"http"
"https"
  1. Zwróć wynik przeprowadzenia feczu HTTP z przekazaniem request.
W przeciwnym razie
  1. Zwróć błąd sieci.

HTTP fetch

Aby przeprowadzić fecz HTTP # (HTTP fetch) z przekazaniem żądania request oraz opcjonalnymi flagami CORS flag, CORS preflight flag i authentication fetch flag, należy wykonać następujące kroki:

Wszystkie trzy wymienione flagi są pewną formą zaksięgowania szczegółów. Druga wskazuje na konieczność użycia żądania z wstępną inspekcją CORS a trzecia wskazują na próbę uwierzytelnienia.

  1. Niech response będzie wartością null.

  2. Jeśli flaga pominięcia wątku serwisu w request jest nieustawiona i obiekt globalny w kliencie skojarzonym z request nie jest obiektem ServiceWorkerGlobalScope, to wykonaj poniższe podkroki:

    1. Ustaw response na wynik przechwycenia faczu dla request.
    2. Jeśli typem w response jest opaque i trybem w request nie jest no CORS lub typem w response jest error, to zwróć błąd sieci.

  3. Jeśli response jest wartością null, to wykonaj poniższe podkroki:

    1. Jeśli CORS preflight flag jest ustawiona i jeden z poniższych warunków jest prawdziwy:

      To wykonaj poniższe wewnętrzne podkroki:

      1. Niech response będzie wynikiem przeprowadzenia feczu z wstępną inspekcją CORS z przekazaniem request.
      2. Jeśli response jest błędem sieci, to zwróć response.

    2. Ustaw flagę pominięcia wątku serwisu w request.

      Nie może być przekierowań. Alternatywnie flaga poświadczenia w request jest ustawiana i CORS flag jest usuwana.

    3. Ustaw credentials flag jeśli trybem uwierzytelnienia w request jest include lub trybem uwierzytelnienia w request jest same-origin i CORS flag jest nieustawiona. W przeciwnym razie usuń credentials flag.
    4. Jeśli trybem pamięci podręcznej w request jest default i lista nagłówków w request zawiera nagłówek, którego nazwą jest `If-Modified-Since`, `If-None-Match`, `If-Unmodified-Since`, `If-Match` lub `If-Range`, to ustaw tryb pamięci podręcznej w request na no-store.
    5. Ustaw response na wynik przeprowadzenia feczu HTTP sieci lub pamięci podręcznej z przekazaniem request i credentials flag (jeśli ustawiona) oraz authentication fetch flag (jeśli ustawiona).

    6. Jeśli CORS flag jest ustawiona i sprawdzenie CORS dla request i response zwraca błąd, to zwróć błąd sieci.

      Nie ma potrzeby stosowania tego dla odpowiedzi z wątku serwisu.

  4. W zależności od wartości statusu w response wykonaj poniższe podkroki:

    304
    1. Jeśli trybem pamięci podręcznej w request nie jest ani default ani no-cache, to nie rób niczego.

    2. W przeciwnym razie wykonaj poniższe wewnętrzne podkroki:

      1. Jeśli nie ma wejścia w pamięci podręcznej HTTP dla request i response, to zwróć błąd sieci.

      2. Ustaw response na wynik uzyskania odpowiedzi z pamięci podręcznej HTTP z użyciem request i response.

        To całkowicie zmienia response, włącznie z jej statusem, którym najprawdopodobniej będzie 200.

        Ustaw stan pamięci podręcznej w response na validated.

    301
    302
    303
    307
    308
    1. Niech location będzie wynikiem parsowania nazwy nagłówka z przekazaniem `Location` i listy nagłówków skojarzonej z response.
    2. Jeśli location jest wartością null, to zwróć response.
    3. Jeśli location jest błędem, to zwróć błąd sieci.
    4. Niech locationURL będzie wynikiem uruchomienia parsera adresu URL z przekazaniem location i url skojarzonego z request.
    5. Jeśli locationURL jest błędem, to zwróć błąd sieci.
    6. Jeśli licznik przekierowań w request ma wartość 20, to zwróć błąd sieci.
    7. Zwiększ licznik przekierowań w request o jeden.
    8. Usuń flagę danych URL tego samego pochodzenia w request.

    9. Jeśli CORS preflight flag jest ustawiona, to ustaw typ w response na error i ustaw flagę manualnego przekierowania w response.

      W ten sposób zapobiegamy wykonywaniu poniższych podkroków.

    10. Jeśli flaga manualnego przekierowania w response jest nieustawiona, to wykonaj poniższe podkroki:

      1. Jeśli CORS flag jest ustawiona i pochodzeniem w locationURL nie jest pochodzenie w url skojarzonym z request, to ustaw pochodzenie w request na nieprzezroczysty identyfikator.
      2. Jeśli CORS flag jest ustawiona i nazwa użytkownika w locationURL nie jest pustym łańcuchem znakowym lub hasło w locationURL nie jest wartością null, to zwróć błąd sieci.
      3. Ustaw url w request na locationURL.
      4. Zwróć wynik przeprowadzenia feczu z przekazaniem request oraz ustawioną flagą CORS flag.
    401
    1. Jeśli flaga poświadczenia w request jest nieustawiona lub CORS flag jest ustawiona, to zwróć response.
    2. Krok ten wymaga dalszych testów.

    3. Jeśli flaga użycia uwierzytelnienia URL w request jest nieustawiona lub authentication fetch flag jest ustawiona, to wykonaj poniższe podkroki:

      1. Niem username i password będzie wynikiem pobrania od użytkownika końcowego odpowiednio nazwy użytkownika i hasła.
      2. Ustaw nazwę użytkownika z przekazaniem url w request i username.
      3. Ustaw hasło z przekazaniem url w request i password.
    4. Zwróć wynik przeprowadzenia feczu HTTP z przekazaniem request oraz ustawioną flagą authentication fetch flag.
    407
    1. Krok ten wymaga dalszych testów.

    2. Pobierz od użytkownika końcowego odpowiednie dane i zapisz wynik jako proxy wejścia poświadczenia.

      Pozostał szczegóły otaczające proxy poświadczenia są definiowane przez standard RFC 2616 - "Hypertext Transfer Protocol -- HTTP/1.1".

    3. Zwróć wynik przeprowadzenia feczu HTTP z przekazaniem request.
    W przeciwnym razie
    Nie rób niczego.
  5. Jeśli authentication fetch flag jest ustawiona, to utwórz wejście poświadczenia z przekazaniem request i sfery (zgodnie z wymogami standardu RFC 2617 - "HTTP Authentication: Basic and Digest Access Authentication").
  6. Jeśli CORS preflight flag jest ustawiona i response jest błędem sieci, to wyczyść wejścia pamięci podręcznej z przekazaniem request.

  7. Zwróć response.

    Zazwyczaj, po zwróceniu, do ciała w response jest wciąż coś dołączane.

HTTP network or cache fetch

Aby przeprowadzić fecz HTTP sieci lub pamięci podręcznej # (HTTP network or cache fetch) z przekazaniem żądania request oraz opcjonalnymi flagami credentials flag i authentication fetch flag, należy wykonać następujące kroki:

Wymienione flagi są pewną formą zaksięgowania szczegółów.

  1. Niech HTTPRequest będzie kopią request, z tym że ciało w HTTPRequest jest referencja do ciała w request.

    Nagłówki muszą być dodawane bez wpływu na request. Ze względu na przekierowania lub błąd uwierzytelnienia mogą zostać ponownie wykorzystane.

  2. Dodaj do listy nagłówków w HTTPRequest parę `Referer`/pusta sekwencja bajtów jeśli referrerem w HTTPRequest jest no referrer, w przeciwnym razie parę `Referer`/referrer w HTTPRequest (zserializowany i zakodowany w utf-8).
  3. Jeśli flaga silnego nagłówka Origin w HTTPRequest jest ustawiona, to dodaj do listy nagłówków w HTTPRequest parę `Origin`/pochodzenie w HTTPRequest (zserializowane i zakodowane w utf-8).

  4. Jeśli credentials flag jest ustawiona, to wykonaj poniższe podkroki:

    1. Modyfikuj listę nagłówków w HTTPRequest zgodnie z wymogami standardu RFC 6265 - "HTTP State Management Mechanism".
    2. Niech authorizationValue będzie wartością null.
    3. Jeśli istnieje wejście poświadczenia dla HTTPRequest i flaga użycia uwierzytelnienia URL w HTTPRequest jest nieustawiona lub url w HTTPRequest nie uwzględnia uwierzytelnienia, to ustaw authorizationValue na wejście poświadczenia.
    4. W przeciwnym razie, jeśli url w HTTPRequest uwzględnia uwierzytelnienie i authentication fetch flag jest ustawiona, to ustaw authorizationValue na url w HTTPRequest.
    5. Jeśli authorizationValue nie jest wartością null, to dodaj parę `RefeAuthorizationrer`/authorizationValue do listy nagłówków w HTTPRequest.

  5. Jeśli istnieje proxy wejścia poświadczenia, to użyj je odpowiednio.

    To celowo nie zależy od trybu uwierzytelnienia w HTTPRequest.

  6. Niech response będzie wartością null.

  7. Jeśli trybem pamięci podręcznej w request nie jest ani no-store ani reload i istnieje kompletna (complete) odpowiedź w pamięci podręcznej HTTP dla request, to wykonaj poniższe kroki:

    1. Jeśli trybem pamięci podręcznej w request jest force cache lub only-if-cached, to ustaw response na odpowiedź w pamięci podręcznej HTTP dla request.
    2. W przeciwnym razie, jeśli trybem pamięci podręcznej w request jest default i odpowiedź w pamięci podręcznej HTTP dla request nie wymaga weryfikacji, to ustaw response na tę odpowiedź i ustaw stan pamięci podręcznej w response na locale.
    3. W przeciwnym razie, jeśli trybem pamięci podręcznej w request jest default lub no-cache i odpowiedź w pamięci podręcznej HTTP dla request wymaga weryfikacji, to modyfikuj listę nagłówków w HTTPRequest w oparciu o zweryfikowane nagłówki.
  8. W przeciwnym razie, jeśli trybem pamięci podręcznej w request jest default lub force cache i istnieje częściowa (partial) odpowiedź w pamięci podręcznej HTTP dla request, to modyfikuj listę nagłówków w HTTPRequest w oparciu o powrotne nagłówki.
  9. Jeśli response jest wartością null i trybem pamięci podręcznej w request jest only-if-cached, to zwróć błąd sieci.

  10. Jeśli response jest wartością null, to modyfikuj listę nagłówków w HTTPRequest zgodnie z wymogami standardu HTTP.

    Wskazane byłoby opisanie tego kroku w bardziej normatywny sposób. W tym momencie nagłówki takie jak `Accept-Encoding`, `Connection`, `DNT` i `Host` mogą być dodawane, jeśli to konieczne.

    `Accept-Charset` nie może być uwzględniany. `Accept` i `Accept-Language` nie mogą być uwzględniane w tym momencie.

    Więcej szczegółów znajduje się podrozdziale Podział warstw nagłówka HTTP.

  11. Jeśli response jest wartością null, to ustaw response na wynik wykonania żądania HTTP z użyciem HTTPRequest, zgodnie z wymogami standardu HTTP, i czekaj do chwili, kiedy wszystkie nagłówki zostaną przesłane lub zwrócony zostanie błąd sieci. Jeśli błąd sieci zwrócony zostanie ze względu na przerwanie danego feczu z powodu reason, to ustaw powód zakończenia w response na reason.

    Jeśli response nie jest błędem sieci i trybem pamięci podręcznej w request nie jest no-store, to uaktualnij response w pamięci podręcznej HTTP dla request.

    Jeśli response została dostarczona poprzez TLS, to ustaw jej stan TLS na deprecated authentication lub authenticated (zgodnie z wymogami standardu RFC 5246 - "The Transport Layer Security (TLS) Protocol Version 1.2").

    W tej chwili dokładne określenie tego zachowania należy do aplikacji klienckich, które zachęca się, aby wykonywały udane połączenia TLS z silnymi właściwościami bezpieczeństwa i zwracały błędy sieci w każdym innym przypadku.

    Jeśli ciało w HTTPRequest nie jest wartością null, to wykonaj poniższe podkroki:

    1. Jeśli długość ładunku ciała w ciele skojarzonym z HTTPRequest jest znana, to ustaw długość w ciele skojarzonym z HTTPRequest na długość ładunku ciała w ciele skojarzonym z HTTPRequest.

    2. Ilekroć ciało w HTTPRequest jest odczytywane z (tzn. jest transmitowane), to zwiększ transmitowanie w ciele skojarzonym z HTTPRequest o ilość przesłanych bajtów ładunku ciała i kolejkuj zadanie feczu na request w celu przetworzenia ciała żądania # (process request body) dla HTTPRequest.

      Użyj sieciowe źródło zadań.

    Wykonaj poniższe podkroki równolegle, zaraz za zwróceniem zewnętrznego zestawu kroków:

    1. Jeśli ciało w response nie jest wartością null, to ustaw długość w ciele skojarzonym z response na długość ładunku ciała w ciele skojarzonym z response.

    2. Ilekroć jeden lub większa ilość bajtów będzie transmitowana, to niech bytes będą transmitowanymi bajtami i wykonaj poniższe podkroki:

      1. Zwiększ transmitowanie w ciele skojarzonym z response o długość bytes.
      2. Niech codings będą wynikiem parsowania wartości nagłówka z przekazaniem `Content-Encoding` i listy nagłówków w response.
      3. Ustaw bytes na wynik przechwycenia kodowania zawartości z przekazaniem codings i bytes.
      4. Dołącz bytes do ciała w response.

    3. Jeśli w dowolnym momencie fecz zostanie przerwany z powodu reason, to ustaw powód zakończenia w response na reason.

      Są one wykonywane równolegle bo w tym momencie nie wiadomo, czy ciało w response jest istotne (response może być przekierowaniem).

  12. Usuń `Content-Encoding` z listy nagłówków w response jeśli jeden z poniższych warunków jest prawdziwy:

    To dotyczy zepsutych konfiguracji serwera Apache. Idealnie byłoby zdefiniowane tego w standardzie HTTP.

  13. Jeśli credentials flag jest ustawiona i lista nagłówków w response zawiera jeden lub większą liczbę nagłówków z nazwą `Set-Cookie`, to wykonaj poniższe podkroki

    1. Poczekaj, aż posiadanie muteksu magazynu może być podjęte przez tę instancję algorytmu feczu.
    2. Podejmij mutex magazynu.

    3. Uaktualnij ciasteczka zgodnie z wymogami standardu RFC 6265 - "HTTP State Management Mechanism".

      Jest to odmiana gromadzenia odcisków palców (fingerprinting).

    4. Zwolnij mutex magazynu tak, żeby ponownie był wolny.

  14. Zwróć response.

    Zazwyczaj, po zwróceniu, do ciała w response jest wciąż coś dołączane.

CORS preflight fetch

Aby przeprowadzić fecz z wstępną inspekcją CORS # (CORS preflight fetch) z przekazaniem żądania request należy wykonać następujące kroki:

  1. Niech preflight będzie nowym żądaniem, gdzie metodą jest `OPTIONS`, url jest url w request, pochodzeniem jest pochodzenie w request, referrerem jest referrer w request i flaga silnego nagłówka Origin jest ustawiona.
  2. Ustaw parę `Access-Control-Request-Method`/metoda z request w liście nagłówków skojarzonej z preflight.
  3. Niech headers będą nazwami wszystkich nagłówków w liście nagłówków skojarzonej z request, z wykluczeniem duplikatów, posortowanych leksykograficznie i z zamienionymi bajtami na małe znaki.
  4. Niech value zawiera elementy z headers, oddzielone od siebie za pomocą bajtów 0x2C 0x20 (`,` i ` `).
  5. Ustaw parę `Access-Control-Request-Headers`/value w liście nagłówków skojarzonej z preflight.
  6. Niech response będzie wynikiem przeprowadzenia feczu HTTP sieci lub pamięci podręcznej z przekazaniem preflight.

  7. Jeśli sprawdzenie CORS z przekazaniem request i response zwraca sukces i status w response jest w przedziale 200 do 299, to wykonaj poniższe podkroki:

    Sprawdzenie CORS przeprowadzane jest na response, a nie na preflight, aby zagwarantować użycie prawidłowego trybu uwierzytelnienia.

    1. Niech methods będzie wynikiem parsowania wartości nagłówka z przekazaniem `Access-Control-Allow-Methods` i listy nagłówków w response.
    2. Niech headerNames będzie wynikiem parsowania wartości nagłówka z przekazaniem `Access-Control-Allow-Headers` i listy nagłówków w response.
    3. Jeśli methods lub headerNames jest błędem, to zwróć błąd sieci.

    4. Jeśli methods jest wartością null i trybem w request jest CORS-with-forced-preflight, to ustaw methods na metodę w request.

      To gwarantuje, że fecz z wstępną inspekcją CORS, wykonany ze względu na tryb CORS-with-forced-preflight w request, będzie buforowany.

    5. Jeśli metoda w request nie znajduje się w methods i nie jest metodą prostą, to zwróć błąd sieci.
    6. Jeśli jedna z nazw w liście nagłówków skojarzonej z response nie znajduje się w headerNames i jej odpowiadający nagłówek nie jest nagłówkiem prostym, to zwróć błąd sieci.
    7. Niech max-age będzie wynikiem parsowania wartości nagłówka z przekazaniem `Access-Control-Max-Age` i listy nagłówków w response.
    8. Jeśli max-age jest błędem lub wartością null, to ustaw max-age na zero.
    9. Jeśli max-age jest większy od nałożonego limitu na max-age, to ustaw max-age na nałożony limit.
    10. Jeśli aplikacja kliencka nie obsługuje buforowania, to zwróć response.
    11. Dla każdej metody method w methods, dla której istnieje dopasowanie metody pamięci podręcznej z przekazaniem request, ustaw pasujący max-age w wejściu na max-age.

    12. Dla każdej metody method w methods, dla której nie istnieje dopasowanie metody pamięci podręcznej z przekazaniem request, utwórz nowe wejście w pamięci podręcznej z wstępną inspekcją CORS, z następującymi wartościami dla poszczególnych pól:

      origin
      pochodzenie w request
      url
      url w request
      max-age
      max-age
      credentials
      Boolowska wartość false jeśli trybem uwierzytelnienia w request nie jest include, w przeciwnym razie boolowska wartość true
      method
      method
    13. Dla każdej nazwy headerName w headerNames, dla której istnieje dopasowanie nazwy nagłówka pamięci podręcznej z przekazaniem request, ustaw pasujący max-age w wejściu na max-age.

    14. Dla każdej nazwy headerName w headerNames, dla której nie istnieje dopasowanie nazwy nagłówka pamięci podręcznej z przekazaniem request, utwórz nowe wejście w pamięci podręcznej z wstępną inspekcją CORS, z następującymi wartościami dla poszczególnych pól:

      origin
      pochodzenie w request
      url
      url w request
      max-age
      max-age
      credentials
      Boolowska wartość false jeśli trybem uwierzytelnienia w request nie jest include, w przeciwnym razie boolowska wartość true
      header name
      headerName
    15. Zwróć response.
  8. W przeciwnym razie zwróć błąd sieci.

CORS preflight cache

Pamięć podręczna z wstępną inspekcją CORS # (CORS preflight cache) składa się z kolekcji wejść (input), gdzie każde wejście posiada następujące pola: origin #, url #, max-age #, credentials #, method # i header name #.

Wejścia muszą zostać usunięte po upływie sekund określonych w polu max-age względem chwili przechwycenia tych wejść. Wejścia mogą zostać usunięte przed wystąpieniem tego momentu.

clear cache entries

Aby wyczyścić wejścia pamięci podręcznej # (clear cache entries) z przekazaniem żądania request należy usunąć wszelkie wejścia w pamięci podręcznej z wstępną inspekcją CORS, których origin jest pochodzeniem w request i których url to url w request.

cache match

Istnieje dopasowanie pamięci podręcznej # (cache match) dla żądania request jeśli origin to pochodzenie w request, url to url w request, i credentials jest boolowską wartością false oraz trybem uwierzytelnienia w request nie jest include lub credentials jest boolowską wartością true.

method cache match

Istnieje dopasowanie metody pamięci podręcznej # (method cache match) dla metody method w żądaniu request, kiedy w pamięci podręcznej z wstępną inspekcją CORS znajduje się wejście, dla którego istnieje dopasowanie pamięci podręcznej z przekazaniem request i którego method to method.

header name cache match

Istnieje dopasowanie nazwy nagłówka pamięci podręcznej # (header name cache match) dla nazwy nagłówka headerName w żądaniu request, kiedy w pamięci podręcznej z wstępną inspekcją CORS znajduje się wejście, dla którego istnieje dopasowanie pamięci podręcznej z przekazaniem request i którego header name to headerName.

CORS check

Aby przeprowadzić sprawdzenie CORS # (CORS check) z przekazaniem żądania request i odpowiedzi response należy wykonać następujące kroki:

  1. Niech origin będzie wynikiem parsowania wartości nagłówka z przekazaniem `Access-Control-Allow-Origin` i listy nagłówków w response.

  2. Jeśli origin jest wartością null lub błędem, to zwróć błąd.

    Wartość null a bajtowy zapis `null` nie są tożsame.

  3. Jeśli trybem uwierzytelnienia w request nie jest include i origin jest `*`, to zwróć sukces.
  4. Jeśli pochodzenie w request, zserializowane i zakodowane w utf-8, nie jest równe origin, to zwróć błąd.
  5. Jeśli trybem uwierzytelnienia w request nie jest include, to zwróć sukces.
  6. Niech credentials będzie wynikiem parsowania wartości nagłówka z przekazaniem `Access-Control-Allow-Credentials` i listy nagłówków w response.
  7. Jeśli credentials jest wartością `true`, to zwróć sukces.
  8. Zwróć błąd.

Background reading#

Poniższe informacje mają charakter jedynie informacyjny.

HTTP header layer division#

Dla celów związanych z feczowaniem platforma posiada warstwę API (img w HTML, background-image w CSS), warstwę wątku serwisu oraz warstwę sieci i pamięci podręcznej. Nagłówki `Accept` i `Accept-Language` są ustawiane w warstwie API (zazwyczaj przez aplikację kliencką). Większość pozostałych nagłówków kontrolowanych przez aplikację kliencką, takich jak `Accept-Encoding`, `Host` czy `Referer`, są ustawiane w warstwie sieci i pamięci podręcznej. Deweloperzy mogą ustawiać nagłówki w warstwie API lub w warstwie wątku serwisu (zwykle poprzez obiekt Request). Deweloperzy nie mają prawie żadnej kontroli nad nagłówkami zabronionymi, ale mogą kontrolować nagłówek `Accept` i mieć możliwość ograniczenia lub wyłączenia nagłówka `Referer`.

Atomic HTTP redirect handling#

W całej platformie, przekierowania (czyli odpowiedzi, których statusem jest 301, 302, 303, 307 i 308) nie są eksponowane przez API. Eksponowanie przekierowań może prowadzić do wycieku informacji w trakcie ataku cross-site scripting.

Fecz do https://example.org/auth, który zawiera nagłówek `Cookie` oznaczony jako HttpOnly, może spowodować przekierowanie do https://other-origin.invalid/4af955781ea1c84a3b11. Ten nowy adres URL zawiera tajemnicę. W przypadku wyeksponowania przekierowań tajemnica ta byłaby dostępna w przypadku ataku cross-site scripting.

Basic safe CORS protocol setup#

W przypadku zasobów, gdzie dane są chronione za pomocą uwierzytelnienia IP lub firewalla (niestety nadal stosunkowo często), użycie protokołu CORS jest niebezpieczne (właśnie z tego powodu protokół CORS miał zostać wynaleziony).

Jednakże w innych przypadkach używa się następującego nagłówka:

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
Access-Control-Allow-Origin: *

Nawet jeśli zasób eksponuje dodatkową informację na podstawie ciastka lub uwierzytelnienia HTTP, to użycie powyższego nagłówka nie ujawni jej. Będzie dzielić zasób z interfejsami API, takimi jak XMLHttpRequest, podobnie jak jest on dzielony w przypadku curl i wget.

Innymi słowy, jeśli zasób nie może być dostępny z losowego urządzenia podłączonego do sieci za pomocą curl i wget, to wyżej wymieniony nagłówek nie jest uwzględniany. Jeżeli jednak może być dostępny, to jak najbardziej można tak robić.

CORS protocol and HTTP caches#

Jeśli wymagania dla protokołu CORS są bardziej skomplikowane niż ustawienie nagłówka `Access-Control-Allow-Origin` na * lub statyczne pochodzenie, to musi być użyte `Vary`:

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
Vary: Access-Control-Allow-Origin
Pasek społecznościowy

SPIS TREŚCI AKTUALNEJ STRONY

Ogólne (H1) Fetch (H2) Infrastructure (H3) byte case-insensitive (H4) case-insensitive byte sequence (H4) byte lowercase (H4) byte lowercase (H4) queue a fetch task (H4) HTTP (H4) Methods (H5) method (H6) simple method (H6) forbidden method (H6) normalize (H6) Headers (H5) header list (H6) append (H6) delete (H6) set (H6) combine (H6) header (H6) simple header (H6) forbidden header name (H6) forbidden response header name (H6) parse a header value (H6) extract a MIME type (H6) Bodies (H5) body (H6) handle content codings (H6) Requests (H5) request (H6) method (H6) url (H6) sandboxed storage area URLs flag (H6) header list (H6) unsafe request flag (H6) body (H6) client (H6) skip service worker flag (H6) context (H6) context frame type (H6) origin (H6) force Origin header flag (H6) same-origin data URL flag (H6) referrer (H6) authentication flag (H6) synchronous flag (H6) mode (H6) credentials mode (H6) use URL credentials flag (H6) cache mode (H6) manual redirect flag (H6) redirect count (H6) response tainting (H6) Responses (H5) response (H6) type (H6) termination reason (H6) url (H6) status (H6) status message (H6) header list (H6) body (H6) cache state (H6) TLS state (H6) network error (H6) filtered response (H6) basic filtered response (H6) CORS filtered response (H6) opaque filtered response (H6) Authentication entries (H4) HTTP extensions (H3) `Origin` header (H4) CORS protocol (H4) General (H5) HTTP requests (H5) CORS request (H6) CORS preflight request (H6) HTTP responses (H5) HTTP new header syntax (H5) Fetching (H3) fetch (H4) basic fetch (H4) HTTP fetch (H4) HTTP network or cache fetch (H4) CORS preflight fetch (H4) CORS preflight cache (H4) clear cache entries (H4) cache match (H4) method cache match (H4) header name cache match (H4) CORS check (H4) Background reading (H3) HTTP header layer division (H4) Atomic HTTP redirect handling (H4) Basic safe CORS protocol setup (H4) CORS protocol and HTTP caches (H4)