Content-Type

Jest to być może najważniejszy nagłówek reprezentacji. Informuje on odbiorcę o typie medium zasobu w ciele wiadomości. Ta informacja jest kluczowa dla klienta, aby mógł poprawnie przetworzyć treść. Na przykład, przeglądarka musi wiedzieć, czy otrzymuje dokument HTML do wyrenderowania, plik CSS do zastosowania stylów, plik JavaScript do wykonania, czy plik graficzny do wyświetlenia.

Wartością tego nagłówka jest typ MIME, po którym często następują dodatkowe dyrektywy.

Popularne typy MIME:

• text/html: Dla standardowych stron internetowych.
• text/css: Dla arkuszy stylów.
• application/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.

Dyrektywy:

Dyrektywy to dodatkowe parametry. Najczęstszą jest charset, która określa użyte kodowanie znaków (np. $UTF-8$).

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

Content-Length

Ten nagłówek wskazuje rozmiar ciała wiadomości w bajtach (jako liczba dziesiętna). Jest to prosta, ale niezbędna informacja. Odbiorca używa tej wartości, aby wiedzieć, ile dokładnie danych odczytać z połączenia sieciowego, aby otrzymać kompletne ciało wiadomości. Bez tego odbiorca musiałby czekać, aż serwer zamknie połączenie, aby wiedzieć, że wiadomość jest kompletna, co jest nieefektywne.

Content-Length: 1548

Content-Encoding

Ten nagłówek określa algorytm kompresji, który został zastosowany do ciała wiadomości. Aby zaoszczędzić pasmo i skrócić czas ładowania, serwery często kompresują dane przed ich wysłaniem. Przeglądarka, widząc ten nagłówek, wie, że musi zdekompresować ciało, zanim będzie mogła go użyć.

Popularne kodowania:

• gzip: Szeroko wspierany i efektywny format kompresji.
• deflate: Inny powszechny algorytm kompresji.
• br: Brotli, nowszy algorytm opracowany przez Google, często oferujący lepszą kompresję niż gzip.

Content-Encoding: gzip

Host

Nagłówek Host jest obowiązkowy we wszystkich żądaniach HTTP/1.1. Określa nazwę domenową serwera, z którym klient próbuje się połączyć, oraz opcjonalnie numer portu. Ten nagłówek jest tym, co umożliwia działanie hostingu wirtualnego. Jeden serwer z jednym adresem IP może hostować setki różnych stron internetowych. Kiedy żądanie dociera do serwera, używa on nagłówka Host, aby określić, do której strony internetowej żądanie jest skierowane, i serwuje odpowiednią treść.

Host: www.example.com

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

Potężną cechą HTTP jest negocjacja treści. Pozwala to klientowi określić swoje preferencje co do typu treści, którą może obsłużyć, a serwer może wtedy wybrać najodpowiedniejszą reprezentację zasobu do odesłania. Odbywa się to głównie za pomocą zestawu nagłówków 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.

Klienci mogą również określać swoje preferencje za pomocą wartości jakości (q-factor), liczby od 0 do 1. Wyższa liczba oznacza wyższą preferencję. Na przykład, Accept-Language: pl, en-US;q=0.9, en;q=0.8 oznacza, że klient preferuje język polski, następnie amerykański angielski, a na końcu dowolny angielski.

Authorization

Ten nagłówek jest standardowym sposobem na dostarczanie poświadczeń w celu uwierzytelnienia klienta na serwerze. Istnieje kilka schematów uwierzytelniania. Dwa najczęstsze to:

• Basic: Ten schemat wysyła nazwę użytkownika i hasło zakodowane w Base64. Nie jest bezpieczny, ponieważ Base64 jest łatwo odkodowywalne, a poświadczenia są przesyłane otwartym tekstem. Powinien być używany wyłącznie przez połączenie HTTPS.

  Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

• Bearer: Jest to schemat używany w nowoczesnych aplikacjach internetowych, w szczególności z frameworkami takimi jak OAuth 2.0. Klient wysyła kryptograficzny token (jak JSON Web Token lub JWT), który serwer może zweryfikować, aby udzielić dostępu. Sam token jest uzyskiwany w oddzielnym procesie logowania.

  Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Cache-Control

Jest to najważniejszy i nowoczesny nagłówek odpowiedzi służący do określania polityk buforowania. Jest to nagłówek ogólny, ale najpotężniejszy w odpowiedziach. Może zawierać różne dyrektywy:

• 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: Odpowiedź nie może być nigdzie buforowana. Jest to przeznaczone dla bardzo poufnych danych.
• no-cache: Ta dyrektywa jest często źle rozumiana. nie oznacza ona „nie buforuj”. Oznacza, że pamięć podręczna musi ponownie zweryfikować z serwerem źródłowym przed użyciem zbuforowanej kopii. Zmusza to pamięć podręczną do sprawdzenia, czy zasób się zmienił, używając nagłówków walidacyjnych, takich jak ETag.
• max-age=$sekundy$: Określa maksymalny czas w sekundach, przez który zasób jest uważany za świeży. Przez ten czas przeglądarka może używać zbuforowanej kopii bez kontaktowania się z serwerem.

# 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 max-age wygaśnie, zbuforowana treść jest uważana za przestarzałą. Jednak zasób na serwerze mógł się faktycznie nie zmienić. Aby uniknąć ponownego pobierania całego pliku, HTTP dostarcza mechanizm walidacji.

1. Serwer dołącza nagłówek ETag (Entity Tag) w swojej pierwotnej odpowiedzi. ETag to unikalny identyfikator lub skrót dla określonej wersji zasobu.
2. 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.
3. Serwer porównuje ETag klienta z bieżącą wersją zasobu. Jeśli są takie same, zasób się nie zmienił. Serwer odpowiada specjalnym statusem 304 Not Modified i pustym ciałem. Przeglądarka wie wtedy, że może bezpiecznie użyć swojej zbuforowanej kopii na kolejny okres. Oszczędza to znaczną ilość pasma.