Nagłówki HTTP | Teleinf Edu

Pola HTTP i kontekst wiadomości

Wiadomość HTTP zawiera żądanie albo odpowiedź wraz z nazwanymi polami metadanych. Pola opisują cel, reprezentację, uwierzytelnianie, buforowanie i reguły przetwarzania. W protokole sieci Web te metadane są przekazywane za pomocą .

W HTTP/1.1 pola następują po linii żądania albo statusu i mają nazwę, w której wielkość liter nie ma znaczenia, oraz wartość po dwukropku. HTTP/2 i HTTP/3 kodują pola w postaci binarnej, zachowując wspólną semantykę. Na przykład Content-Type: text/html identyfikuje typ mediów HTML. Inne pola sterują buforowaniem, uwierzytelnianiem, polityką bezpieczeństwa, kodowaniem treści i stanem ciasteczek.

Grupowanie pól HTTP

Poniższe etykiety tworzą ramę dydaktyczną, lecz nie są czteroczęściowym podziałem używanym przez każdą wersję HTTP. Wspólna semantyka HTTP definiuje pola przez ich znaczenie i kontekst wiadomości, a HTTP/2 i HTTP/3 dodają pola pseudo-nagłówków oraz zabraniają pól zależnych od połączenia, takich jak Connection.

Nagłówki Ogólne (General Headers): Te pola mogą występować w żądaniach i odpowiedziach oraz opisywać wiadomość albo jej przetwarzanie. Date zapisuje czas utworzenia wiadomości. Connection przenosi opcje hop-by-hop w HTTP/1.1, a HTTP/2 i HTTP/3 zabraniają tego pola.
Nagłówki Żądania (Request Headers): Te pola opisują kontekst żądania albo preferencje klienta. Przeglądarka może wysłać User-Agent, Accept-Language i Authorization. Protokół nie wymaga, aby każde pole pochodziło z przeglądarki ani występowało w każdym żądaniu.
Nagłówki Odpowiedzi (Response Headers): Te pola opisują odpowiedź albo wskazują klientowi sposób jej przetwarzania. Przykłady to Server, Location dla przekierowań i Set-Cookie do zapisania stanu ciasteczka. Ich użycie wynika z semantyki pola. Nadawca dobiera je do konkretnej odpowiedzi.
Nagłówki Reprezentacji (Representation Headers, dawniej Entity Headers): Te pola opisują reprezentację albo jej zakodowaną postać. Mogą występować w żądaniach i odpowiedziach. Przykłady to Content-Type i Content-Encoding. Content-Length wskazuje długość danych reprezentacji i może wyznaczać granicę ramkowania wiadomości w HTTP/1.1.

Pole może występować w więcej niż jednym kontekście wiadomości, gdy pozwala na to jego definicja, a rozszerzenie może wprowadzać nową nazwę pola. Nazwy pól nie zależą od wielkości liter, lecz wartości podlegają składni i regułom porównania właściwym dla danego pola. Ma to znaczenie przy łączeniu, przekazywaniu i usuwaniu pól przez pośrednika zmieniającego wersję protokołu.

Pola reprezentacji

Pola reprezentacji opisują format, długość i kodowanie treści. Odbiorca może przetworzyć reprezentację na podstawie zadeklarowanych metadanych, bez zgadywania jej formatu.

Content-Type

To pole identyfikuje typ mediów reprezentacji w treści wiadomości. Przeglądarka może na tej podstawie wybrać parser HTML, procesor arkuszy stylów, obsługę skryptu albo dekoder obrazu.

Wartością jest , po którym mogą występować parametry typu mediów.

Popularne typy MIME

text/html: Dla standardowych stron internetowych.
text/css: Dla arkuszy stylów.
text/javascript: Dla kodu JavaScript.
application/json: Dla danych w formacie JSON, popularnym w API.
image/jpeg, image/png: Dla obrazów.
multipart/form-data: Dla formularzy zawierających przesyłane pliki.

Parametry typu mediów

Parametry dodają informacje do typu mediów. Na przykład charset określa kodowanie znaków, takie jak $UTF-8$ .

Content-Type: text/html; charset=UTF-8

Content-Length

To pole podaje długość danych reprezentacji jako nieujemną dziesiętną liczbę oktetów. W HTTP/1.1 może wyznaczać granicę ciała wiadomości, gdy nie używa się kodowania transferu. Inne wersje i przypadki wiadomości mogą stosować własne reguły ramkowania, więc odbiorca nie zawsze czeka na zamknięcie połączenia.

Content-Length: 1548

Content-Encoding

To pole wymienia kodowania treści zastosowane do reprezentacji, na przykład kompresję. Odbiorca usuwa te kodowania przed przetworzeniem typu mediów wskazanego przez Content-Type. Pole opisuje kodowanie reprezentacji. Inne reguły określają ramkowanie transferu HTTP/1.1.

Popularne kodowania:

gzip: Szeroko wspierany i efektywny format kompresji.
deflate: Kodowanie treści deflate określone dla HTTP.
br: Kodowanie treści Brotli, opracowane przez Google i często wydajniejsze niż gzip.

Content-Encoding: gzip

Metadane treści odpowiadają na inne pytania niż ramkowanie transferu. Content-Type opisuje typ mediów, a Content-Encoding kodowania zastosowane do reprezentacji. HTTP/1.1 używa reguł ramkowania z polem Content-Length albo z kodowaniem transferu, a HTTP/2 i HTTP/3 przenoszą treść w ramkach protokołu. Pośrednik musi zachować zgodność długości z odebranym ramkowaniem.

Pola żądania dla kontekstu i kontroli

Pola żądania przekazują informacje o celu, preferencjach i poświadczeniach. Obsługują trasowanie, negocjację treści i uwierzytelnianie, gdy semantyka pola oraz bezpieczeństwo transportu są właściwe.

Host

W żądaniu HTTP/1.1 pole Host jest obowiązkowe. Zawiera host i opcjonalny port z docelowego URI, co umożliwia . W HTTP/2 i HTTP/3 tę informację może przenosić pseudo-pole :authority. Jeden adres serwera może obsługiwać wiele nazw domenowych, gdy serwer używa tej wartości do wyboru witryny.

Host: www.example.com

Nagłówki Accept-* i Negocjacja Treści

Negocjacja treści pozwala klientowi wymienić akceptowane reprezentacje, a serwerowi wybrać jedną reprezentację zasobu. Żądanie używa pól takich jak Accept-*.

Accept: Informuje serwer, jakie typy mediów (typy MIME) klient może zrozumieć. Na przykład, przeglądarka może wskazać, że obsługuje HTML, XML i obrazy.
Accept-Language: Informuje serwer o preferowanych językach użytkownika. Pozwala to serwerowi na odpowiedź ze stroną w języku polskim, angielskim lub niemieckim, w oparciu o ustawienia przeglądarki użytkownika.
Accept-Encoding: Informuje serwer, jakie algorytmy kompresji obsługuje klient.

Klient może dołączyć do wielu elementów listy wartość jakości od 0 do 1. Wyższa wartość oznacza silniejszą preferencję, a 0 oznacza brak akceptacji elementu. Przykład Accept-Language: pl, en-US;q=0.9, en;q=0.8 wyraża preferencję dla języka polskiego, następnie amerykańskiego angielskiego i innych odmian angielskiego.

Authorization

To pole przenosi poświadczenia dla schematu uwierzytelniania wybranego przez klienta i serwer. Dwa często spotykane schematy to:

Basic: Ten schemat wysyła nazwę użytkownika i hasło zakodowane w Base64. Base64 nie zapewnia poufności, dlatego poświadczenia wymagają HTTPS albo równoważnego bezpieczeństwa transportu.
```
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```
Bearer: Ten schemat przenosi token dostępu, często wydawany przez . Token może być nieprzezroczysty albo mieć określoną strukturę, na przykład jako JSON Web Token, a serwer zasobu sprawdza go zgodnie z regułami systemu wydającego. Token Bearer wymaga poufności transportu.
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
```

Cache-Control i walidatory

Pamięci podręczne HTTP przechowują odpowiedzi i mogą używać ich przy późniejszych równoważnych żądaniach. Pola buforowania określają świeżość, walidację i możliwość ponownego użycia odpowiedzi przez pamięć współdzieloną. Ponowne użycie ogranicza przesyłanie niezmienionych reprezentacji.

Cache-Control

Cache-Control przenosi dyrektywy żądania i odpowiedzi. Dyrektywy odpowiedzi opisują przechowywanie i ponowne użycie odpowiedzi:

public: Odpowiedź może być przechowywana przez dowolną pamięć podręczną, w tym współdzielone proxy.
private: Odpowiedź jest przeznaczona dla jednego użytkownika i nie może być przechowywana przez współdzieloną pamięć podręczną. Prywatna pamięć podręczna przeglądarki użytkownika nadal może ją przechowywać.
no-store: Pamięć podręczna nie może przechowywać odpowiedzi.
no-cache: Zapisana odpowiedź wymaga walidacji przed ponownym użyciem. Dyrektywa sama nie zabrania przechowywania.
max-age= $sekundy$ : Ustawia czas świeżości odpowiedzi w sekundach. Świeża odpowiedź może być użyta bez kontaktu z serwerem źródłowym.

# Zbuforuj ten obraz we wszystkich pamięciach podręcznych na rok
Cache-Control: public, max-age=31536000

# Zbuforuj dane specyficzne dla użytkownika w przeglądarce na godzinę
Cache-Control: private, max-age=3600

# Zawsze sprawdzaj z serwerem przed użyciem zbuforowanego HTML
Cache-Control: no-cache

ETag i If-None-Match (Walidacja)

Gdy odpowiedź staje się nieświeża, jej reprezentacja może nadal odpowiadać bieżącemu zasobowi. Walidatory HTTP pozwalają sprawdzić ten stan bez przesyłania całej reprezentacji.

Serwer dołącza pole ETag w odpowiedzi. Nazwa oznacza entity tag, a ETag jest nieprzezroczystym walidatorem wybranej reprezentacji i może być silny albo słaby.
Kiedy przeglądarka musi ponownie zweryfikować przestarzały zasób, wysyła warunkowe żądanie GET i dołącza wartość ETag w nagłówku żądania If-None-Match.
Serwer porównuje walidator z bieżącą reprezentacją. Przy zgodnym warunkowym GET zwraca 304 Not Modified bez treści reprezentacji, a pamięć podręczna może użyć zapisanej odpowiedzi po aktualizacji metadanych.

Buforowanie zależy także od kontekstu żądania. Reprezentacja wybrana w negocjacji treści może użyć Vary, aby wskazać pamięci podręcznej pola żądania wpływające na wynik. Odpowiedzi powiązane z autoryzacją albo prywatną sesją wymagają ograniczeń, które chronią przed udostępnieniem treści jednego użytkownika innemu. Semantyka pól wpływa więc na ramkowanie, reprezentację, uwierzytelnianie i ochronę danych. Pamięć podręczna musi odczytać te dyrektywy przed decyzją, czy zapisana odpowiedź może obsłużyć żądanie.