Когда я пытаюсь использовать krakend в качестве шлюза API и сделать POST-запрос, к данным добавляется дополнительный номер. Пример запроса:
curl -X POST -H "Content-Type: application/json" -d '{"username":"***","password":"***"}' http://127.0.0.1:8000/api/v1/token
Источник запроса, полученного веб-сервером (после кракенда):
b'POST /api/v1/token HTTP/1.1\r\nHost: host.docker.internal:8000\r\nUser-Agent: KrakenD Version 2.4.3\r\nTransfer-Encoding: chunked\r\nContent-Type: application/json\r\nX-Forwarded-For: 172.17.0.1\r\nX-Forwarded-Host: 127.0.0.1:8080\r\nAccept-Encoding: gzip\r\n\r\n'
b'23\r\n{"username":"***","password":"***"}\r\n'
b'0\r\n\r\n'
Конфигурация krakend.json:
{
"version": 3,
"debug_endpoint": true,
"endpoints": [
{
"endpoint": "/api/v1/token",
"method": "POST",
"backend": [
{
"url_pattern": "/api/v1/token",
"method": "POST",
"host": [ "http://host.docker.internal:8000" ]
}
]
}
]
}
Если я использую прямой запрос к бэкэнду, он не содержит 23 перед телом.
Почему у меня этот номер после шлюза Кракенда?
Похоже, ты прав. Тем не менее, я не понимаю, почему кракенд меняет запрос и добавляет собственные заголовки. И как мне избежать такого поведения.
Боюсь, вы не сможете, потому что кракенд не нарушает протокол HTTP. При этом я не знаком с кракендом — возможно, у него есть специальные настройки для отключения такого поведения. Обратите внимание: если восходящий поток не сообщил krakend, какова длина тела ответа, krakend придется использовать фрагментированное кодирование нисходящего потока.





Добавление этой опции в конечную точку помогло мне решить эту проблему:
"input_headers": ["Content-Type", "Content-Length"]
Детальная информация: https://www.krakend.io/docs/endpoints/parameter-forwarding/
ПС Моя версия кракенда — v2.4.3 (в предыдущих версиях эта опция называлась по-другому).
Рассмотрите возможность добавления этой ссылки в свой ответ, а также отметьте ее как принятую (это нормально для SO).
Я бы сделал дикое предположение и предположил, что вы наблюдаете за тем, что называется «кусковым кодированием» в HTTP. Если я прав, похоже, вы каким-то образом имеете дело с «сырым» HTTP, имея при этом недостаточные знания о протоколе, в частности, игнорируя поле
Transfer-Encodingответа сервера (в данном случае шлюза, который является прокси), что, вместо этого вы ДОЛЖНЫ уважать и действовать соответственно. (И это не единственный аспект, который необходимо учитывать при реализации правильного HTTP-клиента.)