Про три символи, на які може послати сервер

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Ви стикаєтесь із ними щодня, щохвилини, явно чи неявно. Тисячі коротких тризначних кодів повертаються до ваших пристроїв у відповідь на бажання почитати новини, подивитися фільм чи написати змістовну й вагому думку під час урівноваженої, цивілізованої дискусії. Що ж це за загадкові числові комбінації і яку роль вони відіграють у житті сучасного інтернету? Пропоную докопатися до істини разом.

***

...того року Італія здобуває світову першість, здолавши збірну Західної Німеччини з рахунком 3:1, Майкл Джексон випускає найбільш продаваний музичний альбом усіх часів Thriller, у продажі з’являються CD-диски, а в космос відправляється Space Shuttle Columbia. Це — 1982-й. І саме цього року виходить RFC 821, у якому визначається специфікація протоколу передачі електронної пошти мережею «Інтернет». До чого тут це, спитаєте ви? Все просто: саме в цій специфікації вперше з’являються ті самі тризначні коди, принцип яких пізніше запозичить той самий Тім Бернерс-Лі, всебатько сучасного інтернету.

Користувач ПК читає пошту. Чи електронну — до кінця не зрозуміло

Самі коди трохи відрізнялися від звичних нам HTTP-статусів, однак дещо лишилося незмінних з тих давніх часів. Наприклад, уже тоді група кодів 2xx означала успішне виконання команди, а різні статуси групувалися за першою цифрою коду. Згодом цей принцип перекочував і до протоколу передавання файлів FTP. До речі, цікавий факт: група 1xx з’явилася саме в специфікації FTP, а от у SMTP її просто не було.

Як не було цієї групи статусів і в протоколу HTTP аж до версії HTTP/1.1. Ба більше, у найпершої версії, HTTP/0.9, статусів не було зовсім! Це був суворий час, коли HTTP мав лише один GET-метод, а якщо ресурс, який ви запитували в сервера, не існував, то ви попросту не отримували ніякої відповіді.

І лише з версією HTTP/1.1 список статусів нарешті набув звичного нам стану з п’ятьма групами:

• Інформаційні повідомлення 1xx: вказують на те, що запит отримано й обробка продовжується.
• Успішні відповіді 2xx: повідомляють про успішне виконання запиту.
• Повідомлення про перенаправлення 3xx: сигналізують, що клієнт має виконати додаткові дії для завершення запиту.
• Помилки клієнта 4xx: кажуть про проблеми з боку клієнта, що заважають виконати запит.
• Помилки сервера 5xx: вказують на те, що сервер не зміг виконати запит через внутрішню помилку.

Аби зрозуміти, що ж означають ці групи повідомлень, можна уявити собі ситуацію, коли ви питаєте в перехожого про шлях до бібліотеки. Ви виступаєте в ролі клієнта, наприклад браузера, а перехожий — у ролі сервера. Отже, якщо у відповідь на ваше запитання його адресат робить задумливе лице, чухає потилицю і бурмоче: «Зара, зара, секунду», то це буде відповідь з першої групи 1xx.

Якщо ж ви відразу чуєте у відповідь чіткий та детальний маршрут, як пройти до бібліотеки, а перехожий іде у своїх справах, то це однозначно відповідь з другої групи 2xx.

У разі, якщо на ваше запитання ви отримуєте щось на кшталт «біжи три дні за оленем, скачи два дні за зайцем, повзи один день за змією, тоді дістанешся річки, а на березі цієї річки сидітиме старий та мудрий дід — от йому мізки й грай!», то, швидше за все, вас було перенаправлено за допомогою відповіді з третьої групи 3xx.

Коли ж ваш сервер із криком «Сишиш, ти, бль...!» просто бʼє вас у лице, а потім по нирках, імовірно, ви звернулися не до того перехожого й не тими словами. Тобто це помилка клієнта з четвертої групи статусів 4xx. І повторювати той самий запит, певно, не варто.

Помилка клієнта. Можливо, фатальна

А якщо у відповідь на ваше питання перехожий, довірливо дивлячись вам в очі, мовчки обригався, то тут усе просто — це 5xx.

Тож для чого саме призначені ці коди статусів, та який у них сенс?

Якщо дуже коротко, то це засіб сервера в стислий та зрозумілий спосіб сповістити клієнта про результат обробки його запиту. А якщо розгорнутіше, то можна сприймати ці статус-коди як своєрідну мову, якою сервер пояснює, що з ним відбувається, надаючи клієнту додаткові можливості зрозуміти, що й де так або не так.

Наприклад, якщо сервер на певний запит відповість 404, то ми знатимемо як мінімум дві речі: цей ресурс потенційно відкритий і за цим посиланням інформації, що нас цікавить, не існує. В прикладі з бібліотекою це звучатиме як «нема у нас бібліотеки». А якщо ж відповідь буде 401, то це означатиме, що перехожий вас не знає і відповідати через це не бажає. Людською мовою це виглядало б так: «Ваші документи, а потім будете питать». Якщо ж і після того, як ви покажете вашу «Дію», він скаже, що «де бібліотека, вам знать не положено», то це однозначно статус 403.

І результат ніби один і той самий: ви не дізналися, де та довбана бібліотека, але ж ви опиняєтеся у різних ситуаціях, на які можна по-різному реагувати. І треба по-різному реагувати, себто обробляти такі відповіді по-різному, і залежно від того відповідно діяти. Наприклад, показати сповіщення, що даних не існує, або відправити на сторінку логіну тощо.

Взагалі, правильна обробка статус-кодів є дуже важливою у веброзробці: вона дозволяє як покращити зручність ваших сайтів для користувачів, так і більш акуратно й точно реагувати на різноманітні сценарії. А якщо обробляти усі помилки через плашку «Ooops, something went wrong!», то ви встрелитесь шукати, що саме пішло не так під час розробки й налагодження, а ваші користувачі з великою ймовірністю скажуть: «Ooops, you did it again» — і стрімко поскачуть у напрямку конкурента.

Окремо хочеться накликати усі біблійні напасті на голови тих, хто відповідає на всі можливі події простим, старим добрим 200, навіть якщо в цей час насправді у них попадали усі бекапи, а на сервер наклав Ґодзілла. А фактичну відповідь кладуть десь у пʼятнадцятий рівень вкладеності обʼєкта-відповіді. Знаєте, що мені це нагадує? Ніби коли зраночку світить сонечко, співають пташки, ви виходите на кухню, а там уже сидить ваш партнер — і ви відчуваєте, що щось не так. Й у відповідь на запитання «Шось сталось?» — фраза, від якої холоне в жилах: «ВСЕ НОРМАЛЬНО». А ви ж розумієте, що нічого там не нормально, але реальну причину такої відповіді сервер вам не каже, бо у нього «все нормально». І от як ми маємо таке обробляти на клієнті, га?! Тому робіть, будь ласочка, нормальні відповіді за специфікацією. Communication is a key.

А це ще клієнт навіть у сервера нічого й не питав!

Специфікація HTTP постійно розвивається, доповнюється, і, як не дивно, часом позбувається неактуальних кодів чи змінює значення наявних. Наприклад, код 305 Use Proxy було вилучено через проблеми безпеки та потенційні загрози, пов’язані з неправильним використанням проксі-серверів. А код 306 узагалі ніколи не був визначеним, не те що використовуваним, тож його теж позбулися без жалю. Така ж доля, підозрюю, чекає й на код 402 Payment Required, який досі залишається «зарезервованим для майбутнього використання». Його призначення — вказувати на те, що для доступу до ресурсу потрібна оплата, але стандартних протоколів його використання не розробили.

До речі, поширеною думкою є те, що жартівливий код 418 I’m a Teapot є частиною специфікації HTTP. Мушу вас розчарувати: він — частина стандарту Hyper Text Coffee Pot Control Protocol (HTCPCP), хоча часто вказаний у переліках кодів до HTTP. Так от, цей код зʼявився в жартівливому RFC 2324, опублікованому 1 квітня 1998 року. Він описує HTCPCP, який є пародією на інші інтернет-протоколи, й призначений для управління кавоварками через інтернет.

А от код 451 Unavailable for Legal Reasons дійсно є частиною специфікації HTTP з грудня 2015 року. Хто відразу не упізнав, то це пряме відсилання до роману неперевершеного Рея Бредбері «451 градус за Фаренгейтом» — про суспільство, де книги заборонені та підлягають спаленню. Відповідно, код 451 символізує цензуру або правові обмеження на доступ до інформації.

Які ж висновки можна зробити з цього нашого невеличкого екскурсу?

По-перше, знати й розуміти статус-коди важливо всім без винятку фахівцям, що залучені до веброзробки. Бекенд-інженерам — для забезпечення прозорого, чіткого й усім зрозумілого оповіщення програмних клієнтів про стан своїх справ. Фронтенд-розробникам — для правильної обробки цих повідомлень та побудови зручних, інтуїтивних та надійних інтерфейсів, які не падають він найменшого подиху вітру. Та, звичайно ж, тестувальникам — для розуміння, що саме й де вломилося.

А по-друге, варто памʼятати, що протокол HTTP, як і будь-яка інша специфікація, перебуває в процесі постійного розвитку. Отож із часом можуть з’являтися нові статусні коди, що відображатимуть нові вимоги й технологічні виклики. І нам, як розробникам, важливо залишатися в курсі змін й розуміти, як ці зміни можуть впливати на роботу наших вебзастосунків та процес взаємодії користувачів з нашими продуктами.

Дякую за увагу, з вами був Сергій Бабіч та Дивовижний світ веброзробки, і якщо вам сподобалась ця стаття, прошу підписатися на мій ютуб канал, а також обовʼязково залишити тут коментар. Можна навіть образливий, або такий, де ви кажете, що це все мають знати діти уже в дитсадку, і взагалі, ще би про <div> написав.

...а я й пишу...