分块编码和内容长度标头 [英] Chunked encoding and content-length header

查看:37
本文介绍了分块编码和内容长度标头的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

是否可以设置内容长度标头并使用分块传输编码?这样做是否解决了使用chunked时客户端不知道响应长度的问题?

Is it possible to set the content-length header and also use chunked transfer encoding? and does doing so solve the problem of not knowing the length of the response at the client side when using chunked?

我正在考虑的场景是,当您有一个大文件要传输并且确定其大小没有问题,但它太大而无法完全缓冲时.(如果你不使用分块,那么整个响应必须首先被缓冲?对吗??)

the scenario I'm thinking about is when you have a large file to transfer and there's no problem in determining its size, but it's too large to be buffered completely. (If you're not using chunked, then the whole response must get buffered first? Right??)

谢谢.

推荐答案

1) 否:消息不得同时包含 Content-Length 标头字段和非身份传输编码.如果消息确实包含非身份传输编码,内容长度必须被忽略."(RFC 2616,第 4.4 节)

1) No: "Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored." (RFC 2616, Section 4.4)

2) 不,你可以使用 Content-Length 和流;该协议不限制您的实现方式.

2) And no, you can use Content-Length and stream; the protocol doesn't constrain how your implementation works.

这篇关于分块编码和内容长度标头的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆