HTTP

01Формат сообщения

HTTP — протокол «запрос–ответ», как официант, который принимает заказ и приносит блюдо. У запроса есть стартовая строка (метод, путь, версия), заголовки (пары ключ: значение) и необязательное тело. У ответа — строка статуса (версия, код, пояснение), заголовки и необязательное тело. HTTP не хранит состояние: каждый запрос самостоятелен, а состояние, например вход в систему, переносится через cookie или токены. В HTTP/2 и HTTP/3 те же сообщения передаются бинарными фреймами, но смысл тот же, поэтому текстовая форма ниже по-прежнему лучший способ о них думать.

1POST /api/orders HTTP/1.1
2Host: api.example.com
3Content-Type: application/json
4Authorization: Bearer <token>
5Content-Length: 39
6 
7{"productId": 42, "quantity": 2}
8 
9HTTP/1.1 201 Created
10Location: /api/orders/1001
11Content-Type: application/json
12 
13{"id": 1001, "status": "pending"}

02Методы и их обещания

GET читает ресурс и ничего не должен менять. HEAD — это GET без тела, удобен для проверок. POST создаёт что-то или запускает действие. PUT полностью заменяет ресурс, PATCH меняет его часть, DELETE удаляет. OPTIONS спрашивает, что разрешено, и используется в CORS preflight-запросах. Важны два свойства. Безопасные методы (GET, HEAD, OPTIONS) не меняют состояние, поэтому краулеры и prefetch могут вызывать их свободно. Идемпотентные методы (GET, HEAD, PUT, DELETE, OPTIONS) дают тот же результат при повторе, поэтому клиенты могут повторить их после таймаута. POST и PATCH по умолчанию не идемпотентны: повтор POST может создать два заказа, если сервер не использует ключ идемпотентности.

• Никогда не меняйте данные на GET: их может запустить превью ссылки или prefetch.
• Автоматически повторяйте только идемпотентные запросы.
• Для неподдерживаемых методов возвращайте 405 Method Not Allowed с заголовком Allow.

03Семейства статус-кодов

Всё говорит первая цифра. 1xx — информационные (103 Early Hints позволяет серверу отправить подсказки для preload до настоящего ответа). 2xx — успех: 200 OK, 201 Created, 204 No Content. 3xx — перенаправление: 301 и 308 постоянные, 302 и 307 временные (307 и 308 сохраняют метод и тело), 304 Not Modified для кэширования. 4xx — ошибки клиента: 400 Bad Request, 401 Unauthorized (не аутентифицирован), 403 Forbidden (аутентифицирован, но нет прав), 404 Not Found, 405, 409 Conflict, 410 Gone, 413 Payload Too Large, 415 Unsupported Media Type, 422 Unprocessable Content (валидация), 429 Too Many Requests. 5xx — ошибки сервера: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout. Правильные коды позволяют клиентам, кэшам, мониторингу и поисковикам вести себя корректно, не читая тело.

04Заголовки и cookie

Заголовки несут метаданные. В запросе: Host, Accept, Accept-Language, Authorization, Content-Type, User-Agent, Cookie. В ответе: Content-Type, Content-Length, Location, Set-Cookie, Cache-Control и заголовки безопасности — Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff и Referrer-Policy. Cookie — это небольшие значения, которые сервер просит браузер сохранить и отправлять обратно с каждым запросом к этому сайту. Насколько они безопасны, решают флаги. Secure: отправляется только по HTTPS. HttpOnly: JavaScript не может её прочитать, что ограничивает ущерб от XSS. SameSite=Lax (значение браузера по умолчанию) блокирует отправку в большинстве кросс-сайтовых запросов, Strict блокирует во всех, None разрешает кросс-сайтовые, но требует Secure. Path, Domain и Max-Age управляют областью действия и временем жизни. Префикс __Host- принудительно требует Secure, Path=/ и отсутствие Domain.

1HTTP/1.1 200 OK
2Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200
3Strict-Transport-Security: max-age=31536000; includeSubDomains
4X-Content-Type-Options: nosniff
5Referrer-Policy: strict-origin-when-cross-origin
6Content-Security-Policy: default-src 'self'; img-src 'self' data:

05Кэширование: Cache-Control, ETag, 304

Кэширование избавляет от лишней работы. Cache-Control говорит браузерам и CDN, что делать: max-age=31536000, immutable — для версионированных ресурсов вроде app.3f9a1c.js; no-cache — для HTML, который можно хранить, но нужно каждый раз перепроверять; no-store — для чувствительных данных, которые нельзя хранить никогда; private — для ответов, предназначенных только браузеру одного пользователя; s-maxage — для общих кэшей вроде CDN; stale-while-revalidate — чтобы отдавать слегка устаревшую копию, пока в фоне идёт обновление. Валидаторы делают перепроверку дешёвой: сервер отправляет ETag (отпечаток) или Last-Modified, позже браузер присылает If-None-Match или If-Modified-Since, и если ничего не изменилось, сервер отвечает 304 Not Modified без тела. Vary сообщает кэшам, какие заголовки запроса влияют на ответ, например Accept-Encoding.

1GET /app.css HTTP/1.1
2Host: example.com
3If-None-Match: "a1b2c3"
4 
5HTTP/1.1 304 Not Modified
6ETag: "a1b2c3"
7Cache-Control: no-cache

06CORS без путаницы

Браузеры соблюдают same-origin policy: страница на https://app.example.com не может читать ответы с https://api.example.com, если API этого не разрешает. CORS (Cross-Origin Resource Sharing) — это способ, которым сервер выдаёт такое разрешение через заголовки ответа. Простым запросам достаточно Access-Control-Allow-Origin. Запросы с JSON-телом, собственными заголовками вроде Authorization или методами вроде PUT и DELETE вызывают preflight: браузер сначала отправляет OPTIONS и спрашивает, разрешён ли настоящий запрос. Если используются cookie, сервер должен вернуть точный origin (не *) и Access-Control-Allow-Credentials: true. CORS соблюдают только браузеры; он не защищает ваш API от curl или других серверов, поэтому аутентификация всё равно нужна.

1OPTIONS /api/orders HTTP/1.1
2Origin: https://app.example.com
3Access-Control-Request-Method: POST
4Access-Control-Request-Headers: content-type, authorization
5 
6HTTP/1.1 204 No Content
7Access-Control-Allow-Origin: https://app.example.com
8Access-Control-Allow-Methods: GET, POST, PATCH, DELETE
9Access-Control-Allow-Headers: content-type, authorization
10Access-Control-Allow-Credentials: true
11Access-Control-Max-Age: 600
12Vary: Origin

07Как смотреть HTTP на практике

Вкладка Network в браузере показывает каждый запрос с заголовками, таймингами, cookie и ответом. Кликните правой кнопкой по запросу и выберите Copy as cURL, чтобы воспроизвести его в терминале. curl -v печатает весь обмен; -I получает только заголовки. Для API помогают Postman, Insomnia или HTTPie, но обычный curl в ранбуке — самый переносимый вариант. При отладке сравнивайте рабочий и сломанный запросы бок о бок: обычно разницу объясняет один заголовок, cookie или статус-код. Не забывайте удалять токены и cookie, прежде чем делиться скопированным запросом с кем-либо.

1curl -sI https://example.com/                      # headers only
2curl -v https://api.example.com/health             # full exchange
3curl -s -X POST https://api.example.com/orders \
4  -H "Content-Type: application/json" \
5  -H "Authorization: Bearer $TOKEN" \
6  -d '{"productId":42,"quantity":2}' -w "\n%{http_code}\n"

08Границы сообщений и request smuggling

В HTTP/1.1 получатель должен знать, где заканчивается тело. Content-Length задаёт размер в байтах; Transfer-Encoding: chunked отправляет тело частями, у каждой своя длина, а в конце идёт чанк нулевого размера. Если в запросе есть оба заголовка или искажённая версия одного из них, фронтовой прокси и бэкенд-сервер могут по-разному понять, где кончается запрос. Тогда атакующий может спрятать второй запрос в теле первого, и бэкенд воспримет его как начало запроса следующего пользователя. Это HTTP request smuggling, и с его помощью можно обойти правила безопасности или отравить кэш. Защита: обновляйте прокси и серверы, отклоняйте запросы с обоими заголовками или некорректными границами, по возможности используйте HTTP/2 на всём пути и избегайте самописных прокси. У HTTP/2 и HTTP/3 своё фреймирование, но даунгрейд до HTTP/1.1 на прокси возвращает риск.

09Условные запросы для безопасных параллельных изменений

Два админа открывают один и тот же товар, оба его редактируют, и второе сохранение молча перезаписывает первое: проблема потерянного обновления. HTTP решает её валидаторами. Ответ на GET содержит ETag (отпечаток версии). Клиент отправляет изменение с If-Match, равным этому ETag. Если ресурс за это время изменился, сервер отказывает с 412 Precondition Failed, а клиент перезагружает данные и сливает изменения. If-None-Match: * в PUT означает «создать, только если не существует», что защищает от случайной перезаписи. Сервер может требовать предусловия при записи через 428 Precondition Required. Внутри это удобно ложится на колонку version или проверку updated_at в одном выражении UPDATE ... WHERE version = ?, так что проверка и запись атомарны.

1GET /api/products/42 HTTP/1.1
2 
3HTTP/1.1 200 OK
4ETag: "v7"
5 
6PATCH /api/products/42 HTTP/1.1
7If-Match: "v7"
8Content-Type: application/json
9 
10{"price": 4900}
11 
12HTTP/1.1 412 Precondition Failed      # someone saved v8 first

10Content negotiation, Vary и range-запросы

У одного URL может быть несколько представлений. Клиент сообщает предпочтения через Accept, Accept-Language и Accept-Encoding, а сервер выбирает одно, в идеале отвечая 406, если ничего не подходит. Любой заголовок, который меняет ответ, должен быть указан в Vary, иначе кэш может отдать тело в Brotli клиенту, который понимает только gzip, или русскую страницу англоязычному посетителю. Vary также дробит кэш: Vary: User-Agent или Vary: Cookie могут сделать кэширование почти бесполезным, поэтому для языков лучше отдельные URL, а Vary по возможности ограничить Accept-Encoding. Range-запросы позволяют клиенту запросить часть файла через Range: bytes=0-1023; сервер отвечает 206 Partial Content и сообщает о поддержке через Accept-Ranges: bytes. На этом держатся перемотка в видеоплеерах и докачка в менеджерах загрузок.

1curl -s -o /dev/null -D - -H "Range: bytes=0-1023" https://example.com/video.mp4
2# HTTP/2 206
3# content-range: bytes 0-1023/48213004
4# accept-ranges: bytes

11Cookie между сайтами, поддоменами и фреймами

Site и origin — разные понятия. Origin — это scheme + host + port; site — регистрируемый домен, поэтому app.example.com и api.example.com — разные origin, но один site. Правила SameSite работают с site, поэтому cookie с SameSite=Lax всё равно отправляется между вашими поддоменами. В межсайтовом контексте Lax-cookie уходят только с навигациями верхнего уровня методом GET и никогда — с fetch или POST-формами с другого сайта. Cookie с атрибутом Domain доступны всем поддоменам, включая те, что обслуживает сторонний сервис, поэтому сессионные cookie держите host-only. Сторонние контексты ограничены: Safari и Firefox по умолчанию блокируют third-party cookie, а Partitioned cookie (CHIPS) позволяют встроенному виджету хранить состояние отдельно для каждого сайта верхнего уровня. Браузеры также ограничивают размер cookie — около 4 KB на каждую, и каждая cookie отправляется с каждым запросом, так что большие cookie съедают трафик.

1Set-Cookie: __Host-sid=8f2c...; Path=/; Secure; HttpOnly; SameSite=Lax
2Set-Cookie: widget_state=abc; Path=/; Secure; SameSite=None; Partitioned