Как передаются данные в GET запросе

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

Знаете ли вы, какие части GET-запроса несут данные, и умеете ли превратить это в тест-кейсы. Следом обычно спрашивают, чем GET отличается от POST и можно ли отправить GET с телом.

Как отвечать

Данные в GET передаются в нескольких местах:

• строка запроса: после ?, пары key=value через &, например /api/orders?status=paid&page=2;
• путь: /api/orders/42, идентификатор ресурса прямо в URL;
• заголовки: Authorization, Accept-Language, собственные вроде X-Request-Id;
• cookies: браузер добавляет их сам в заголовок Cookie.

Тело у GET по RFC 9110 не имеет определённого смысла: часть серверов и прокси его отбрасывает или отвечает ошибкой. Спецсимволы и кириллица кодируются процентами в UTF-8: пробел это %20 (в формах +), & внутри значения %26. Для массивов стандарта нет: id=1&id=2, id[]=1 и id=1,2 серверы понимают по-разному, формат смотрят в спецификации API. Жёсткого лимита длины URL в стандарте тоже нет, но у nginx и Tomcat по умолчанию около 8 КБ, дальше ответ 414 URI Too Long или 400.

Что проверить:

• спецсимволы и кириллицу в значениях, пустые, повторяющиеся и неизвестные параметры;
• граничные значения пагинации и очень длинный URL;
• что пароли и токены не уходят в URL: он оседает в логах сервера и прокси, истории браузера и заголовке Referer;
• что GET ничего не меняет на сервере: метод безопасный и идемпотентный, его ответы кеширует браузер и CDN.

Инструменты: вкладка Params в Postman, Network в DevTools, curl -G --data-urlencode "q=иван петров".

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

Называют «2048 символов» ограничением протокола. Это старый предел Internet Explorer, реальные ограничения задают сервер и прокси.

Считают, что в HTTPS параметры видны всем. В сети TLS шифрует URL целиком, открыт только домен. Утечка происходит в логах и истории, а не в канале.

Забывают, что фрагмент после # на сервер не отправляется, и ищут его в логах бэкенда.