Інформаційні коди статусу 1xx

Що таке проміжна відповідь

Будь-яка інша родина статусів завершує обмін. 200, 404 чи 502 - це фінальне слово сервера щодо цього запиту. 1xx інакший: сервер надсилає рядок статусу й будь-які заголовки, тоді тримає з'єднання відкритим і пізніше надсилає другу відповідь. RFC 9110 вимагає, щоб клієнти вміли прочитати одну чи більше відповідей 1xx перед фінальною, і дозволяє будь-якому клієнту, що не розуміє конкретний код 1xx, його ігнорувати.

Проміжну відповідь відкидають, щойно приходить фінальна, тож більшість інструментів її ніколи не показують. Панель мережі вашого браузера, лог доступу вашого вебсервера і перевірка моніторингу однаково звітують про фінальний статус. Проміжна відповідь виконала свою роботу на рівні транспорту і зникла.

Коди 1xx, з якими можна зіткнутися

• 100 Continue. Клієнт надіслав заголовки запиту з Expect: 100-continue і зробив паузу перед надсиланням великого тіла. 100 означає "заголовки виглядають нормально, надсилай тіло". Якщо сервер усе одно відхилив би запит, він може відповісти фінальною помилкою замість цього, і клієнт ніколи не витрачає трафік на завантаження навантаження. Це єдиний код 1xx, що виконує корисну роботу на звичайних сайтах, зазвичай за великими завантаженнями файлів і API-клієнтами на кшталт curl.
• 101 Switching Protocols. Клієнт попросив змінити протокол через заголовок Upgrade, і сервер погодився. Це нормальний, успішний результат рукостискання WebSocket, тож 101 у лозі - це зазвичай добра ознака, а не інцидент.
• 102 Processing. Визначено специфікацією WebDAV для довготривалих запитів, щоб клієнт знав, що сервер не завис. Рідко реалізується поза WebDAV, і навряд чи ви зустрінете його на звичайному сайті.
• 103 Early Hints. Сервер надсилає заголовки Link рано, ще до того, як завершив генерувати сторінку, щоб браузер міг почати попереднє завантаження таблиць стилів, шрифтів чи скриптів, поки HTML усе ще формується. Це функція продуктивності, а не сигнал помилки, і зазвичай ви вмикаєте її навмисно на CDN чи origin.

Чому 1xx - не те, що потрібно виправляти

1xx сам по собі не несе жодної вади. Не існує такого поняття, як сторінка, що "повертає 100" чи "повертає 101", так само, як сторінка може "повертати 404". Якщо у вас проблема, а десь в обміні є 1xx, цікавою інформацією завжди лишається фінальний код статусу, що прийшов після нього, або сам факт, що фінальна відповідь взагалі не прийшла.

Справжні режими збою поблизу 1xx виявляються як зависання чи фінальна помилка, а не як сам 1xx:

• Старий проксі чи балансувальник навантаження, що не передає проміжні відповіді, тож клієнт, що чекає на 100 Continue, зависає, поки не спрацює власний тайм-аут.
• Апгрейд WebSocket, що ніколи не дістається 101, бо проксі перед застосунком видаляє заголовки Upgrade і Connection. З'єднання тоді відкочується назад чи провалюється відкрито.
• Early hints, видані з посиланнями на ресурси, яких уже не існує, що витрачає запити, не ламаючи сторінку.

Як самому побачити відповідь 1xx

1. Використайте клієнт із докладним виводом. Звичайний curl -I показує лише заголовки фінальної відповіді, тож запитайте про весь обмін:

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

   Сервер, що співпрацює, відповідає HTTP/1.1 100 Continue перед тим, як піде тіло, а тоді фінальним 2xx чи 4xx.
2. Для шляху WebSocket перевірте, що рукостискання дістається HTTP/1.1 101 Switching Protocols. Якщо ні, спершу погляньте на рівень проксі: заголовки апгрейду - hop-by-hop, і кілька поширених конфігурацій зворотного проксі відкидають їх за замовчуванням.
3. Для early hints запитайте сторінку й пошукайте блок 103 перед фінальною відповіддю. Не кожен посередник його пропускає, тож відсутній 103 не завжди означає, що origin його не надсилає.
4. Якщо велике завантаження зависає без жодної відповіді, повторіть спробу без заголовка Expect. Якщо повторна спроба вдається, щось між вами й origin проковтує проміжні відповіді.

Моніторинг обміну, якого ви не бачите

Оскільки коди 1xx ніколи не потрапляють у лог чи панель, моніторите ви фінальну відповідь і те, скільки часу знадобилося, щоб вона прийшла. Шлях завантаження, що завис на проміжній відповіді, ззовні виглядає точнісінько як повільний чи тайм-аутний ендпоінт, і зовнішня перевірка бачить це одразу. HostTracker виконує перевірки з понад 300 точок у 158 містах, тож запит, що зависає за конкретним мережевим шляхом, можна відрізнити від справжнього збою. Пропустіть URL-адресу через інструмент HTTP-перевірки, щоб побачити фінальний статус і час відповіді. Посібники коди успіху 2xx і коди перенаправлення 3xx охоплюють відповіді, що справді завершують обмін.