HTTP HEAD 响应 - 设置内容长度

发布于 2024-08-02 08:01:19 字数 225 浏览 2 评论 0原文

我正在尝试为我们的一项服务构建一个 HEAD 方法,以便客户可以在决定是否下载之前查看内容类型和大小。

如何设置响应头的内容长度?使用 HttpContext 公开 ContentType、编码等,但我无法指定长度,因为我假设该值通常是在将某些内容添加到响应时由框架添加的。

是否有另一种方法可以做到这一点,或者我是否错误地设置了 HEAD 请求的长度 - 我实际上应该添加自定义标头来返回资源的大小吗?

I'm trying to build a HEAD method to one of our services so that clients can peek at the content type and size before deciding whether to download it.

How can I set the Content Length of the response header? Using HttpContext exposes the ContentType, Encoding etc but I can't specify a length as I presume this value is normally added by the framework when some content is added to the response.

Is there another way of doing this or am I incorrect to be setting the length for a HEAD request - should I actually be adding a custom header to return the size of the resource?

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

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

发布评论

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

评论(1

想你只要分分秒秒 2024-08-09 08:01:19

我认为 Content-Length 指定响应正文的大小 - 而不是资源的大小。因此,它在 HEAD 响应的上下文中没有意义。

编辑:规格说明:

HEAD 方法与 GET 相同,只是服务器不得在响应中返回消息正文。响应 HEAD 请求的 HTTP 标头中包含的元信息应该与响应 GET 请求而发送的信息相同。此方法可用于获取有关请求所隐含的实体的元信息,而无需传输实体主体本身。此方法通常用于测试超文本链接的有效性、可访问性和最近修改情况。

对 HEAD 请求的响应可以是可缓存的,因为响应中包含的信息可以用于从该资源更新先前缓存的实体。如果新的字段值表明缓存的实体与当前实体不同(如 Content-Length、Content-MD5、ETag 或 Last-Modified 的更改所示),则缓存必须将缓存条目视为过时。

-- http://www.w3.org/Protocols/ rfc2616/rfc2616-sec9.html#sec9.4

这表明我上面的说法是错误的。特别是后一段强烈建议 HEAD 可以有一个 Content-Length 标头。

I think a Content-Length specifies the size of the body of the response - not the size of the resource. As such, it doesn't make sense in the context of a HEAD response.

Edit: The specs says:

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

-- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4

This suggests that my above statement is wrong. Especially the latter paragraph strongly suggests that a HEAD can have a Content-Length header.

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