200 OK: що це означає і що приховує

Що гарантує 200

200 - стандартний статус успіху. Він повідомляє вузький і конкретний набір фактів: DNS розв'язався, TCP-з'єднання встановлено, TLS узгоджено, якщо URL-адреса була HTTPS, сервер прийняв рядок запиту й заголовки, і сформував відповідь, яку вважає успішною. Для GET тіло - це запитаний ресурс; для POST - результат дії.

Чого 200 не каже - це чи містить сторінка каталог товарів, чи відрендерилася форма оформлення замовлення, чи отримав JavaScript, що наповнює сторінку, свої дані, чи є отримана вами відповідь тією самою, яку отримують ваші відвідувачі в іншій країні. Усе це живе в тілі, а код статусу ніколи в тіло не заглядає.

200, що насправді є збоєм

Самого моніторингу коду статусу недостатньо, бо зламаний сайт відповідає 200 у всіх цих випадках:

• Сторінка обслуговування. Навмисно віддається з 200 скриптом деплою чи правилом CDN. Аптайм виглядає ідеальним протягом усього вікна збою.
• Перехоплений виняток застосунку. Фреймворк ловить помилку й рендерить дружню сторінку "щось пішло не так" через звичайний конвеєр шаблонів, що встановлює статус за замовчуванням 200.
• М'який 404. Повідомлення "сторінку не знайдено", повернуте з 200 замість 404. Відвідувачі спантеличені, а пошукові системи можуть тримати URL-адресу в індексі чи трактувати весь патерн як низькоякісний.
• Порожня оболонка, відрендерена на клієнті. HTML-документ завантажується нормально, але виклик API, що мав наповнити його, провалився. Статус 200, а сторінка порожня.
• Застаріла чи неправильномовна закешована копія. Edge-вузол, чиє звернення до origin провалилося, продовжує віддавати те, що вже має, із 200.
• Запаркований чи перехоплений домен. Після зміни DNS він відповідає 200 із чужим контентом.

Повільний 200 - усе одно проблема

Час відповіді часто важливіший за код. Сторінка, якій потрібно дванадцять секунд, щоб повернути 200, для більшості відвідувачів функціонально недоступна, бо вони підуть, не дочекавшись завершення. У коду статусу взагалі немає часового виміру, тож час відповіді доводиться вимірювати й обмежувати порогом окремо. Розмір також вартий уваги з тієї самої причини: 200, що повертає 300 байтів там, де зазвичай повертає 80 КБ, - сильний сигнал, що сторінка відрендерилася без свого вмісту.

Як перевірити, що 200 - справжній успіх

1. Читайте рядок статусу й таймінг разом:

   curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/

2. Отримайте тіло й перевіряйте наявність рядка, що з'являється лише коли сторінка справді працює, наприклад заголовок, ціну чи мітку у футері, а не щось, що містить і шаблон помилки.
3. Перевіряйте як відсутність, так і наявність. Пошук фраз на кшталт "on maintenance", "temporarily unavailable" чи формулювання винятку вашого фреймворка ловить випадок дружньої помилки.
4. Порівнюйте розмір відповіді з відомим справним базовим рівнем. Різке падіння довжини тіла зазвичай означає, що оболонка відрендерилась, а вміст ні.
5. Перевіряйте глибоку сторінку, а не лише головну. Головні сторінки найбільш активно кешують, і саме вони найімовірніше продовжать відповідати 200, поки застосунок за ними зламаний.
6. Повторюйте перевірку з більш ніж однієї мережі. 200 з вашого офісу й помилка з іншого континенту вказують на DNS, CDN чи географічну маршрутизацію, а не на сам застосунок.

Що може пропустити зелена перевірка аптайму

Монітор, що читає лише код статусу, звітуватиме про зелений сайт протягом усього інциденту, що почався зі сторінки обслуговування, яку ніхто не прибрав. Поєднання перевірки статусу з твердженням за ключовим словом і порогом часу відповіді - це те, що перетворює "сервер відповів" на "сторінка працювала". HostTracker пропонує 13 типів моніторів і сповіщає електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами, тож невідповідність вмісту піднімає те саме сповіщення, що й збій. Пропустіть URL-адресу через інструмент HTTP-перевірки, щоб побачити її статус, заголовки й таймінг, або читайте родину 2xx і 500 Internal Server Error про відповіді, які приховує дружня сторінка помилки.