Что происходит после принятия HTTP GET запроса на сервере

Что проверяют

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

Как отвечать

По шагам, коротко:

• сервер принимает соединение, для https поверх него поднимается TLS;
• читается стартовая строка и заголовки, по Host выбирается виртуальный хост;
• маршрутизатор подбирает обработчик по пути и методу, до него запрос проходит промежуточные слои: логирование, аутентификация, ограничение частоты, разбор параметров;
• обработчик достаёт данные из базы или кэша и сериализует их;
• собирается ответ: статус, заголовки, тело;
• соединение обычно остаётся открытым, в HTTP/2 запросы идут по нему параллельно.

Дальше переведите разговор на то, что видно с вашей стороны. Смысл GET в том, что он безопасный и идемпотентный: состояние не меняет, повтор ничего не ломает, поэтому его вольны кэшировать браузер и прокси. Отсюда Cache-Control, ETag и условный запрос с If-None-Match, на который сервер отвечает 304 без тела. Отдельно стоит упомянуть, что кросс-доменному GET с нестандартными заголовками предшествует предварительный запрос, и его тоже обрабатывает сервер.

Где спотыкаются

Уверены, что на каждый запрос поднимается новое соединение. Постоянные соединения и мультиплексирование в HTTP/2 меняют картину: дробить запросы на множество мелких уже не так дорого, как было.

Считают параметры строки запроса безобидными. Они попадают в логи сервера, в историю браузера и в заголовок перехода, поэтому токен или персональные данные туда не кладут.

Путают 304 и ответ из кэша. При 304 запрос до сервера всё-таки доехал и вернулся без тела, а свежий ответ из памяти браузера отдаётся вообще без обращения к сети, и в панели сети это видно по источнику и размеру.