Lista pól nagłówka HTTP

HTTP
HTTP logo.svg
Metody żądań
Pola nagłówka
Kody statusu odpowiedzi
Bezpieczne metody kontroli dostępu
Luki w zabezpieczeniach

Pola nagłówka HTTP to lista ciągów znaków wysyłanych i odbieranych zarówno przez program kliencki, jak i serwer przy każdym żądaniu i odpowiedzi HTTP. Te nagłówki są zwykle niewidoczne dla użytkownika końcowego i są przetwarzane lub rejestrowane tylko przez serwer i aplikacje klienckie. Określają sposób kodowania informacji wysyłanych/odbieranych przez połączenie (jak w Content-Encoding ), weryfikację sesji i identyfikację klienta (jak w ciasteczkach przeglądarki , adresie IP, kliencie użytkownika ) lub ich anonimowość (maskowanie VPN lub proxy, fałszowanie agenta użytkownika), sposób, w jaki serwer powinien obchodzić się z danymi (jak w przypadku funkcji Do-Not-Track ), wiek (czas przebywania we współdzielonej pamięci podręcznej ) dokumentu pobrane m.in.

Format ogólny

W HTTP w wersji 1.x pola nagłówka są przesyłane po linii żądania (w przypadku wiadomości HTTP żądania) lub linii odpowiedzi (w przypadku wiadomości HTTP odpowiedzi), która jest pierwszą linią wiadomości. Pola nagłówka to rozdzielone dwukropkami pary klucz-wartość w ciągu znaków zwykłego tekstu , zakończone sekwencją znaków powrotu karetki (CR) i nowego wiersza (LF). Koniec sekcji nagłówka jest oznaczony pustą linią pola, co skutkuje transmisją dwóch kolejnych par CR-LF. W przeszłości długie linie można było składać w wiele linii; linie kontynuacji są oznaczone obecnością spacji (SP) lub poziomej tabulacji (HT) jako pierwszego znaku w następnej linii. To składanie zostało uznane za przestarzałe w dokumencie RFC 7230.

HTTP/2 i HTTP/3 zamiast tego używają protokołu binarnego , w którym nagłówki są kodowane w jednym nagłówku i zero lub więcej ramek KONTYNUACJI przy użyciu HPACK (HTTP/2) lub QPACK (HTTP/3), które zapewniają wydajną kompresję nagłówka. Wiersz żądania lub odpowiedzi z protokołu HTTP/1 został również zastąpiony kilkoma polami pseudonagłówka, z których każde zaczyna się od dwukropka ( : ) .

Nazwy pól

  Podstawowy zestaw pól jest znormalizowany przez Internet Engineering Task Force (IETF) w dokumentach RFC 9110 i 9111 . Nazwy pól , pola nagłówków i repozytorium tymczasowych rejestracji są utrzymywane przez IANA . Każda aplikacja może zdefiniować dodatkowe nazwy pól i dopuszczalne wartości.

W nazwach pól nagłówka nie jest rozróżniana wielkość liter. Kontrastuje to z nazwami metod HTTP (GET, POST itp.), w których rozróżniana jest wielkość liter.

HTTP/2 nakłada pewne ograniczenia na określone pola nagłówka (patrz poniżej).

Niestandardowe pola nagłówka były konwencjonalnie oznaczane przez poprzedzenie nazwy pola X- , ale ta konwencja została wycofana w czerwcu 2012 r. Z powodu niedogodności, jakie powodowała, gdy niestandardowe pola stały się standardem. Wcześniejsze ograniczenie korzystania z obniżonej wersji zostało zniesione w marcu 2013 r.

Wartości pól

Kilka pól może zawierać komentarze (np. pola User-Agent, Server, Via), które oprogramowanie może zignorować.

Wiele wartości pól może zawierać parę klucz-wartość jakości ( q ) oddzieloną znakiem równości , określającą wagę używaną w negocjacjach treści . Na przykład przeglądarka może wskazać, że akceptuje informacje w języku niemieckim lub angielskim, z preferowanym językiem niemieckim, ustawiając wartość q dla de wyższą niż en , w następujący sposób:

Zaakceptuj język: de; q=1,0, en; q=0,5

Limity wielkości

Norma nie nakłada żadnych ograniczeń co do rozmiaru każdej nazwy pola nagłówka lub wartości, ani co do liczby pól. Jednak większość serwerów, klientów i oprogramowania proxy nakłada pewne ograniczenia ze względów praktycznych i bezpieczeństwa. Na przykład serwer Apache 2.3 domyślnie ogranicza rozmiar każdego pola do 8190 bajtów, a w jednym żądaniu może być maksymalnie 100 pól nagłówka.

Pola żądań

Standardowe pola żądania

Nazwa Opis Przykład Status Standard
CEL Akceptowalne manipulacje instancjami dla żądania. A-IM: kanał Stały   RFC3229 _
Zaakceptować Rodzaje mediów , które są akceptowalne dla odpowiedzi. Zobacz negocjowanie zawartości . Zaakceptuj: tekst/html Stały   RFC9110 _
Zaakceptuj zestaw znaków Akceptowalne zestawy znaków. Zaakceptuj zestaw znaków: utf-8 Stały   RFC9110 _
Zaakceptuj-Datetime Dopuszczalna wersja w czasie. Zaakceptuj-Datetime: czwartek, 31 maja 2007 r., 20:35:00 GMT Tymczasowy   RFC7089 _
Zaakceptuj kodowanie Lista akceptowanych kodowań. Zobacz Kompresja HTTP . Zaakceptuj kodowanie: gzip, deflate Stały   RFC9110 _
Zaakceptuj język Lista akceptowanych języków ludzkich do odpowiedzi. Zobacz negocjowanie zawartości . Zaakceptuj język: en-US Stały   RFC9110 _

Metoda-Żądania-Kontroli Dostępu, Nagłówki-Żądań-Kontroli Dostępu 		Inicjuje żądanie udostępnienia zasobów między źródłami w Origin (poniżej). Metoda żądania kontroli dostępu: GET Stały: standardowy
Upoważnienie Poświadczenia uwierzytelniające dla uwierzytelniania HTTP . Autoryzacja: podstawowa QWxhZGRpbjpvcGVuIHNlc2FtZQ== Stały   RFC9110 _
Kontrola pamięci podręcznej Służy do określania dyrektyw, które muszą być przestrzegane przez wszystkie mechanizmy buforowania w łańcuchu żądanie-odpowiedź. Kontrola pamięci podręcznej: bez pamięci podręcznej Stały   RFC9111 _
Połączenie Opcje kontrolne dla bieżącego połączenia i lista pól żądań typu hop-by-hop.

Nie wolno używać z HTTP/2.

 Połączenie: utrzymanie aktywności

Połączenie: aktualizacja

Stały   RFC9110 _
Kodowanie treści Typ kodowania używanego w danych. Zobacz Kompresja HTTP . Kodowanie treści: gzip Stały   RFC9110 _
Długość treści Długość treści żądania w oktetach (8-bitowych bajtach). Długość treści: 348 Stały   RFC9110 _
Treść-MD5 Zakodowana w formacie Base64 binarna suma MD5 zawartości treści żądania. Treść-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== Przestarzały   Dokumenty RFC 1544 , 1864 , 4021
Typ zawartości Typ nośnika treści żądania (używany z żądaniami POST i PUT). Typ treści: application/x-www-form-urlencoded Stały   RFC9110 _
Ciastko Plik cookie HTTP wysłany wcześniej przez serwer za pomocą Set-Cookie (poniżej). Plik cookie: $Wersja=1; Skórka=nowa; Stały: standardowy   RFC 2965 , 6265
Data Data i godzina powstania wiadomości (w formacie „HTTP-date” zgodnie z definicją w dokumencie RFC 9110: semantyka HTTP, sekcja 5.6.7 „Formaty daty/godziny” ). Data: wtorek, 15 listopada 1994 r., 08:12:31 GMT Stały   RFC9110 _
Oczekiwać Wskazuje, że klient wymaga określonego zachowania serwera. Spodziewaj się: 100-kontynuuj Stały   RFC9110 _
Przekazano Ujawnij oryginalne informacje o kliencie łączącym się z serwerem WWW za pośrednictwem serwera proxy HTTP. Przekazano: for=192.0.2.60;proto=http;by=203.0.113.43 Przekazano: for=192.0.2.43, for=198.51.100.17 Stały   RFC7239 _
Z Adres e-mail użytkownika zgłaszającego żądanie. Od: uż[email protected] Stały   RFC9110 _
Gospodarz Nazwa domeny serwera (dla hostingu wirtualnego ) oraz numer portu TCP , na którym nasłuchuje serwer. Numer portu można pominąć, jeśli port jest standardowym portem dla żądanej usługi.

Obowiązkowe od HTTP/1.1. Jeśli żądanie jest generowane bezpośrednio w HTTP/2, nie należy go używać.

 Host: en.wikipedia.org:8080

Gospodarz: pl.wikipedia.org

Ustawienia HTTP2 Żądanie aktualizacji z HTTP/1.1 do HTTP/2 MUSI zawierać dokładnie jedno pole nagłówka HTTP2-Setting . Pole nagłówka HTTP2-Settings to pole nagłówka specyficzne dla połączenia, które zawiera parametry regulujące połączenie HTTP/2, dostarczane w oczekiwaniu na zaakceptowanie przez serwer żądania aktualizacji. Ustawienia HTTP2: token64 Stały: standardowy
Jeśli-dopasuj Wykonuj akcję tylko wtedy, gdy jednostka dostarczona przez klienta jest zgodna z tą samą jednostką na serwerze. Dotyczy to głównie metod takich jak PUT, które aktualizują zasób tylko wtedy, gdy nie został on zmodyfikowany od czasu ostatniej aktualizacji użytkownika. Jeśli dopasowanie: „737060cd8c284d8af7ad3082f209582d” Stały   RFC9110 _
Jeśli-zmodyfikowano-od Umożliwia zwrócenie 304 Not Modified, jeśli treść nie uległa zmianie. Jeśli-zmodyfikowano-od: sob., 29 października 1994 r. 19:43:31 GMT Stały   RFC9110 _
Brak dopasowania Umożliwia zwrócenie komunikatu 304 Not Modified, jeśli treść jest niezmieniona, patrz HTTP ETag . Brak dopasowania: „737060cd8c284d8af7ad3082f209582d” Stały   RFC9110 _
Jeśli-zakres Jeśli istota się nie zmieniła, wyślij mi brakujące części; w przeciwnym razie wyślij mi całą nową jednostkę. Jeśli-zakres: „737060cd8c284d8af7ad3082f209582d” Stały   RFC9110 _
Jeśli-niezmodyfikowany-od Wysyłaj odpowiedź tylko wtedy, gdy encja nie była modyfikowana od określonego czasu. Jeśli-niemodyfikowany-od: Sob, 29 października 1994 19:43:31 GMT Stały   RFC9110 _
Max-Forward Ogranicz liczbę przypadków, w których wiadomość może zostać przekazana przez serwery proxy lub bramy. Maksymalna liczba napastników: 10 Stały   RFC9110 _
Pochodzenie Inicjuje żądanie udostępnienia zasobów między źródłami (prosi serwer o pola odpowiedzi Access-Control-* ). Pochodzenie: http://www.example-social-network.com Stały: standardowy   RFC6454 _
Pragma Pola specyficzne dla implementacji, które mogą mieć różne efekty w dowolnym miejscu łańcucha żądanie-odpowiedź. Pragma: bez pamięci podręcznej Stały   RFC9111 _
Woleć Pozwala klientowi zażądać, aby serwer zastosował określone zachowania podczas przetwarzania żądania. Preferuj: powrót = reprezentacja Stały RFC7240
Upoważnienie pełnomocnika Poświadczenia autoryzacji do łączenia się z serwerem proxy. Autoryzacja proxy: podstawowa QWxhZGRpbjpvcGVuIHNlc2FtZQ== Stały   RFC9110 _
Zakres Żądaj tylko części encji. Bajty są numerowane od 0. Zobacz Obsługa bajtów . Zakres: bajtów=500-999 Stały   RFC9110 _
Referent [ sic ] Jest to adres poprzedniej strony internetowej, z której nastąpiło przekierowanie do aktualnie żądanej strony. (Słowo „referrer” zostało błędnie zapisane w RFC, a także w większości implementacji do tego stopnia, że ​​stało się standardowym użyciem i jest uważane za poprawną terminologię) Strona odsyłająca: http://en.wikipedia.org/wiki/Main_Page Stały   RFC9110 _
TE Kodowanie transferu, które agent użytkownika jest skłonny zaakceptować: można użyć tych samych wartości, co w polu nagłówka odpowiedzi Transfer-Encoding, plus wartość „zwiastunów” (związana z metodą przesyłania „fragmented”), aby powiadomić serwer, którego oczekuje otrzymać dodatkowe pola w zwiastunie po ostatnim kawałku o zerowym rozmiarze.

W protokole HTTP/2 obsługiwane są tylko zwiastuny .

TE: przyczepy, spuść powietrze Stały   RFC9110 _
Przyczepa Wartość pola Trailer general wskazuje, że dany zestaw pól nagłówka jest obecny w zwiastunie wiadomości zakodowanej przy użyciu fragmentarycznego kodowania transferu . Zwiastun: Max-Forwards Stały   RFC9110 _
Kodowanie transferu Forma kodowania używana do bezpiecznego przekazania podmiotu użytkownikowi. Obecnie zdefiniowane metody to: chunked , compress, deflate, gzip, identity.

Nie wolno używać z HTTP/2.

 Kodowanie transferu: podzielone Stały   RFC9110 _
Agent użytkownika Ciąg agenta użytkownika agenta użytkownika. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 Stały   RFC9110 _
Aktualizacja Poproś serwer o uaktualnienie do innego protokołu.

Nie wolno używać w protokole HTTP/2.

 Aktualizacja: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket Stały   RFC9110 _
Przez Informuje serwer o serwerach proxy, przez które wysłano żądanie. Przez: 1.0 fred, 1.1 example.com (Apache/1.1) Stały   RFC9110 _
Ostrzeżenie Ogólne ostrzeżenie o możliwych problemach z treścią podmiotu. Ostrzeżenie: 199 Różne ostrzeżenia Przestarzały   RFC 7234 , 9111

Typowe niestandardowe pola żądań

Nazwa pola Opis Przykład
Niezabezpieczone żądania aktualizacji Informuje serwer, który (prawdopodobnie w trakcie migracji HTTP -> HTTPS) obsługuje mieszane treści, że klient wolałby przekierowanie do HTTPS i może obsłużyć Content-Security-Policy: upgrade-insecure-requests

Nie wolno używać z HTTP/2

 Niezabezpieczone żądania aktualizacji: 1
X-Wnioskowano-Z Używany głównie do identyfikacji żądań Ajax (większość frameworków JavaScript wysyła to pole z wartością XMLHttpRequest ); identyfikuje również aplikacje na Androida za pomocą WebView X-Requested-With: XMLHttpRequest
DNT Żąda od aplikacji internetowej wyłączenia śledzenia użytkownika. To jest wersja Mozilli pola nagłówka X-Do-Not-Track (od Firefoksa 4.0 Beta 11). Safari i IE9 również obsługują to pole. W dniu 7 marca 2011 r. projekt wniosku został złożony do IETF. Grupa W3C ds. ochrony przed śledzeniem opracowuje specyfikację. DNT: 1 (bez śledzenia włączone)

DNT: 0 (nie śledź wyłączone)

X-przekazany-za De facto standard identyfikacji początkowego adresu IP klienta łączącego się z serwerem WWW za pośrednictwem serwera proxy HTTP lub modułu równoważenia obciążenia. Zastąpiony przez przekazany nagłówek. X-Forwarded-For: klient1, proxy1, proxy2

X-przekazany-za: 129.78.138.66, 129.78.64.103

X-Forwarded-Host De facto standard identyfikacji pierwotnego hosta żądanego przez klienta w nagłówku żądania Host HTTP, ponieważ nazwa hosta i/lub port odwrotnego proxy (systemu równoważenia obciążenia) może różnić się od serwera pochodzenia obsługującego żądanie. Zastąpiony przez przekazany nagłówek. X-Forwarded-Host: en.wikipedia.org:8080

X-Forwarded-Host: en.wikipedia.org

X-Forwarded-Proto De facto standard identyfikacji protokołu źródłowego żądania HTTP, ponieważ odwrotne proxy (lub system równoważenia obciążenia) może komunikować się z serwerem WWW za pomocą HTTP, nawet jeśli żądanie do odwrotnego proxy to HTTPS. Alternatywna forma nagłówka (X-ProxyUser-Ip) jest używana przez klientów Google rozmawiających z serwerami Google. Zastąpiony przez przekazany nagłówek. X-Forwarded-Proto: https
Https front-endu Niestandardowe pole nagłówka używane przez aplikacje firmy Microsoft i systemy równoważenia obciążenia Front-End-Https: włączony
Zastąpienie metody X-Http Żąda od aplikacji internetowej zastąpienia metody określonej w żądaniu (zwykle POST) metodą podaną w polu nagłówka (zwykle PUT lub DELETE). Można to wykorzystać, gdy agent użytkownika lub zapora ogniowa uniemożliwia bezpośrednie wysyłanie metod PUT lub DELETE (zauważ, że jest to albo błąd w komponencie oprogramowania, który należy naprawić, albo celowa konfiguracja, w którym to przypadku pominięcie może być źle zrobić). Zastąpienie metody X-HTTP: USUŃ
Identyfikator urządzenia X-ATT Umożliwia łatwiejsze parsowanie MakeModel/Firmware, które zwykle znajduje się w ciągu User-Agent urządzeń AT&T Identyfikator urządzenia X-Att: GT-P7320/P7320XXLPG
Profil X-Wap Linki do pliku XML w Internecie z pełnym opisem i szczegółami dotyczącymi aktualnie podłączonego urządzenia. W przykładzie po prawej stronie znajduje się plik XML dla AT&T Samsung Galaxy S2. profil x-wap: http://wap.samsungmobile.com/uaprof/SGH-I777.xml
Połączenie proxy Zaimplementowane jako niezrozumienie specyfikacji HTTP. Powszechne z powodu błędów w implementacjach wczesnych wersji HTTP. Posiada dokładnie taką samą funkcjonalność jak standardowe pole Connection.

Nie wolno używać z HTTP/2.

 Połączenie proxy: utrzymanie aktywności
X-UIDH Głębokie wstawianie pakietu po stronie serwera unikalnego identyfikatora identyfikującego klientów Verizon Wireless ; znany również jako „perma-cookie” lub „supercookie” X-UIDH: ...
X-Csrf-Token Służy do zapobiegania fałszowaniu żądań między witrynami . Alternatywne nazwy nagłówków to: X-CSRFToken i X-XSRF-TOKEN X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
X-Request-ID,

Identyfikator korelacji X, Identyfikator korelacji

 Koreluje żądania HTTP między klientem a serwerem. X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
Zapisz dane Nagłówek żądania podpowiedzi klienta Save-Data dostępny w przeglądarkach Chrome, Opera i Yandex umożliwia programistom dostarczanie lżejszych, szybszych aplikacji użytkownikom, którzy zdecydują się na tryb oszczędzania danych w przeglądarce. Zapisz dane: wł

Pola odpowiedzi

Standardowe pola odpowiedzi

Nazwa pola Opis Przykład Status Standard
Zaakceptuj-CH Żąda wskazówek klienta HTTP Zaakceptuj-CH: UA, Platforma Eksperymentalny   RFC8942 _





Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Expose-Headers, Access-Control-Max-Age, Access-Control-Allow-Methods, Access-Control-Allow-Headers 		Określanie, które witryny internetowe mogą uczestniczyć w udostępnianiu zasobów między źródłami Access-Control-Allow-Origin: * Stały: standardowy   RFC7480 _
Zaakceptuj poprawkę Określa, które formaty dokumentów poprawek są obsługiwane przez ten serwer Zaakceptuj poprawkę: text/example;charset=utf-8 Stały   RFC5789 _
Zaakceptuj zakresy Jakie typy częściowego zakresu treści obsługuje ten serwer za pośrednictwem udostępniania bajtów Zaakceptuj zakresy: bajty Stały   RFC9110 _
Wiek Wiek obiektu w pamięci podręcznej serwera proxy w sekundach Wiek: 12 lat Stały   RFC9111 _
Umożliwić Prawidłowe metody dla określonego zasobu. Do użycia w metodzie 405 niedozwolone Zezwalaj: DOBIERZ, GŁOWĘ Stały   RFC9110 _
Alt-Svc Serwer używa nagłówka „Alt-Svc” (oznaczającego usługi alternatywne), aby wskazać, że dostęp do jego zasobów można również uzyskać w innej lokalizacji sieciowej (host lub port) lub przy użyciu innego protokołu

Podczas korzystania z protokołu HTTP/2 serwery powinny zamiast tego wysyłać ramkę ALTSVC.

 Alt-Svc: http/1.1="http2.example.com:8001"; ma=7200 Stały
Kontrola pamięci podręcznej Informuje wszystkie mechanizmy buforowania od serwera do klienta, czy mogą buforować ten obiekt. Jest mierzony w sekundach Kontrola pamięci podręcznej: maksymalny wiek = 3600 Stały   RFC9111 _
Połączenie Opcje sterowania dla bieżącego połączenia i lista pól odpowiedzi typu hop-by-hop.

Nie wolno używać z HTTP/2.

 Połączenie: zamknięte Stały   RFC9110 _
Dyspozycja treści Możliwość wywołania okna dialogowego „Pobieranie pliku” dla znanego typu MIME w formacie binarnym lub zasugerowania nazwy pliku dla zawartości dynamicznej. Cytaty są konieczne ze znakami specjalnymi. Treść-dyspozycja: załącznik; nazwa_pliku="nazwa pliku.roz" Stały   Dokumenty RFC 2616 , 4021 , 6266
Kodowanie treści Typ kodowania używanego w danych. Zobacz Kompresja HTTP . Kodowanie treści: gzip Stały   RFC9110 _
Język treści Naturalny język lub języki docelowych odbiorców załączonych treści Język treści: da Stały   RFC9110 _
Długość treści Długość treści odpowiedzi w oktetach (8-bitowych bajtów) Długość treści: 348 Stały   RFC9110 _
Lokalizacja zawartości Alternatywna lokalizacja zwróconych danych Lokalizacja zawartości: /index.htm Stały   RFC9110 _
Treść-MD5 formacie Base64 binarna suma MD5 treści odpowiedzi Treść-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== Przestarzały   Dokumenty RFC 1544 , 1864 , 4021
Zakres treści Gdzie w pełnej treści wiadomości należy ta częściowa wiadomość Zakres treści: bajty 21010-47021/47022 Stały   RFC9110 _
Typ zawartości Typ MIME tej zawartości Typ zawartości: text/html; zestaw znaków=utf-8 Stały   RFC9110 _
Data Data i godzina wysłania wiadomości (w formacie „HTTP-date” zgodnie z RFC 9110) Data: wtorek, 15 listopada 1994 r., 08:12:31 GMT Stały   RFC9110 _
Baza Delta Określa tag jednostki z kodowaniem delta odpowiedzi. Podstawa Delta: „abc” Stały   RFC3229 _
Etag Identyfikator określonej wersji zasobu, często skrót wiadomości ETag: „737060cd8c284d8af7ad3082f209582d” Stały   RFC9110 _
Wygasa Podaje datę/godzinę, po której odpowiedź jest uważana za nieaktualną (w formacie „HTTP-date” zgodnie z definicją w RFC 9110) Wygasa: czw., 1 grudnia 1994 r., 16:00:00 GMT Stały: standardowy   RFC9111 _
JESTEM Manipulacje instancjami zastosowane do odpowiedzi. IM: karm Stały   RFC3229 _
Ostatnio zmodyfikowany Data ostatniej modyfikacji żądanego obiektu (w formacie „HTTP-date” zgodnie z RFC 9110) Ostatnia modyfikacja: wtorek, 15 listopada 1994 r., 12:45:26 GMT Stały   RFC9110 _
Połączyć Używany do wyrażenia relacji typu z innym zasobem, gdzie typ relacji jest zdefiniowany przez RFC 5988 Połączyć: ; rel="alternatywny" Stały   RFC5988 _
Lokalizacja Używany w przekierowaniu lub gdy został utworzony nowy zasób.
  • Przykład 1: Lokalizacja: http://www.w3.org/pub/WWW/People.html
  • Przykład 2: Lokalizacja: /pub/WWW/Ludzie.html
Stały   RFC9110 _
P3P To pole ma na celu ustawienie polityki P3P , w postaci P3P:CP="your_compact_policy" . Jednak P3P nie odniosło sukcesu, większość przeglądarek nigdy go w pełni nie zaimplementowała, wiele stron internetowych ustawia to pole z fałszywym tekstem polityki, co wystarczyło, aby oszukać przeglądarki istnieniem polityki P3P i przyznać uprawnienia do plików cookie stron trzecich . P3P: CP="To nie jest polityka P3P! Zobacz https://en.wikipedia.org/wiki/Special:CentralAutoLogin/P3P, aby uzyskać więcej informacji." Stały
Pragma Pola specyficzne dla implementacji, które mogą mieć różne skutki w dowolnym miejscu łańcucha żądanie-odpowiedź. Pragma: bez pamięci podręcznej Stały   RFC9111 _
Zastosowano preferencje Wskazuje, które tokeny preferencji zostały honorowane przez serwer i zastosowane do przetwarzania żądania. Zastosowano preferencje: return=representation Stały RFC7240
Uwierzytelnianie proxy Poproś o uwierzytelnienie, aby uzyskać dostęp do serwera proxy. Uwierzytelnianie proxy: podstawowe Stały   RFC9110 _
Kołki klucza publicznego Przypinanie klucza publicznego HTTP ogłasza skrót autentycznego certyfikatu TLS witryny Kołki klucza publicznego: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; Stały   RFC7469 _
Spróbuj ponownie po Jeśli encja jest chwilowo niedostępna, to instruuje klienta, aby spróbował ponownie później. Wartość może być określonym przedziałem czasu (w sekundach) lub datą HTTP.
  • Przykład 1: Spróbuj ponownie po: 120
  • Przykład 2: Ponów próbę po: piątek, 7 listopada 2014 r., 23:59:59 GMT

Stały

   RFC9110 _
serwer Nazwa serwera Serwer: Apache/2.4.1 (Unix) Stały   RFC9110 _
Plik cookie HTTP Set-Cookie: UserID=JohnDoe; Maksymalny wiek=3600; Wersja=1 Stały: standardowy   RFC6265 _
Ścisłe bezpieczeństwo transportu Zasady HSTS informujące klienta HTTP, jak długo buforować zasady HTTPS i czy dotyczy to subdomen. Strict-Transport-Security: max-age=16070400; zawierać subdomeny Stały: standardowy
Przyczepa Wartość pola Trailer general wskazuje, że dany zestaw pól nagłówka jest obecny w zwiastunie wiadomości zakodowanej przy użyciu fragmentarycznego kodowania transferu . Zwiastun: Max-Forwards Stały   RFC9110 _
Kodowanie transferu Forma kodowania używana do bezpiecznego przekazania podmiotu użytkownikowi. Obecnie zdefiniowane metody to: chunked , compress, deflate, gzip, identity.

Nie wolno używać z HTTP/2.

 Kodowanie transferu: podzielone Stały   RFC9110 _
Tk Nagłówek stanu śledzenia, wartość sugerowana do wysłania w odpowiedzi na DNT (do-not-track), możliwe wartości: 
 „!” - w budowie "?"  — dynamiczna „G” — brama do wielu stron „N” — brak śledzenia „T” — śledzenie „C” — śledzenie za zgodą „P” — śledzenie tylko za zgodą „D” — pomijanie DNT „U” — aktualizacja
Tk: ? Stały
Aktualizacja Poproś klienta o uaktualnienie do innego protokołu.

Nie wolno używać w protokole HTTP/2

 Aktualizacja: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket Stały   RFC9110 _
Różnić się Informuje serwery proxy podrzędne, jak dopasować przyszłe nagłówki żądań, aby zdecydować, czy można użyć buforowanej odpowiedzi, zamiast żądać nowej z serwera źródłowego.
  • Przykład 1: Różne: *
  • Przykład 2: Vary: Accept-Language
Stały   RFC9110 _
Przez Informuje klienta o serwerach proxy, przez które wysłano odpowiedź. Przez: 1.0 fred, 1.1 example.com (Apache/1.1) Stały   RFC9110 _
Ostrzeżenie Ogólne ostrzeżenie o możliwych problemach z treścią podmiotu. Ostrzeżenie: 199 Różne ostrzeżenia Przestarzały   RFC 7234 , 9111
Uwierzytelnianie WWW Wskazuje schemat uwierzytelniania, którego należy użyć w celu uzyskania dostępu do żądanej jednostki. Uwierzytelnianie WWW: podstawowe Stały   RFC9110 _
Opcje X-Frame Zabezpieczenie przed przechwytywaniem kliknięć : deny - brak renderowania w ramce, sameorigin - brak renderowania w przypadku niezgodności pochodzenia, allow-from - zezwolenie z określonej lokalizacji, allowall - niestandardowe, zezwolenie z dowolnej lokalizacji Opcje X-Frame: odmów Przestarzały

Typowe niestandardowe pola odpowiedzi

Nazwa pola Opis Przykład


Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP 		Polityki bezpieczeństwa treści . X-WebKit-CSP: default-src 'self'
Spodziewaj się-CT Powiadom, aby preferować wymuszanie przezroczystości certyfikatu . Expect-CT: max-age=604800, wymuszaj, report-uri=" https://example.example/report "
NEL Służy do konfigurowania rejestrowania żądań sieciowych. NEL : { "report_to" : "nazwa_grupy_raportowania" , "max_age" : 12345 , "include_subdomains" : false , "success_fraction" : 0.0 , "failure_fraction" : 1.0 }
Polityka uprawnień Aby umożliwić lub wyłączyć różne funkcje lub interfejsy API przeglądarki. Polityka uprawnień: pełny ekran=(), kamera=(), mikrofon=(), geolokalizacja=(), kohorta zainteresowań=()
Odświeżać Używany w przekierowaniu lub gdy został utworzony nowy zasób. To odświeżenie przekierowuje po 5 sekundach. Rozszerzenie nagłówka wprowadzone przez firmę Netscape i obsługiwane przez większość przeglądarek internetowych. Zdefiniowane przez standard HTML Odśwież: 5; adres URL=
Zgłoś do Nakazuje agentowi użytkownika przechowywanie punktów końcowych raportowania dla źródła. Report-To : { "group" : "csp-endpoint" , "max_age" : 10886400 , "endpoints" : [ { "url" : "https-url-witryny-która-zbiera-raporty" } ] }
Status Pole nagłówka CGI określające stan odpowiedzi HTTP. Normalne odpowiedzi HTTP zamiast tego używają oddzielnej „linii stanu”, zdefiniowanej w dokumencie RFC 9110. Stan: 200 OK
Timing-Allow-Origin Nagłówek odpowiedzi Timing-Allow-Origin określa źródła, które mogą wyświetlać wartości atrybutów pobranych za pomocą funkcji interfejsu API synchronizacji zasobów , które w przeciwnym razie byłyby zgłaszane jako zero ze względu na ograniczenia między źródłami. Timing-Allow-Origin: *

Timing-Allow-Origin: [, ]*

X-Content-Duration Podaj czas trwania audio lub wideo w sekundach; obsługiwane tylko przez przeglądarki Gecko Czas trwania treści X: 42,666
X-Content-Type-Options Jedyna zdefiniowana wartość, „nosniff”, uniemożliwia Internet Explorerowi podsłuchiwanie MIME odpowiedzi poza zadeklarowanym typem zawartości. Dotyczy to również przeglądarki Google Chrome podczas pobierania rozszerzeń. X-Content-Type-Options: nosniff
X-Powered-By Określa technologię (np. ASP.NET, PHP, JBoss) obsługującą aplikację internetową (szczegóły wersji są często w X-Runtime , X-Version lub X-AspNet-Version ) X-Powered-By: PHP/5.4.0
Przekierowanie X przez Określa komponent odpowiedzialny za określone przekierowanie.
X-Redirect-By: WordPress X-Redirect-By: Polylang
X-identyfikator-żądania, X-identyfikator-korelacji Koreluje żądania HTTP między klientem a serwerem. X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
Kompatybilny z X-UA Zaleca preferowany silnik renderujący (często tryb zgodności wstecznej) do wyświetlania treści. Służy również do aktywacji Chrome Frame w Internet Explorerze. W standardzie HTML zdefiniowana jest tylko wartość IE=edge .

X-UA-Compatible: IE=edge X-UA-Compatible: IE=EmulateIE7 X-UA-Compatible: Chrome=1
Ochrona X-XSS cross-site scripting (XSS). Ochrona X-XSS: 1; tryb = blok

Efekty wybranych pól

Unikanie buforowania

Jeśli serwer WWW odpowie za pomocą Cache-Control: no-cache , wówczas przeglądarka internetowa lub inny system buforowania (pośrednie serwery proxy) nie może używać odpowiedzi w celu zaspokojenia kolejnych żądań bez uprzedniego sprawdzenia z serwerem źródłowym (ten proces nazywa się sprawdzaniem poprawności). To pole nagłówka jest częścią protokołu HTTP w wersji 1.1 i jest ignorowane przez niektóre pamięci podręczne i przeglądarki. Można to zasymulować, ustawiając Expires HTTP version 1.0 na czas wcześniejszy niż czas odpowiedzi. Zauważ, że no-cache nie instruuje przeglądarki ani serwerów proxy o tym, czy zawartość ma być buforowana. Po prostu mówi przeglądarce i serwerom proxy, aby sprawdziły zawartość pamięci podręcznej na serwerze przed jej użyciem (odbywa się to za pomocą wspomnianych powyżej atrybutów If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match). Wysłanie wartości braku pamięci podręcznej instruuje zatem przeglądarkę lub serwer proxy, aby nie korzystały z zawartości pamięci podręcznej jedynie na podstawie „kryteriów aktualności” zawartości pamięci podręcznej. Innym powszechnym sposobem zapobiegania wyświetlaniu użytkownikowi starej zawartości bez weryfikacji jest Kontrola pamięci podręcznej: max-age=0 . To instruuje agenta użytkownika, że ​​zawartość jest nieaktualna i powinna zostać sprawdzona przed użyciem.

Pole nagłówka Cache-Control: no-store ma na celu poinstruowanie aplikacji przeglądarki, aby dołożyła wszelkich starań, aby nie zapisywać jej na dysku (tj. nie buforować).

Żądanie, aby zasób nie był buforowany, nie gwarantuje, że nie zostanie on zapisany na dysku. W szczególności definicja HTTP/1.1 wprowadza rozróżnienie między magazynami historii a pamięciami podręcznymi. Jeśli użytkownik wróci do poprzedniej strony, przeglądarka może nadal wyświetlać stronę, która została zapisana na dysku w magazynie historii. Jest to prawidłowe zachowanie zgodne ze specyfikacją. Wiele programów użytkownika wykazuje różne zachowania podczas ładowania stron z magazynu historii lub pamięci podręcznej w zależności od tego, czy protokołem jest HTTP, czy HTTPS.

Cache -Control: no-cache jest również przeznaczone do użycia w żądaniach wysyłanych przez klienta. Jest to sposób, w jaki przeglądarka informuje serwer i wszelkie pośrednie pamięci podręczne, że potrzebuje nowej wersji zasobu. Pragma : no-cache , zdefiniowane w specyfikacji HTTP/1.0, ma ten sam cel. Jest on jednak zdefiniowany tylko dla nagłówka żądania. Jego znaczenie w nagłówku odpowiedzi nie jest określone. Zachowanie Pragmy: brak pamięci podręcznej w odpowiedzi jest specyficzna dla implementacji. Podczas gdy niektóre aplikacje klienckie zwracają uwagę na to pole w odpowiedziach, HTTP/1.1 RFC wyraźnie ostrzega przed poleganiem na tym zachowaniu.

Zobacz też

Od tej edycji w tym artykule wykorzystano treść artykułu „Co to jest nagłówek http X-REQUEST-ID?” , którego autorem jest Stefan Kögl ze Stack Exchange, który jest licencjonowany w sposób umożliwiający ponowne wykorzystanie na podstawie licencji Creative Commons Attribution-ShareAlike 3.0 Unported License , ale nie na mocy GFDL . Należy przestrzegać wszystkich odpowiednich warunków.

Od tej edycji ten artykuł używa treści z „Dlaczego platforma ASP.NET dodaje nagłówek HTTP„ X-Powered-By:ASP.NET” w odpowiedziach?” , którego autorem jest Adrian Grigore ze Stack Exchange, który jest licencjonowany w sposób umożliwiający ponowne wykorzystanie na podstawie licencji Creative Commons Attribution-ShareAlike 3.0 Unported License , ale nie na mocy GFDL . Należy przestrzegać wszystkich odpowiednich warunków.

Linki zewnętrzne


Pobrano z „ https://en.wikipedia.org/w/index.php?title=List_of_HTTP_header_fields&oldid=1138584422 ”