ContentLength в объекте запроса репрезентует заголовок Content-Length. Но этот заголовок

Question

ContentLength в объекте запроса репрезентует заголовок Content-Length. Но этот заголовок

репрезентует длину тела сообщения, а не длину самой сущности. Разница в том, что тело сообщения может быть закодировано, например, сжато условным gzip. Тело сущности - декодированное тело сообщения. Я в своем фреймворке пользователю подаю сразу готовенькое и декодированное. В таком случае, ContentLength может не соответствовать реальному количеству байт, прочитанных из тела. Это может создать проблемы для пользователя?

#backend #go #programming #russian

0

11.06.2023

21 ответов

8 просмотров

Andrey S

А если нету заголовка Content-Length?

0

11 месяцев назад

Alex

Подозреваю, что когда прокси-сервер жмет в gz, он и переписывает этого заголовок на новое значение?

0

11 месяцев назад

Александр Костюченко

Andrey S
А если нету заголовка Content-Length?

он разве не обязательный по протоколу?

0

11 месяцев назад

Александр Костюченко

судя по спеке вы не должны модифицировать программно это значение, если верно вас понял

0

11 месяцев назад

Владимир Гришин

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

0

11 месяцев назад

Maxim Biryukov

Владимир Гришин
Это может создать проблемы в очень неожиданных мес...

Какой клиент?

0

11 месяцев назад

Владимир Гришин

Maxim Biryukov
Какой клиент?

Который дергает ручку

0

11 месяцев назад

Maxim Biryukov

Владимир Гришин
Который дергает ручку

Клиент который дёргает ручку никак не увидит что внутри фреймворка переписали хидер с длиной, более того автор вопроса про переписывание и не писал

0

11 месяцев назад

Andrey Likhachev

А зачем такие сложности? Чтобы два раза не аллоцировать тело?

0

11 месяцев назад

Павло Побуджувач Автор вопроса

Andrey S
А если нету заголовка Content-Length?

если не указан Connection: close, то тело будет обработано, как следующий запрос. Что, вероятнее всего, приведет к ошибке парсинга

0

11 месяцев назад

Павло Побуджувач Автор вопроса

Andrey Likhachev
А зачем такие сложности? Чтобы два раза не аллоцир...

не в аллокациях, а дизайне вопрос. Например, ожидает ли пользователь, что request.ContentLength будет строго равен размеру прочитанного тела?

0

11 месяцев назад

Павло Побуджувач Автор вопроса

Alex
Подозреваю, что когда прокси-сервер жмет в gz, он ...

ну да, Content-Length должен быть равен длине тела сообщения, а не сущности. Иными словами - фактический размер передаваемых данных

0

11 месяцев назад

Павло Побуджувач Автор вопроса

Александр Костюченко
судя по спеке вы не должны модифицировать программ...

нет, значение я модифицировать не буду, да и не смогу

0

11 месяцев назад

Maxim Biryukov

Если писать прокси, то 1) потерялось значение content length, и передавать его дальше неверно, и об этом надо капсом в доке писать 2) фреймворк задекодил тело, теперь нужно руками энкодить, если нужно было со сжатием или в точности передать тело - некруто, лишняя работа 3) можно было как то хитро использовать io.CopyBuffer с буфером зависимым от length, это теперь тоже нельзя делать 4) явное поведение лучше неявного

0

11 месяцев назад

Павло Побуджувач Автор вопроса

Maxim Biryukov
Если писать прокси, то 1) потерялось значение co...

вот прокси как раз может спокойно модифицировать запрос, такое поведение будет некорректным для гейтвея

0

11 месяцев назад

Andrey Likhachev

Павло Побуджувач
не в аллокациях, а дизайне вопрос. Например, ожида...

Да. Стабильно будет проверять. Еще есть вариант с посылкой частями. Это же часть протокола.

0

11 месяцев назад