Kody statusu informacyjne 1xx

Czym jest odpowiedź tymczasowa

Każda inna rodzina statusów kończy wymianę. 200, 404 czy 502 to ostatnie słowo serwera w sprawie danego żądania. 1xx jest inne: serwer wysyła linię statusu i ewentualne nagłówki, a potem trzyma połączenie otwarte i wysyła drugą odpowiedź później. RFC 9110 wymaga, żeby klienci potrafili odczytać jedną lub więcej odpowiedzi 1xx przed odpowiedzią końcową, i pozwala każdemu klientowi, który nie rozumie konkretnego kodu 1xx, po prostu go zignorować.

Odpowiedź tymczasowa zostaje odrzucona, gdy tylko nadejdzie ta końcowa, więc większość narzędzi jej w ogóle nie pokazuje. Panel sieci w Twojej przeglądarce, log dostępu Twojego serwera WWW i kontrola monitoringu wszystkie raportują status końcowy. Odpowiedź tymczasowa wykonała swoją pracę na poziomie transportu i zniknęła.

Kody 1xx, na które możesz się natknąć

• 100 Continue. Klient wysłał nagłówki żądania z Expect: 100-continue i wstrzymał się przed wysłaniem dużego ciała żądania. 100 oznacza "nagłówki wyglądają dobrze, wyślij ciało". Jeśli serwer i tak odrzuciłby żądanie, może zamiast tego odpowiedzieć od razu błędem końcowym, a klient nigdy nie marnuje przepustowości na przesłanie ładunku. To jedyny kod 1xx, który wykonuje użyteczną pracę na zwykłych stronach, zwykle przy dużych przesyłaniach plików i klientach API takich jak curl.
• 101 Switching Protocols. Klient poprosił o zmianę protokołu nagłówkiem Upgrade, a serwer się zgodził. To normalny, udany wynik uzgadniania WebSocket, więc 101 w logu to zwykle dobry znak, a nie incydent.
• 102 Processing. Zdefiniowany przez specyfikację WebDAV dla długo trwających żądań, żeby klient wiedział, że serwer się nie zawiesił. Rzadko implementowany poza WebDAV i mało prawdopodobne, żebyś go spotkał na zwykłej stronie WWW.
• 103 Early Hints. Serwer wysyła nagłówki Link wcześnie, zanim skończy generować stronę, żeby przeglądarka mogła zacząć wstępnie ładować arkusze stylów, czcionki czy skrypty, podczas gdy HTML jest jeszcze wytwarzany. To funkcja wydajnościowa, nie sygnał błędu, i zwykle włącza się ją celowo na CDN albo serwerze źródłowym.

Dlaczego 1xx to nie coś do naprawienia

1xx sam w sobie nie niesie żadnej winy. Nie istnieje coś takiego jak strona, która "zwraca 100" albo "zwraca 101" w taki sposób, w jaki strona może zwracać 404. Jeśli masz problem, a gdzieś w wymianie jest 1xx, interesująca informacja to zawsze kod statusu końcowego, który po nim nastąpił, albo fakt, że żadna odpowiedź końcowa w ogóle nie nadeszła.

Prawdziwe tryby awarii w pobliżu 1xx objawiają się jako zawieszenie albo błąd końcowy, a nie jako sam 1xx:

• Stary proxy albo load balancer, który nie przekazuje odpowiedzi tymczasowych, więc klient czekający na 100 Continue wisi, aż zadziała jego własny timeout.
• Uaktualnienie WebSocket, które nigdy nie dociera do 101, bo proxy przed aplikacją usuwa nagłówki Upgrade i Connection. Połączenie wtedy się cofa albo od razu zawodzi.
• Early hints wysłane z linkami do zasobów, które już nie istnieją, co marnuje żądania, nie psując samej strony.

Jak samodzielnie zobaczyć odpowiedź 1xx

1. Użyj klienta z pełnym wyjściem. Zwykłe curl -I pokazuje tylko nagłówki odpowiedzi końcowej, więc poproś zamiast tego o całą wymianę:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Współpracujący serwer odpowiada HTTP/1.1 100 Continue, zanim wyjdzie ciało żądania, a potem końcowym 2xx albo 4xx.
2. Dla ścieżki WebSocket sprawdź, czy uzgadnianie dociera do HTTP/1.1 101 Switching Protocols. Jeśli nie, spójrz najpierw na warstwę proxy: nagłówki uaktualnienia są nagłówkami między-skokowymi (hop-by-hop), a kilka popularnych konfiguracji reverse proxy domyślnie je usuwa.
3. Dla early hints zażądaj strony i poszukaj bloku 103 przed odpowiedzią końcową. Nie każdy pośrednik go przepuszcza, więc brak 103 nie zawsze oznacza, że serwer źródłowy go nie wysyła.
4. Jeśli duże przesyłanie wisi bez żadnej odpowiedzi, spróbuj ponownie bez nagłówka Expect. Jeśli ponowna próba się powiedzie, coś między Tobą a serwerem źródłowym połyka odpowiedzi tymczasowe.

Monitorowanie wymiany, której nie widzisz

Ponieważ kody 1xx nigdy nie trafiają do logu ani panelu, to, co monitorujesz, to odpowiedź końcowa i czas, jaki zajęło jej nadejście. Ścieżka przesyłania zawieszona na odpowiedzi tymczasowej wygląda z zewnątrz dokładnie jak wolny albo przekraczający limit czasu endpoint, a zewnętrzna kontrola widzi to od razu. HostTracker wykonuje kontrole z ponad 300 punktów kontrolnych w 158 miastach, więc żądanie zawieszone za jedną konkretną ścieżką sieciową da się odróżnić od prawdziwej awarii. Przepuść adres URL przez narzędzie do kontroli HTTP, żeby zobaczyć status końcowy i czas odpowiedzi. Przewodniki kody sukcesu 2xx i kody przekierowań 3xx obejmują odpowiedzi, które faktycznie kończą wymianę.