Jak działa HTTP – metody, statusy i nagłówki w pigułce

HTTP (Hypertext Transfer Protocol) to fundamentalny protokół komunikacji w Internecie, wykorzystywany do wymiany danych między klientami a serwerami w modelu klient–serwer.

Klient (np. przeglądarka lub aplikacja) inicjuje żądanie, a serwer zwraca odpowiedź. W tym artykule omawiamy trzy kluczowe komponenty HTTP: metody (rodzaj operacji), kody statusu (wynik żądania) oraz nagłówki (metadane komunikacji). Zrozumienie tych elementów jest niezbędne każdemu, kto pracuje z aplikacjami webowymi, API REST i technologiami sieciowymi.

Fundamenty protokołu HTTP i jego rola w komunikacji internetowej

HTTP to protokół warstwy aplikacyjnej oparty na modelu żądanie–odpowiedź (request–response). Protokół jest bezstanowy (stateless) – każde żądanie zawiera komplet informacji do jego obsługi, co ułatwia skalowanie i równoważenie obciążenia.

Wiadomość HTTP składa się z następujących elementów:

• linia startowa – określa metodę, ścieżkę i wersję protokołu (w żądaniach) lub wersję, kod i tekst statusu (w odpowiedziach);
• nagłówki – pary nazwa–wartość, które przekazują metadane dotyczące żądania lub odpowiedzi;
• ciało wiadomości – właściwe dane przesyłane między stronami (np. JSON, HTML, pliki).

Protokół HTTP ewoluował od HTTP/0.9 i HTTP/1.0, przez HTTP/1.1 (połączenia trwałe, transfer porcjowany), po HTTP/2 (multipleksowanie, kompresja nagłówków) i HTTP/3 (transport QUIC zamiast TCP). HTTP/3 znacząco redukuje opóźnienia i eliminuje blokowanie head‑of‑line na poziomie połączenia.

Metody HTTP – operacje na zasobach

Metody podstawowe i ich charakterystyka

Metody HTTP („czasowniki”) definiują zamiar operacji na zasobie i mają cechy takie jak: bezpieczeństwo (safe), idempotentność (idempotent) oraz możliwość cachowania (cacheable). Poprawne użycie metod to fundament dobrego projektu API.

Dla szybkiego porównania metod i ich właściwości warto skorzystać z poniższej ściągi:

Metoda GET służy do pobierania zasobów i jest bezpieczna, idempotentna oraz cacheable. Dane trafiają zwykle do adresu URL (query string) lub nagłówków; długość URL bywa ograniczona, dlatego GET nie służy do dużych ładunków.

Metoda POST tworzy zasoby i przesyła dane w ciele żądania. Nie jest bezpieczna ani idempotentna; może być cacheable wyłącznie w ściśle określonych warunkach sygnalizowanych nagłówkami.

Metody aktualizacji i usuwania

PUT wykonuje pełną aktualizację lub upsert i jest idempotentna – wielokrotne identyczne żądania dają ten sam stan. Wymaga pełnej reprezentacji zasobu; odpowiednio zwraca 200 OK (aktualizacja) lub 201 Created (utworzenie).

PATCH wprowadza częściowe zmiany. Nie jest domyślnie idempotentna (np. „increment by 1” zadziała przy każdym powtórzeniu). Popularne formaty to JSON Patch i JSON Merge Patch.

DELETE usuwa zasoby i jest idempotentna – pierwsze wywołanie zwykle zwraca 200 OK lub 204 No Content, kolejne mogą zwrócić 404 Not Found.

Dodatkowe metody i ich zastosowania

HEAD działa jak GET bez ciała odpowiedzi; jest bezpieczna, idempotentna i cacheable. Służy do sprawdzania Content-Length, Last-Modified i innych metadanych bez pobierania treści.

OPTIONS ujawnia dozwolone metody (nagłówek Allow) i obsługuje preflight CORS; jest bezpieczna i idempotentna.

TRACE zwraca otrzymane żądanie (loopback) w celach diagnostycznych; jest bezpieczna i idempotentna.

CONNECT ustanawia tunel (np. HTTPS przez proxy), istotny dla bezpieczeństwa w niezaufanych sieciach.

Kody statusu HTTP – odpowiedzi serwera

Kategorie kodów statusu

Kody statusu to trzycyfrowe wartości informujące o wyniku przetworzenia żądania. Wyróżniamy pięć grup:

• 1xx – informacyjne,
• 2xx – powodzenia,
• 3xx – przekierowania,
• 4xx – błędy klienta,
• 5xx – błędy serwera.

Kody 1xx (informacyjne) sygnalizują kontynuację przetwarzania – np. 100 Continue (kontynuuj wysyłkę ciała) czy 101 Switching Protocols (zmiana protokołu, np. WebSocket).

Kody 2xx (powodzenia) oznaczają sukces: 200 OK (zasób zwrócony), 201 Created (zasób utworzony), 202 Accepted (asynchroniczne przyjęcie), 204 No Content (brak treści), 206 Partial Content (odpowiedź zakresowa).

Kody przekierowania i błędów klienta

Kody 3xx (przekierowania): 301 Moved Permanently (trwała zmiana URL), 302 Found (czasowe przeniesienie), 303 See Other (pobierz pod innym URI metodą GET), 304 Not Modified (użyj kopii z cache).

Kody 4xx (błędy klienta): 400 Bad Request (błąd składni), 401 Unauthorized (brak uwierzytelnienia), 403 Forbidden (brak uprawnień), 404 Not Found (brak zasobu), 422 Unprocessable Content (błąd semantyczny), 429 Too Many Requests (limit żądań).

Kody błędów serwera

Kody 5xx (błędy serwera): 500 Internal Server Error (błąd ogólny), 501 Not Implemented (brak implementacji), 502 Bad Gateway (zła odpowiedź upstream), 503 Service Unavailable (przeciążenie/konserwacja), 504 Gateway Timeout (timeout upstream), 505 HTTP Version Not Supported (nieobsługiwana wersja).

Nagłówki HTTP – metadane i instrukcje komunikacji

Struktura i znaczenie nagłówków

Nagłówki to pary nazwa–wartość przekazywane w żądaniach i odpowiedziach. Nazwy nagłówków są case-insensitive, a wartości mogą być wrażliwe na wielkość liter w zależności od kontekstu. Wyróżniamy m.in. nagłówki żądania, odpowiedzi oraz reprezentacyjne (dotyczące treści). Nagłówki end-to-end przechodzą do końcowego odbiorcy, a hop-by-hop obowiązują wyłącznie na danym łączu transportowym.

Ważne nagłówki żądania

Poniżej kluczowe nagłówki żądania i ich zastosowania:

• Host – wymagana w HTTP/1.1 domena (i port) serwera docelowego; umożliwia wirtualny hosting;
• Accept – preferowane typy MIME odpowiedzi (np. application/json);
• Accept-Encoding – obsługiwane algorytmy kompresji (np. gzip, deflate, br);
• Authorization – poświadczenia (np. Bearer dla OAuth 2.0);
• Content-Type – format ciała żądania (np. application/json, application/x-www-form-urlencoded);
• Content-Length – rozmiar ciała żądania w bajtach;
• User-Agent – identyfikacja przeglądarki/urządzenia;
• Referer – adres strony odsyłającej (historycznie błędna pisownia);
• Cookie – przekazanie ciasteczek do serwera;
• Sec-Fetch-* – kontekst żądania dla oceny ryzyka (Site, Mode, User, Dest);
• Origin – pochodzenie żądania w kontekście CORS.

Ważne nagłówki odpowiedzi

Najczęściej używane nagłówki odpowiedzi to:

• Content-Type – typ MIME zwracanej zawartości;
• Content-Length – rozmiar ciała odpowiedzi;
• Content-Encoding – użyta kompresja (np. gzip, br);
• Cache-Control – reguły cachowania (max-age, no-cache, no-store, public);
• ETag – identyfikator wersji zasobu do rewalidacji;
• Last-Modified – data ostatniej modyfikacji zasobu;
• Expires – bezwzględny czas wygaśnięcia zasobu;
• Access-Control-Allow-Origin – dozwolone pochodzenia (CORS);
• Access-Control-Allow-Methods – dozwolone metody (CORS);
• Access-Control-Allow-Headers – dozwolone nagłówki (CORS);
• Set-Cookie – zapis ciasteczek po stronie klienta;
• Location – adres nowego zasobu przy 201 lub w odpowiedziach 3xx.

Struktura żądań i odpowiedzi HTTP

Anatomia żądania HTTP

Żądanie składa się z linii żądania, nagłówków, pustej linii i opcjonalnego ciała. Przykładowy format linii żądania: <metoda> <ścieżka> <wersja protokołu>, np. GET /index.html HTTP/1.1.

Po linii żądania następują nagłówki w formacie nazwa: wartość (w HTTP/1.1 obowiązkowo Host), po nich pusta linia i opcjonalne ciało (częste dla POST, PUT, PATCH).

Przykład prostego żądania GET:

GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer token123

Przykład żądania POST z ciałem JSON:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 52

{ "name": "John", "email": "[email protected]" }

Anatomia odpowiedzi HTTP

Odpowiedź zawiera linię statusu (<wersja> <kod> <tekst>, np. HTTP/1.1 200 OK), nagłówki, pustą linię i opcjonalne ciało (np. żądana treść lub opis błędu). Kody 204, 304 i wszystkie 1xx nie mają ciała odpowiedzi.

Przykład odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 60
Cache-Control: max-age=3600

{ "id": 123, "name": "John Doe", "email": "[email protected]" }

Bezpieczeństwo i dobre praktyki w HTTP

Uwierzytelnianie i autoryzacja

Uwierzytelnianie (kim jesteś?) i autoryzacja (co możesz zrobić?) to odrębne procesy. 401 Unauthorized oznacza problem z uwierzytelnieniem, a 403 Forbidden – brak uprawnień dla uwierzytelnionego klienta.

Popularne schematy: Basic (Authorization: Basic base64(username:password)) i Bearer (Authorization: Bearer token, często JWT). Stosuj wyłącznie przez HTTPS, aby chronić poświadczenia.

Bezpieczeństwo nagłówków i ochrona przed atakami

Poniższe nagłówki wzmacniają bezpieczeństwo aplikacji:

• Strict-Transport-Security (HSTS) – wymusza HTTPS i chroni przed MITM;
• X-Frame-Options – blokuje osadzanie w iframe (ochrona przed clickjackingiem);
• X-Content-Type-Options: nosniff – wyłącza MIME sniffing;
• Content-Security-Policy (CSP) – kontroluje dozwolone źródła zasobów (np. default-src 'self', script-src 'self' https://trusted-cdn.com).

Nagłówki Access-Control-* (CORS) definiują, które pochodzenia, metody i nagłówki mają dostęp do zasobów przeglądarkowych.

Cachowanie i optymalizacja wydajności

Cache-Control steruje pamięcią podręczną: max-age (czas świeżości), no-cache (wymagana rewalidacja), no-store (zakaz przechowywania), public (dopuszczone cache współdzielone). Warunkowe żądania z ETag i Last-Modified ograniczają transfer (np. If-None-Match -> 304 Not Modified).

Kompresja treści jest negocjowana przez Accept-Encoding i Content-Encoding (np. gzip, br), co zmniejsza rozmiar odpowiedzi.

Zaawansowane funkcje komunikacji HTTP

Żądania wstępne (preflight) i CORS

CORS umożliwia bezpieczny dostęp cross-origin. Dla „nieprostych” żądań przeglądarka wysyła preflight OPTIONS z nagłówkami Access-Control-Request-Method i Access-Control-Request-Headers. Serwer odpowiada m.in. Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers oraz Access-Control-Max-Age (czas cache’owania odpowiedzi preflight).

Żądania zakresowe (range requests) i pobieranie częściowe

Żądania zakresowe pozwalają pobrać fragment zasobu: Range: bytes=start-end. Serwer, jeśli wspiera zakresy (Accept-Ranges: bytes), zwraca 206 Partial Content z Content-Range oraz właściwym Content-Length. To umożliwia wznawianie pobrań i efektywne strumieniowanie dużych plików.

Keep-alive i połączenia trwałe

W HTTP/1.1 połączenia trwałe są domyślne; zmniejszają narzut wielokrotnego TCP handshake. W HTTP/1.0 używano Connection: keep-alive i (opcjonalnie) Keep-Alive z parametrami timeout oraz max. W HTTP/2 nagłówki te są zabronione, bo multipleksowanie zastępuje ich funkcję.

Porównanie wersji protokołu HTTP

Poniższa tabela zestawia kluczowe różnice między HTTP/1.1, HTTP/2 i HTTP/3: