Cross-Origin Request sharing (CORS): Zapytania prefight

Po ostatnim poście powinno być jasne dlaczego i kiedy warto używać CORS. Przedstawiony przykład pokazywał dwa kluczowe nagłówki: origin oraz Access-Control-Allow-Origin. W praktyce jednak, może zdarzyć się, że przeglądarka wyśle dodatkowy pakiet, tzw. “prefight”. Przeglądarki omijają ten etap, gdy następujące warunki sa spełnione:

  1. Zapytanie jest typu GET, HEAD lub POST
  2. W nagłówku nie ma innych zapytań niż  Accept, Accept-Language, Content-Language lub Content-Type
  3. Content-Type ma wyłącznie wartości takie jak: application/x-www-form-urlencoded, multipart/form-data, text/plain

W przeciwnym wypadku, pakiet prefight zostanie wysłany. Najprostszy przykład takiego pakietu, wysyłanego przez klienta do usługi to:

OPTIONS /
Host: bar.com
Origin: http://foo.com

Przede wszystkim, prefight używa HTTP Options, gdzie jako wartość często podaje się adres usługi. Dodatkowo, można skorzystać z nagłówków Access-Control-Request-Method lub Access-Control-Request-Headers. Pierwszy z nich służy do określenia metod HTTP z jakich chcemy skorzystać (GET, PUT itp.). Drugi z kolei, zawiera dodatkowe nagłówki, jakie klient chce ustawić (niestandardowe). Przykład:

OPTIONS http://service.com/hello HTTP/1.1
Accept: */*
Origin: http://client.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: accept, x-my-custom-header
Accept-Encoding: gzip, deflate

W odpowiedzi z kolei, dostajemy standardowo Access-Control-Allow-Origin oraz dodatkowo Access-Control-Allow-Methods:

Access-Control-Allow-Origin: http://foo.com
Access-Control-Allow-Methods: PUT, DELETE

W przypadku, gdy wszystko zgadza się (origin, methods) wtedy dopiero przeglądarka wysyła właściwe zapytanie między domenowe. Jak widać, w przypadku niestandardowych zapytań, czas wykonania może być trochę dłuższy ze względu na liczbę wysyłanych i odbieranych pakietów.

Leave a Reply

Your email address will not be published.