Можно ли установить заголовок длины содержимого, а также использовать кодирование передачи по частям? и решает ли это проблему незнания длины ответа на стороне клиента при использовании фрагментов?
сценарий, о котором я думаю, - это когда у вас есть большой файл для передачи и нет проблем с определением его размера, но он слишком велик для полной буферизации. (Если вы не используете chunked, тогда сначала должен быть буферизован весь ответ? Верно ??)
благодаря.
1) Нет: «Сообщения НЕ ДОЛЖНЫ включать в себя как поле заголовка Content-Length, так и неидентификационное кодирование передачи. Если сообщение действительно включает в себя неидентификационное кодирование передачи, Content-Length ДОЛЖНО игнорироваться». (RFC 2616, раздел 4.4)
2) И нет, вы можете использовать Content-Length и stream; протокол не ограничивает работу вашей реализации.
Что ж, вы всегда можете отправить заголовок с указанием размера файла. Что-то вроде response.addHeader("File-Size","size of the file");
И игнорируйте заголовок Content-Length.
Клиентская реализация должна быть настроена, чтобы читать это значение, но эй, вы можете достичь того, чего хотите :)
X-. Прокси-сервер HTTP вполне может решить отбросить ваш нестандартный не-X-заголовок.
- person MSalters; 06.04.2017
X- в нестандартных заголовках осуждается, не рекомендуется и не считается передовой практикой. Просто используйте file-size в качестве имени заголовка, все в порядке. tools.ietf.org/html/rfc6648
- person isaacs; 14.09.2017
Вы должны использовать Content-Length или chunking, но не то и другое одновременно.
Если вы заранее знаете длину, вы можете использовать Content-Length вместо фрагментов, даже если вы генерируете контент на лету и никогда не храните его сразу в своем буфере.
Однако вам не следует этого делать, если данные действительно большие, потому что прокси-сервер может не справиться с ними. Для больших данных безопаснее разбивать их на части.
