从 Servlet 等发送估计的 HTTP 内容长度

发布于 2024-08-08 07:43:49 字数 125 浏览 3 评论 0原文

我经常需要从 servlet/restlet 或其他什么动态生成内容,并且提前不知道长度。如果客户端是浏览器,进度条无法正常工作,因为我没有设置Content-Length标头。有没有办法设置估计的内容长度,以便进度条“或多或少”工作?

I often need to generate content dynamically from a servlet / restlet or whatever, and don't know the length ahead of time. If the client is a browser, the progress bar doesn't work properly, because I haven't set the Content-Length header. Is there any way of setting an estimated content length, so the progress bar works "more or less"?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

你是年少的欢喜 2024-08-15 07:43:49

不可以,Content-Length 值必须是确切的内容长度

当在允许消息体的消息中给出内容长度时,其字段值必须与消息体中的八位字节数完全匹配。 HTTP/1.1 用户代理必须在收到并检测到无效长度时通知用户。

因此,您不能仅发送估计的 Content-Length 值来获取进度条。

No, the Content-Length value must be the exact content length:

When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.

So you cannot send just an estimated Content-Length value to get a progress bar.

仙气飘飘 2024-08-15 07:43:49

虽然我不建议这样做,但您可以将内容长度设置为内容的估计值,然后您将看到一个进度条。只要你能保证你的估计等于或大于实际内容,这通常是有效的。如果您的实际内容大于估计内容,则内容将被截断为指定的内容长度。

我在 Firefox、IE 和 Chrome 中对此进行了测试,没有出现任何问题。 HTTP 规范规定,如果指定的长度与实际长度不匹配,用户代理必须通知用户,但我在测试过的任何浏览器中都没有观察到这种行为。

我将其作为一个选项进行了研究,但由于在规范范围之外进行游戏可能会出现不可预见的冲突,因此放弃了它。

While I wouldn't recommend doing it you can set the content-length to an estimate of what the content is, and you will get a progress bar. As long as you can guarantee that your estimate is equal to or greater than the actual content this will generally work. If your actual content is greater than the estimate than the content will be truncated to the specified content-length.

I tested this in Firefox, IE, and Chrome without issue. The HTTP spec states that users agents MUST notify the user if the specified length doesn't match the actual length, but I have not observed this behavior with any browser I've tested.

I investigated this as an option but abandoned it due to the potential unforeseen conflicts for playing outside the bounds of the specification.

白首有我共你 2024-08-15 07:43:49

不清楚你在问什么。您始终可以自己设置 Content-Length 标头,但它需要实际匹配您发送的数据量。处理动态数据(您事先不知道任何长度)的标准方法是缓冲输出,找到实际长度,设置标头,然后转储输出。没有真正回答你似乎在问什么,但我认为你问的是不可能的。

Not clear what you're asking. You can always set the Content-Length header yourself, though it needs to actually match the amount of data you're sending. The standard way to handle dynamic data where you don't know anything about the length ahead of time is to buffer the output, find the actual length, set the header, then dump the output. Not really answering what you appear to be asking, but I think what you're asking is impossible.

緦唸λ蓇 2024-08-15 07:43:49

执行此操作的唯一方法(如 RFC 中所述)是不设置 Content-Length 标头,即。响应标头不包含 Content-Length 行。在这种情况下,浏览器不知道正文有多长,因此服务器“告诉”浏览器所有正文已通过 关闭连接

我不确定在这种情况下 Java 容器是否会自动关闭连接,或者您是否可以通过某种过滤器自行关闭连接。

回答你的问题:我认为不可能给浏览器一个估计。

The only way to do this (as decribed in an RFC) is not to set the Content-Length header, ie. the response header does not contain a Content-Length line. In this case the browser does not know how long the body is, so the server "tells" the browser that all of the body has been sent by closing the connection.

I'm not sure whether the Java container will automatically close the connection in this case or if you can do it yourself via some kind of Filter.

To answer your question: I do not think that it is possible to give the browser an estimate.

温柔戏命师 2024-08-15 07:43:49

如果事先未知内容的长度,您可以使用 “分块”内容编码(根据 HTTP 版本 1.1)。但这并不能解决你的进度条问题,除非你知道要发送多少内容,否则就没有办法让它发挥作用。

If the length of your content is not known beforehand you can use the “chunked” content encoding (as per HTTP version 1.1). This will not solve your progress bar problem, though—and there’s just no way to make it work unless you know how much content you are going to send.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文