Java UrlConnection HTTP 1.0
我正在尝试从我的 Java 应用程序下载文件。 但因为 UrlConnection 使用 HTTP 1.1 协议，我得到一个 Tranfer Encoding: chunked 响应，在这种情况下我无法找出文件大小（未设置内容长度）。 据我所知，HTTP 版本是硬编码在类中的，无法更改它。 是否可以以某种方式将版本更改回版本或告诉服务器在发送文件时不要使用分块编码？
编辑：我不想检索动态内容，我的应用程序是下载管理器。 我下载的文件是静态的。 我检查过的其他下载器 wget、igetter、curl 使用 Http 1.0，它们从大多数服务器获取大小信息。 但我的应用程序和 Firefox 发布 Http 1.1 总是获得分块编码。 我知道内容长度并不总是存在，但我希望大部分时间都能得到它。
I am trying to download a file from my Java application. But because UrlConnection uses HTTP 1.1 protocol i get a Tranfer Encoding: chunked response in which case i can not find out file size(content-length is not set). From what i could find HTTP version is hard coded in the class and there is no way to change it. Is it somehow possible to change the version back to one or tell the server not to use chunked encoding when sending a file?
Edit: I am not trying to retrive dynamic content my application is a download manager.
files i am downloading are static. Other downloaders i checked wget,igetter,curl use Http 1.0 and they get the size info from most servers. But my application and firefox issuing Http 1.1 always gets chunked encoding. I understand that content-length is not always present but i would like to get it most of time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Jakarta Commons HTTP 客户端包含一个“偏好架构”，允许对 HTTP 连接的细节进行一些细粒度的控制。 请参阅 http://hc.apache.org/httpclient-3.x /preference-api.html
The Jakarta Commons HTTP Client contains a "preference architecture" that allows some fine grained control over the particulars of the HTTP connection. See http://hc.apache.org/httpclient-3.x/preference-api.html
即使您指定了 HTTP/1.0，服务器也很可能无法指定有效的内容长度。 当内容是动态生成的时，服务器必须缓冲所有内容以测量其总长度。 并非所有服务器都能够回退到这种效率较低的行为。
如果缓冲响应是合理的，为什么不在您拥有完全控制权的客户端中进行呢？ 这比依赖服务器更安全。
读取响应而不进行处理，只需将数据填充到 ByteArrayOutputStream 中。 完成后，测量生成的字节数组的长度。 然后用它创建一个 ByteArrayInputStream 并处理该流来代替从 URLConnection 获取的流。
It's very likely that the server can't specify a valid content-length, even if you specify HTTP/1.0. When content is dynamically produced, the server has to buffer it all to measure its total length. Not all servers are going to be able to fallback to this less efficient behavior.
If buffering the response is reasonable, why not do it in your client, where you have full control? This is safer than relying on the server.
Read the response without processing, just stuffing the data into a
ByteArrayOutputStream. When you are done, measure the length of the resulting byte array. Then create aByteArrayInputStreamwith it and process that stream in place of the stream you got from theURLConnection.