HTTP-заголовки, які повинен знати кожен веброзробник

Що таке HTTP-заголовки і навіщо вони потрібні

Якщо ви коли-небудь відкривали DevTools → Network, то напевно бачили там десятки різних рядків на кшталт Content-Type, Cache-Control, User-Agent, Cookie та інших. На перший погляд це може виглядати як якась технічна інформація, яка потрібна лише серверу.

Насправді з HTTP-заголовками веброзробник стикається постійно. Просто більшість часу ми їх навіть не помічаємо.

Коли ви відкриваєте сторінку сайту, браузер відправляє запит на сервер. Сервер обробляє його та повертає відповідь. Разом із самим запитом або відповіддю передається додаткова інформація — саме це і є HTTP-заголовки (HTTP headers).

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

Простий приклад

Сервер може повернути браузеру таку відповідь:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600

Тут нас цікавлять останні два рядки.

Content-Type повідомляє браузеру, що сервер повернув HTML-документ. А Cache-Control визначає, як браузеру працювати з кешем цього документа.

Тобто сервер не просто каже: «Ось тобі сторінка». Він також передає додаткові інструкції щодо того, як цю сторінку потрібно обробити.

Заголовки бувають у запитах і відповідях

Важливий момент, який спочатку легко пропустити: HTTP-заголовки використовуються в обидві сторони.

Браузер додає заголовки до свого запиту:

GET /products HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

А сервер додає свої заголовки до відповіді:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 18452

Як це працює?

На практиці це може бути набагато складніше. Разом із завантаженням однієї сторінки браузер робить десятки, а іноді й сотні запитів до сервера — за CSS-файлами, JavaScript, зображеннями, шрифтами, API тощо. І кожен із цих запитів має свої заголовки.

Саме тому HTTP-заголовки важливо хоча б на базовому рівні розуміти.

Для чого вони потрібні?

За допомогою заголовків вирішується дуже багато різних завдань. Наприклад:

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

Тому, коли на сайті щось працює не так, як очікується, іноді проблема знаходиться зовсім не в HTML, CSS або JavaScript. Варто відкрити Network → Headers і подивитися, що саме відправляє браузер та що повертає сервер.

Якщо ви займаєтеся веброзробкою, не варто сприймати HTTP-заголовки як щось суто «серверне». Навіть якщо ви переважно працюєте з HTML, CSS та JavaScript, рано чи пізно вони знадобляться для пошуку помилок, оптимізації швидкості або налаштування безпеки сайту.

Далі розглянемо найпоширеніші HTTP-заголовки на простих прикладах і подивимося, де саме вони використовуються на реальних сайтах.

Основні HTTP-заголовки, які варто знати

Коли вперше відкриваєш список HTTP-заголовків у DevTools, їх кількість може трохи здивувати. Але знати всі заголовки напам'ять зовсім не потрібно. Є кілька, з якими веброзробник стикається найчастіше під час роботи із сайтами, кешуванням, авторизацією та API.

Нижче розберемо заголовки, які найчастіше можна побачити у вкладці Network.

Content-Type — тип даних

Заголовок Content-Type повідомляє браузеру, який тип даних повернув сервер.

Наприклад, для HTML-сторінки сервер може відправити:

Content-Type: text/html; charset=UTF-8

Браузер бачить цей заголовок і розуміє, що отримані дані потрібно обробити як HTML-документ. Для інших ресурсів значення буде відповідним:

Content-Type: text/css
Content-Type: application/javascript
Content-Type: application/json
Content-Type: image/webp

Цей заголовок зустрічається не лише під час завантаження звичайних сторінок. Наприклад, API часто повертає дані у форматі JSON:

Content-Type: application/json

Якщо сервер віддає ресурс із неправильним типом, браузер може обробити його не так, як очікується. Тому під час пошуку проблем із CSS, JavaScript, API або файлами перевірка Content-Type може багато чого пояснити.

Cache-Control — керування кешуванням

Заголовок Cache-Control визначає правила кешування отриманого ресурсу.

Наприклад:

Cache-Control: max-age=3600

У цьому випадку браузер може використовувати збережену копію ресурсу протягом 3600 секунд, тобто однієї години, не завантажуючи його повторно з сервера.

Також можна зустріти:

Cache-Control: no-cache
Cache-Control: no-store

Ці два значення часто плутають. no-cache не забороняє браузеру зберігати ресурс. Перед використанням збереженої копії браузер повинен перевірити, чи залишається вона актуальною.

no-store має інше призначення — відповідь не повинна зберігатися в кеші.

На практиці Cache-Control часто використовується для CSS, JavaScript, зображень, шрифтів та інших статичних файлів. Коли браузеру не потрібно повторно завантажувати один і той самий ресурс із сервера, сторінка відкривається швидше, а кількість запитів зменшується.

Location — перенаправлення на іншу адресу

Заголовок Location використовується, коли сервер повідомляє клієнту адресу, на яку потрібно перейти.

Наприклад, під час постійного перенаправлення сервер може повернути:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

Браузер отримує відповідь 301, бачить нову адресу в Location і переходить на неї.

Location зустрічається не лише з відповіддю 301. Він використовується і з іншими HTTP-відповідями, які передбачають перенаправлення.

Set-Cookie та Cookie — робота з cookies

Якщо сайт використовує cookies, у HTTP-запитах та відповідях можна побачити два пов'язані заголовки — Set-Cookie і Cookie.

Спочатку сервер може відправити браузеру:

Set-Cookie: session=abc123

Браузер зберігає отриману cookie. Під час наступного запиту до цього сайту вона може бути передана назад:

Cookie: session=abc123

Відмінність між цими заголовками можна побачити в таблиці:

Cookies використовуються для збереження налаштувань, роботи сесій, авторизації та інших функцій сайту. У реальному запиті значення cookie зазвичай набагато довше, ніж у наведеному прикладі.

User-Agent — інформація про клієнт

Під час HTTP-запиту браузер може передавати серверу інформацію про себе за допомогою заголовка User-Agent.

User-Agent: Mozilla/5.0 ...

Рядок User-Agent може містити інформацію про браузер, операційну систему та інші характеристики клієнта.

Сервер може використовувати ці дані, наприклад, для визначення особливостей клієнта або формування відповіді. Однак значення User-Agent можна змінити, тому покладатися на нього як на достовірне джерело інформації не варто.

Referer — джерело переходу

Заголовок Referer може містити адресу сторінки, з якої був зроблений перехід або запит.

Наприклад:

Referer: https://example.com/catalog

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

Ця інформація може використовуватися для аналітики, визначення джерела переходу або реалізації певної логіки на сайті.

Referer присутній не в кожному запиті. Браузер може не передавати його залежно від налаштувань політики передачі реферера.

Authorization — авторизація запиту

Заголовок Authorization використовується для передачі даних, за допомогою яких сервер перевіряє права доступу до певного ресурсу.

Один із поширених варіантів виглядає так:

Authorization: Bearer eyJhbGciOi...

Такий формат часто зустрічається під час роботи з API. Сервер отримує токен, перевіряє його та визначає, чи дозволено виконувати запит.

Конкретний спосіб авторизації залежить від API та використовуваної системи. Тому заголовок Authorization не обов'язково містить саме Bearer — існують й інші схеми авторизації.

Коротка шпаргалка

У підсумку розглянуті заголовки можна звести до однієї таблиці:

Це лише частина HTTP-заголовків, які можна зустріти під час роботи сайту. Окрему групу становлять заголовки, пов'язані з безпекою. Вони вже стосуються не стільки передачі даних, скільки правил, за якими браузер повинен взаємодіяти із сайтом.

HTTP-заголовки для безпеки сайту

HTTP-заголовки використовуються не лише для передачі інформації про ресурси, кешування або авторизацію. За їх допомогою сервер може передавати браузеру додаткові правила, які стосуються безпеки сайту.

Є кілька заголовків, які часто зустрічаються в налаштуваннях сучасних сайтів. Розглянемо чотири з них.

Strict-Transport-Security — примусовий HTTPS

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

Для цього використовується заголовок Strict-Transport-Security, який також називають HSTS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Значення max-age задає період, протягом якого браузер повинен запам'ятати це правило. У прикладі вище це 31536000 секунд, тобто один рік.

Параметр includeSubDomains поширює правило також на піддомени.

Після того як браузер отримав цей заголовок, ситуація може виглядати так: користувач вводить в адресному рядку:

http://example.com

А браузер самостійно переходить на:

https://example.com

При цьому браузеру не потрібно спочатку звертатися до HTTP-версії сайту, щоб отримати перенаправлення від сервера.

З HSTS краще не поспішати. Якщо ввімкнути його з великим значенням max-age, а потім виявиться, що якийсь піддомен або частина сайту не підтримує HTTPS, браузер продовжить вимагати захищене з'єднання протягом усього зазначеного періоду.

Content-Security-Policy — контроль джерел ресурсів

Content-Security-Policy, або CSP, дозволяє визначити, з яких джерел браузер може завантажувати різні ресурси сторінки.

Наприклад:

Content-Security-Policy: default-src 'self'

У такому варіанті за замовчуванням дозволяється завантаження ресурсів лише з поточного джерела.

Правило можна розширити для окремих типів ресурсів. Наприклад:

Content-Security-Policy: default-src 'self'; img-src 'self' https://images.example.com

Тут зображення дозволено завантажувати як із власного сайту, так і з images.example.com. Для інших типів ресурсів продовжує діяти правило default-src 'self'.

CSP може допомогти зменшити ризик XSS-атак та інших проблем, пов'язаних із виконанням стороннього коду. Водночас налаштування цієї політики потребує уваги: занадто суворе правило може заблокувати потрібні JavaScript-файли, стилі, шрифти, зображення або підключення до API.

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

X-Content-Type-Options — захист від MIME-sniffing

Цей заголовок має лише одне поширене значення:

X-Content-Type-Options: nosniff

Параметр nosniff повідомляє браузеру не намагатися самостійно визначати тип ресурсу, якщо сервер уже передав його через Content-Type.

Наприклад, сервер повинен коректно повідомити браузеру, що перед ним JavaScript:

Content-Type: application/javascript

А не розраховувати на те, що браузер сам здогадається про тип файлу.

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

X-Frame-Options — захист від завантаження сторінки в iframe

Заголовок X-Frame-Options визначає, чи може сторінка бути завантажена всередині <iframe>.

Наприклад:

X-Frame-Options: DENY

означає, що сторінку не можна завантажувати всередині iframe.

Інший варіант:

X-Frame-Options: SAMEORIGIN

дозволяє використовувати сторінку всередині iframe лише на сторінках того самого джерела.

Цей механізм може використовуватися для захисту від clickjacking. Суть такої атаки полягає в тому, що зловмисник намагається розмістити чужу сторінку або окремий елемент поверх власного інтерфейсу, щоб користувач випадково натиснув на приховану кнопку чи посилання.

Чотири заголовки в одній таблиці

Якщо звести все сказане вище до однієї таблиці, отримаємо таку картину:

Ці заголовки зазвичай не прописують безпосередньо в HTML-коді сторінки. Найчастіше вони додаються на рівні вебсервера, reverse proxy або самої CMS. Конкретний спосіб залежить від того, як побудована інфраструктура сайту.

У браузері всі ці налаштування можна побачити у відповіді сервера, відкривши DevTools → Network → Headers. Це зручний спосіб перевірити, які правила безпеки реально отримує браузер, а не лише те, що, як нам здається, налаштовано на сервері.

CORS: чому браузер блокує запити

З CORS веброзробник зазвичай стикається тоді, коли JavaScript повинен отримати дані з іншого домену. Сам запит може виглядати цілком правильно, сервер може навіть повернути відповідь, але браузер все одно не дозволить JavaScript отримати ці дані.

Наприклад, сторінка знаходиться за адресою:

https://example.com

А JavaScript звертається до API:

https://api.example.net/products

Оскільки це різні джерела, браузер застосовує правила CORS — Cross-Origin Resource Sharing.

Origin — звідки прийшов запит

Під час cross-origin-запиту браузер додає до HTTP-запиту заголовок Origin:

Origin: https://example.com

Він повідомляє серверу, з якого саме origin виконується запит.

Origin складається з трьох основних частин:

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

Наприклад, ці адреси мають різні origins:

https://example.com
http://example.com
https://www.example.com
https://api.example.com:8080

Access-Control-Allow-Origin — дозвіл від сервера

Після отримання запиту сервер може повідомити браузеру, чи дозволяє він доступ до відповіді з конкретного origin.

Для цього використовується заголовок Access-Control-Allow-Origin:

Access-Control-Allow-Origin: https://example.com

У цьому випадку сервер дозволяє браузеру використовувати відповідь для сторінки, яка працює з https://example.com.

Також можна зустріти:

Access-Control-Allow-Origin: *

Символ * означає, що доступ до відповіді дозволений для будь-якого origin. Такий варіант часто використовують для публічних API, але він підходить не для кожної ситуації.

Звідки береться помилка CORS?

Уявімо, що на сторінці виконується такий JavaScript:

fetch('https://api.example.net/products')
  .then(response => response.json())
  .then(data => console.log(data));

Якщо API не дозволяє запити з https://example.com, браузер може показати в Console повідомлення на кшталт:

Access to fetch at 'https://api.example.net/products'
from origin 'https://example.com' has been blocked
by CORS policy

Тут часто виникає помилкове враження, що проблема знаходиться у JavaScript. Насправді код fetch() може бути написаний правильно. Браузер отримав відповідь від сервера, але не дозволив JavaScript отримати до неї доступ, оскільки сервер не передав потрібний CORS-заголовок.

З CORS я найчастіше стикаюся саме тоді, коли AJAX або fetch()-запит виглядає правильним, сервер відповідає, але браузер все одно показує помилку в Console. У такій ситуації я спочатку дивлюся Network і перевіряю заголовки запиту та відповіді.

Preflight-запит і метод OPTIONS

У деяких випадках браузер перед основним запитом спочатку відправляє додатковий запит — preflight. Для нього використовується HTTP-метод OPTIONS.

Наприклад, браузер може відправити:

OPTIONS /products HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST

Таким запитом браузер фактично перевіряє, чи дозволяє сервер виконати майбутній cross-origin-запит.

Сервер може відповісти:

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST

Після такої відповіді браузер може виконати основний запит POST.

Якщо сервер не дасть необхідного дозволу, основний запит може не відбутися або браузер не дозволить JavaScript отримати його результат.

Основні CORS-заголовки

Під час діагностики CORS найчастіше доводиться мати справу з такими заголовками:

Якщо в Console з'явилася помилка CORS, не обов'язково одразу шукати проблему в JavaScript. Відкрийте DevTools → Network, знайдіть потрібний запит і перегляньте Request Headers та Response Headers. За значеннями Origin і Access-Control-Allow-Origin часто можна швидко зрозуміти, чому браузер заблокував відповідь.

Як перевіряти HTTP-заголовки в DevTools

Тепер, коли ми розібрали основні HTTP-заголовки, можна подивитися, де саме їх шукати під час роботи із сайтом. Для цього не потрібні додаткові розширення або спеціальні програми. Достатньо відкрити інструменти розробника браузера.

Де шукати заголовки?

У Google Chrome (або в іншому браузері) відкрийте DevTools → Network і перезавантажте сторінку. У списку з'являться запити до HTML-документа, CSS-файлів, JavaScript, зображень, шрифтів та інших ресурсів.

Перегляд HTTP-заголовків сторінки в DevTools

Якщо натиснути на будь-який запит, праворуч відкриється інформація про нього. Нас цікавить вкладка Headers.

У ній можна побачити заголовки як самого запиту, так і відповіді сервера.

Request Headers

У секції Request Headers знаходяться заголовки, які браузер відправив серверу.

Наприклад:

GET /products HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Cookie: session=abc123

Тут можна побачити адресу запитаного ресурсу, інформацію про браузер, типи даних, які він готовий прийняти, cookies та багато іншого.

Залежно від конкретного запиту набір заголовків буде відрізнятися. Наприклад, запит JavaScript до API матиме інший набір параметрів, ніж запит на завантаження зображення.

Response Headers

У секції Response Headers знаходяться заголовки, які сервер повернув браузеру разом із відповіддю.

Наприклад:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600
Content-Encoding: gzip

Саме тут можна перевірити, який тип даних повернув сервер, чи використовується кешування, чи ввімкнене стиснення та які правила безпеки передаються браузеру.

Що перевіряти в першу чергу?

Коли потрібно розібратися з проблемою, немає сенсу переглядати всі заголовки підряд. Зазвичай достатньо знайти той, який стосується конкретної ситуації.

Приклад: CSS-файл завантажується неправильно

Уявімо ситуацію: CSS-файл підключений до сторінки, запит до нього проходить, але браузер повідомляє про проблему.

Відкриваємо Network, знаходимо потрібний CSS-файл і дивимося його заголовки.

Замість очікуваного:

Content-Type: text/css

сервер повертає:

Content-Type: text/html

Тут уже є зачіпка для пошуку причини. Сервер повідомляє браузеру, що замість CSS він отримав HTML.

Причина може бути, наприклад, у неправильному шляху до файлу, перенаправленні або налаштуванні сервера. Але шукати проблему в самому CSS у такій ситуації немає сенсу — спочатку потрібно з'ясувати, чому сервер повертає не той ресурс.

Приклад: помилка CORS

Інша поширена ситуація виникає під час роботи з API.

У запиті можна побачити:

Origin: https://example.com

А у відповіді сервера відсутній необхідний заголовок:

Access-Control-Allow-Origin: https://example.com

Саме після такої перевірки стає зрозуміло, чому браузер не дозволяє JavaScript отримати відповідь від API.

Тому повідомлення про CORS у Console краще не сприймати як проблему, яку потрібно виправляти виключно в JavaScript. Спочатку варто подивитися сам HTTP-запит та відповідь сервера у вкладці Network.

Перевірка заголовків через curl

Для швидкої перевірки відповіді сервера можна скористатися командою curl. Наприклад:

curl -I https://example.com

Ключ -I дозволяє отримати HTTP-заголовки відповіді без завантаження всього вмісту сторінки.

Результат може виглядати приблизно так:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=3600
strict-transport-security: max-age=31536000

Такий спосіб зручний, коли потрібно швидко перевірити налаштування сервера з командного рядка.

У більшості випадків, коли на сайті щось поводиться дивно, я спочатку відкриваю Network і дивлюся конкретний запит. Це часто швидше, ніж одразу шукати причину в HTML, CSS, JavaScript або налаштуваннях CMS.

Що дає перевірка HTTP-заголовків?

HTTP-заголовки не потрібно знати напам'ять. Набагато корисніше розуміти, де їх знайти та який саме заголовок перевірити в конкретній ситуації.

Якщо не завантажується ресурс — дивимося його відповідь. Якщо не працює кеш — перевіряємо Cache-Control. Якщо браузер показує помилку CORS — дивимося Origin та CORS-заголовки. Якщо потрібно перевірити налаштування безпеки — переглядаємо відповідні заголовки у відповіді сервера.

У результаті DevTools → Network → Headers стає одним із перших місць, куди варто заглянути під час діагностики проблем із сайтом.

HTTP-заголовки: що варто запам’ятати

На початку роботи з HTTP-заголовками їхня кількість може трохи лякати. Насправді не потрібно знати напам’ять усі існуючі заголовки. Достатньо розуміти призначення основних із них і знати, де їх перевірити, коли на сайті виникає проблема.

Якщо на сайті виникла проблема

HTTP-заголовки можуть допомогти швидко знайти причину в багатьох типових ситуаціях:

• не завантажується CSS або JavaScript — перевірити Content-Type;
• сторінка постійно завантажує ресурси заново — перевірити Cache-Control;
• браузер блокує запит до API — перевірити CORS-заголовки;
• потрібно перевірити налаштування HTTPS — подивитися Strict-Transport-Security;
• сторінка не відкривається всередині iframe — перевірити X-Frame-Options;
• браузер повідомляє про заблокований ресурс — перевірити Content-Security-Policy.

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

HTTP-заголовки — це не окрема складна технологія, яку потрібно вивчати перед початком роботи з веброзробкою. Це частина звичайного HTTP-обміну, з якою розробник стикається практично щодня.

Чим краще ви розумієте основні заголовки, тим легше знаходити причини проблем із кешем, API, авторизацією, HTTPS та безпекою сайту.

Відповіді на часті питання

• Де подивитися HTTP-заголовки сайту?

  Найпростіший спосіб — відкрити DevTools у браузері та перейти до Network. Після цього потрібно вибрати потрібний запит і відкрити вкладку Headers. Тут можна переглянути як заголовки запиту (Request Headers), так і заголовки відповіді сервера (Response Headers).

• Чи можна змінити HTTP-заголовки сайту?

  Так. Більшість заголовків можна налаштувати на стороні сервера або reverse proxy. Наприклад, у конфігурації Apache чи Nginx можна додати заголовки без внесення змін у код кожної сторінки. Деякі заголовки також може формувати сама CMS або окреме розширення.

• Чи впливають HTTP-заголовки на швидкість завантаження сайту?

  Так, але вплив залежить від конкретного заголовка. Наприклад, правильно налаштований Cache-Control дозволяє браузеру зберігати ресурси в кеші та не завантажувати їх повторно під час кожного відвідування. Це може помітно скоротити кількість запитів і час завантаження сторінки. Водночас самі HTTP-заголовки займають дуже мало місця порівняно з HTML, зображеннями, CSS та JavaScript.

• Чи можна перевірити HTTP-заголовки без DevTools?

  Так. Для швидкої перевірки можна використовувати команду curl у терміналі:

  curl -I https://example.com

  У відповідь сервер покаже свої HTTP-заголовки. Такий спосіб зручний, коли потрібно швидко перевірити налаштування сервера або порівняти відповіді різних сторінок.