Топ 6 вещей, которые нужно знать про HTTP

Методы и идемпотентность

не формальность, а прямое указание, можно ли повторять запрос

Смысл методов простой. GET — прочитать, ничего не меняя. POST — создать или выполнить действие. PUT — положить ресурс целиком по известному адресу. PATCH — изменить часть. DELETE — удалить.

Два свойства, ради которых всё это придумано. Безопасный метод не меняет состояние на сервере — таков GET. Идемпотентный метод можно повторить сколько угодно раз с тем же результатом: PUT и DELETE идемпотентны, POST — нет.

Зачем это на практике. Сеть ненадёжна: ответ может потеряться, клиент — повторить. Библиотеки и прокси спокойно повторяют GET, PUT и DELETE и не повторяют POST. Отсюда правило: если действие нельзя выполнять дважды, оно не должно висеть на GET. Классическая ошибка новичка — удаление по обычной ссылке: достаточно, чтобы по этому адресу прошёлся любой обходчик страниц.

Ключ идемпотентности. Для платежей и заказов, где повтор недопустим, придумали приём: клиент генерирует уникальный ключ операции и присылает его в заголовке. Сервер запоминает и на повторный запрос с тем же ключом отдаёт прежний результат вместо второго списания. Это не часть протокола, а соглашение, но встречается почти во всех платёжных интерфейсах.

• Даёт понятное правило, когда повтор безопасен
• Убирает целый класс багов с двойными действиями
• Делает поведение API предсказуемым для чужих клиентов

• Разница между PUT и PATCH на практике трактуется вольно
• Идемпотентность на сервере нужно обеспечивать самому, протокол её не гарантирует

каждый запрос · оценка 9,4

Коды состояния

первое, что смотрят при разборе любой проблемы

Группы запоминаются легко: 2xx — получилось, 3xx — ищи в другом месте, 4xx — виноват клиент, 5xx — виноват сервер. Уже это деление экономит время: 4xx означает, что чинить надо запрос, 5xx — что чинить надо сервер, и разбираться в этих случаях нужно в совершенно разных местах.

Пары, которые путают чаще всего. 401 — «я не знаю, кто вы» (нет или просрочены данные для входа). 403 — «я знаю, кто вы, и вам сюда нельзя». Отдавать 401 при нехватке прав — распространённая ошибка: клиент честно попробует переавторизоваться и попадёт в цикл.

404 и 410. Первый — «не найдено, может, никогда и не было». Второй — «было, но удалено навсегда». Для поисковых систем это разные сигналы, но 410 применяют редко и осознанно.

Полезные коды, о которых забывают. 201 при успешном создании, с адресом созданного объекта в заголовке. 204 — успех без содержимого. 409 — конфликт, например попытка создать то, что уже есть. 422 — данные разобрались, но не прошли проверку. 429 — слишком много запросов, притормозите.

Из серверных. 500 — упало ваше приложение. 502 и 504 — упал или не ответил тот, кто стоит за прокси. 503 — сервис временно недоступен. Разница подсказывает, где смотреть логи, ещё до того, как вы их открыли.

Главный антипаттерн. Отдавать 200 с текстом ошибки внутри тела. Так делают удивительно часто, и после этого ни один клиент, ни один мониторинг и ни один повтор при сбое не работают правильно.

• Мгновенно указывает, на чьей стороне проблема
• Клиенты и мониторинг умеют реагировать автоматически
• Учится за один вечер и не забывается

• Часть кодов трактуется разными командами по-разному
• Один код без внятного тела ошибки мало что объясняет пользователю

каждый ответ · оценка 9,5

HTTPS и что он на самом деле даёт

не галочка в настройках, а условие работы всего остального

Шифрование канала даёт три вещи: содержимое запросов нельзя прочитать по дороге, его нельзя незаметно подменить и вы уверены, что говорите с тем сервером, чьё имя набрали. Без этого любой промежуточный узел видит пароли, токены и куки открытым текстом.

Что не защищено. Имя сайта, к которому вы обращаетесь, обычно всё равно видно наблюдателю, а сертификат подтверждает только принадлежность домена, но ничего не говорит о добросовестности владельца. Замок в адресной строке не означает, что сайт не мошеннический.

Смешанное содержимое. Защищённая страница, подгружающая скрипт по незащищённому адресу, — дыра ровно того же размера, что и полностью незащищённый сайт. Браузеры такое блокируют, и это одна из типовых причин «на проде всё сломалось, а локально работало».

Строгая политика. Специальный заголовок предписывает браузеру ходить на сайт только по защищённому протоколу и запоминает это на указанный срок. Полезно, но включать стоит осознанно: откатить решение на уже посетивших сайт браузерах быстро не получится.

Сертификаты. Бесплатные автоматические сертификаты давно стали нормой, срок жизни у них короткий, и продление должно быть автоматическим. Просроченный сертификат — типовая авария выходного дня, и почти всегда причина в том, что автопродление настроили один раз и забыли проверить.

• Закрывает перехват и подмену данных по дороге
• Обязателен для современных возможностей браузера
• Автоматические сертификаты бесплатны и ставятся быстро

• Просроченный сертификат кладёт сайт целиком
• Смешанное содержимое ломает страницы неочевидным образом
• Строгая политика включается легко, а отключается долго

всегда · оценка 9,3

Заголовки кеширования

источник и самых больших ускорений, и самых странных багов

Главный заголовок управления кешем задаёт две вещи: кому можно хранить ответ и сколько. Значение «приватно» разрешает хранить только браузеру конкретного пользователя, «публично» — ещё и промежуточным узлам, «не хранить» запрещает вовсе.

Проверка свежести. Сервер может отдать вместе с ответом метку версии содержимого или дату последнего изменения. В следующий раз браузер присылает её обратно и получает либо новый ответ, либо короткий код 304 «не изменилось» — без тела. Трафика почти ноль, а данные гарантированно актуальны.

Рабочая схема для сайта. Статические файлы — на долгий срок, с отпечатком содержимого в имени файла: изменился файл, изменилось имя, старое просто перестало запрашиваться. HTML-страницы — с проверкой свежести или на очень короткий срок.

Самая опасная ошибка. Разрешить публичное кеширование персонального ответа. Промежуточный узел сохранит страницу одного пользователя и покажет её другому. Всё, что зависит от того, кто вы, должно помечаться как приватное или некешируемое явно.

При отладке. Половина загадочных «у меня старая версия» решается принудительным обновлением с отключённым кешем. Если после этого всё нормально — вы нашли, где именно неправильные заголовки.

• Правильные заголовки ускоряют повторные визиты радикально
• Проверка свежести экономит трафик, не жертвуя актуальностью
• Настраивается на уровне сервера, без правок в коде

• Ошибка приводит к показу чужих данных — цена максимальная
• Сбросить уже разосланный длинный кеш почти невозможно
• Поведение промежуточных узлов и браузеров различается в мелочах

статика и API · оценка 9,2

Куки и их флаги

четыре атрибута, от которых зависит безопасность входа

Кука — это пара «имя и значение», которую сервер просит браузер сохранить и присылать обратно. Так и держится вход: браузер сам прикладывает её к каждому запросу на подходящий адрес.

Флаг «только для сервера». Запрещает читать куку из скриптов на странице. Для куки с идентификатором сессии обязателен: если чужой скрипт сумеет выполниться на вашей странице, без этого флага он унесёт сессию целиком.

Флаг «только по защищённому соединению». Кука не отправляется по незащищённому протоколу. Тоже обязателен, иначе один случайный переход по незащищённому адресу — и она уехала открытым текстом.

Правило отправки на чужие сайты. Управляет тем, приложится ли кука к запросу, инициированному другим сайтом. Строгий режим лучше всего защищает от подделки запросов, но ломает сценарии с переходом из внешних систем — например, возврат с платёжного шлюза. Средний режим обычно и есть разумный компромисс.

Домен и путь. Определяют, куда именно кука будет прикладываться. Отсюда классическая проблема «вошёл на сайте, а на поддомене не вошёл»: кука выставлена на конкретный хост, а не на домен с поддоменами.

Про срок. Кука без срока живёт до закрытия браузера, со сроком — до указанной даты. Для сессий короткий срок лучше длинного, а по-настоящему правильный вариант — короткая сессия плюс отдельный механизм продления.

• Три флага закрывают большинство типовых атак на сессию
• Браузер сам прикладывает куку — на клиенте писать нечего
• Работает одинаково во всех браузерах

• Настройки по умолчанию небезопасны, всё нужно указывать явно
• Ограничения на междоменные куки постоянно ужесточаются
• Проблемы с доменом и путём отлаживаются мучительно

вход и сессии · оценка 9,1

Редиректы

простая тема с двумя ловушками, на которые попадаются все

301 и 308 — переезд навсегда, 302 и 307 — временно. Разница важна: постоянный редирект браузеры и поисковые системы запоминают, и отменить его на уже посетивших машинах трудно. Если не уверены — временный.

Первая ловушка — метод. Исторически при получении 301 и 302 клиенты меняли POST на GET, и это поведение закрепилось. Именно поэтому появились 307 и 308: они гарантируют, что метод и тело сохранятся. Для API это принципиально — иначе отправленные данные тихо теряются по дороге.

Вторая ловушка — цепочки. Каждый редирект — это лишний круг до сервера. Цепочка из трёх переходов заметна на мобильной связи, а замкнувшееся кольцо даёт ошибку, которую пользователь видит как сломанный сайт. Проверять цепочку стоит после каждой перенастройки адресов.

Типовая схема. С незащищённого протокола на защищённый, с варианта с приставкой в имени на основной домен — или наоборот. Главное, чтобы всё сводилось к одному адресу за один переход, а не последовательными шагами.

• Позволяет менять адреса, не теряя пользователей и позиции
• Настраивается на веб-сервере в пару строк
• Легко проверяется утилитой командной строки

• Постоянный редирект тяжело откатить: он закеширован у людей
• Смена метода при переходе теряет тело запроса
• Цепочки и кольца ломают сайт незаметно для владельца

адреса и переезды · оценка 8,8