Чи можна відправляти body в GET-запиті?

Загальні питанняSenior~5 хв читання

GET request body - технічно надіслати можна, і він пройде через TCP, але RFC 7231 розділ 4.3.1 не визначає його семантику, тому більшість серверів відкидають його ще до того, як запит досягне твого коду.

Теорія

TL;DR

Тіло GET-запиту технічно надходить на рівні TCP. Що з ним відбувається далі - залежить від сервера.
RFC 7231 каже: payload у GET «не має визначеної семантики». Сервер може ігнорувати, переслати або повернути 411.
Nginx відкидає GET bodies до того, як запит досягає додатку. Express body-parser пропускає їх за замовчуванням.
Проксі-шари в продакшені (AWS ALB, Varnish) видаляють тіло без повідомлення.
Для фільтрів - query params. Для складних даних - POST.

Швидкий приклад

javascript

// Клієнт надсилає тіло - сервер його не бачить
fetch('/api/users', {
  method: 'GET',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ filter: 'active' })
})
.then(res => res.json())
.then(data => console.log(data));

// Сервер (Express):
app.get('/api/users', (req, res) => {
  console.log(req.body); // {} - body-parser пропустив GET
  res.json({ users: allUsers }); // Фільтрація не відбулась
});

Тіло пройшло в TCP-пакеті, але було відкинуте до того, як запустився обробник маршруту. Жодної помилки. Саме ця тиша і робить GET bodies такими непомітними в продакшені.

Що насправді говорить RFC 7231

Розділ 4.3.1 RFC 7231 формулює так: "A payload within a GET request message has no defined semantics." Одне речення - і вся проблема. Специфікація не забороняє тіло, вона каже, що сервер не зобов'язаний з ним щось робити. Тому сервери поводяться по-різному: одні ігнорують, інші пересилають далі, треті повертають 411.

Одночасно специфікація вимагає, щоб GET був безпечним (safe) і ідемпотентним (idempotent). Безпечний метод не повинен змінювати стан сервера. Як тільки ти передаєш логіку фільтрації в тілі - ти покладаєшся на поведінку, яку специфікація ніколи не гарантувала.

Як різні сервери обробляють тіло

Nginx з версії 0.7 відкидає GET bodies у модулі ngx_http_core_module ще до того, як запит потрапляє в додаток. Apache mod_proxy може переслати тіло далі, але записує попередження в лог. Express body-parser перевіряє req.method і пропускає GET та HEAD - тому req.body на GET-маршруті завжди {}, якщо не перевизначити параметр { type: '*/*' }.

AWS ALB видаляє GET bodies до того, як вони досягають Lambda. CDN-сервіси на кшталт Varnish і CloudFront будують ключ кешу тільки з URL, ігноруючи тіло. Якщо два різних клієнти надсилають однаковий URL з різними тілами - обидва отримають одну й ту ж кешовану відповідь. Це не проблема продуктивності, це баг у коректності даних.

Правила вибору

Просте отримання даних з фільтрами: query params (/users?active=true&role=admin)
Складні об'єкти фільтрації або дані більше приблизно 2KB: POST на ендпоінт пошуку (POST /users/search)
Потрібне кешування: тільки query params - RFC 7234 не включає тіло запиту в ключ кешу
GraphQL: завжди POST - GET з тілом для змінних ненадійний і вже прибраний в Apollo до версії 3.0

Elasticsearch - це свідомий виняток. Їхній ендпоінт _search приймає JSON-тіло при GET-запитах для підтримки повного Query DSL. В документації ES це прямо зазначено, і POST пропонується як альтернатива. Це рішення конкретної команди, а не загальний патерн.

Типові помилки

Помилка 1: Очікувати заповнений req.body в GET-обробнику Express

javascript

// Неправильно
app.use(express.json());
app.get('/users', (req, res) => {
  const { filter } = req.body; // Завжди undefined
  res.json(db.query(filter));
});

// Варіант виправлення: перейти на POST, або явно налаштувати middleware
app.use(express.json({ type: '*/*' }));
// Але додавати це лише заради GET bodies - погана угода

body-parser перевіряє req.method і виходить при GET і HEAD. Тіло ніколи не парситься.

Помилка 2: Передавати великий обсяг даних у тілі GET

javascript

// Неправильно - Safari може повернути 400, браузери обмежують розмір
fetch('/graphql', {
  method: 'GET',
  body: JSON.stringify(largeVariables) // 413 Payload Too Large у деяких клієнтах
});

// Правильно: POST відповідно до специфікації GraphQL
fetch('/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query, variables: largeVariables })
});

Safari відомий тим, що відхиляє GET-запити з тілом більше 2KB. Специфікація GraphQL рекомендує POST для всіх нетривіальних запитів.

Помилка 3: Розраховувати на кешування CDN при GET з тілом

javascript

// Хибне припущення - обидва запити використовують один запис у кеші
// Запит A: GET /api/data  +  body: { "tenant": "acme" }
// Запит B: GET /api/data  +  body: { "tenant": "contoso" }
// Contoso отримає дані Acme з кешу

// Правильно: фільтр в URL
// GET /api/data?tenant=acme
// GET /api/data?tenant=contoso

RFC 7234 будує ключ кешу з URL і окремих заголовків. Тіло запиту до ключа не входить.

Помилка 4: Працює локально, ламається в продакшені

Локальні Flask або plain Node HTTP сервери зазвичай парсять все, що отримують. Проблема з'являється після деплою за Nginx або cloud load balancer, який видаляє тіло. Розрив між dev і prod тут особливо болючий: код виглядає правильно локально, запит завершується з 200, і фільтрація просто перестає працювати без жодного повідомлення про помилку.

Де це зустрічається в реальному коді

Elasticsearch _search: GET з JSON-тілом для Query DSL. Документація прямо рекомендує POST як альтернативу.
Apollo GraphQL (до версії 3.0): підтримував GET body для змінних запиту. Прибрано на користь POST.
GitHub Enterprise: GET /search/code приймає тіло в деяких версіях (не задокументовано).
Splunk 9.x: GET /search/jobs/export використовує тіло для SPL-запитів.

Всі ці випадки - спадкові рішення або одноразовий вибір конкретних команд. Жоден з них не є патерном для нового коду.

Питання на співбесіді

Q: Чому мій GET з curl -d працює локально, але падає в продакшені?
A: Локальні dev-сервери парсять все, що отримують. Продакшн Nginx або CloudFront видаляє GET bodies до того, як вони досягають додатку. TCP-пакет приходить, але сервер відкидає тіло.

Q: Чи кешують CDN тіло GET-запиту?
A: Ні. RFC 7234 визначає ключ кешу як URL плюс окремі заголовки. Тіло не входить в ключ, тому CDN поверне кешовану відповідь незалежно від вмісту тіла.

Q: Як Axios і fetch поводяться при відправці GET body?
A: Обидва надсилають тіло на рівні TCP. Axios виводить попередження в консоль у деяких версіях. Fetch мовчить. В обох випадках ключова - поведінка сервера, а більшість серверів тіло відкидає.

Q: Мені потрібно передати 10KB даних фільтрації при GET-подібній операції. Що використовувати?
A: POST на ендпоінт пошуку. Назви його /search або /query і задокументуй як операцію читання. Додай заголовки ETag і Cache-Control, якщо бекенд має підтримувати кешування - деякі reverse proxies дозволяють це налаштувати і для POST.

Q: HTTP/2 щось змінює в цьому питанні?
A: Ні. HTTP/2 змінює фреймінг і мультиплексування, але не семантику методів. Поведінка GET body на рівні додатку залишається невизначеною.

Приклади

Базовий: тіло надіслано, тіло проігноровано

javascript

// client.js
const response = await fetch('/api/products', {
  method: 'GET',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ category: 'electronics' })
});

const data = await response.json();
// data містить ВСІ товари, а не тільки electronics
// Тіло було передане, але ніколи не прочитане

// server.js (Express)
app.use(express.json());

app.get('/api/products', (req, res) => {
  console.log(req.body); // {}
  res.json(db.getAll()); // Повертає все без фільтрації
});

Тіло покинуло клієнт, пройшло мережу і було відкинуто Express body-parser. Фільтрація не відбулась. Помилки не було.

Середній рівень: query params проти POST для складних фільтрів

javascript

// Неправильно: фільтр у тілі GET
// GET /api/orders  +  body: { "status": "pending", "userId": 42 }
// req.body = {} на сервері

// Правильно: прості фільтри в query string
// GET /api/orders?status=pending&userId=42
app.get('/api/orders', (req, res) => {
  const { status, userId } = req.query; // Працює надійно скрізь
  const orders = db.orders.filter(
    o => o.status === status && o.userId === Number(userId)
  );
  res.json(orders);
});

// Правильно: складні фільтри через POST
// POST /api/orders/search
app.post('/api/orders/search', express.json(), (req, res) => {
  const { filters, sort, pagination } = req.body; // Парситься коректно
  res.json(db.orders.search(filters, sort, pagination));
});

Query params для простих випадків. Окремий POST-ендпоінт для всього складного. Обидва підходи передбачувані на будь-якому проксі, CDN і фреймворку.

Просунутий рівень: Elasticsearch GET body (легітимний виняток)

bash

# Elasticsearch приймає тіло в GET для свого Query DSL
curl -X GET "localhost:9200/products/_search" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "bool": {
        "must": [{ "match": { "category": "electronics" } }],
        "filter": [{ "range": { "price": { "lte": 500 } } }]
      }
    },
    "sort": [{ "price": { "order": "asc" } }]
  }'

javascript

// Офіційний ES JS client надсилає POST під капотом
const result = await client.search({
  index: 'products',
  body: {
    query: {
      bool: {
        must: [{ match: { category: 'electronics' } }],
        filter: [{ range: { price: { lte: 500 } } }]
      }
    }
  }
});

ES додав підтримку GET body, бо Query DSL занадто складний для URL-кодування. Офіційний JS-клієнт все одно надсилає запит як POST під капотом. Якщо звертатись до REST API напряму через GET з тілом - це працює, бо команда ES спеціально реалізувала таку підтримку. Більшість інших серверів цього не зробила.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.