本文深入探讨HTTP ETag在重定向场景下的行为及Go语言客户端的实现策略。我们将解析ETag与重定向URL的关联，以及服务器在处理条件请求时，重定向状态码如何优先于ETag等前置条件。通过Go语言示例代码，分析客户端如何正确管理ETag，并强调在面对重定向时，应将ETag与最终资源URL关联，同时警惕重定向响应中ETag的有效性。
理解HTTP ETag与条件请求
HTTP ETag（实体标签）是HTTP协议中用于缓存验证的一种机制，它允许客户端和服务器有效地判断资源是否已更改。当客户端发起请求时，如果它之前接收过该资源的ETag，可以通过 If-None-Match 请求头将其发送给服务器。服务器收到后，会比较请求中的ETag与当前资源的ETag。如果匹配，服务器通常会返回 304 Not Modified 状态码，指示客户端使用其缓存副本，从而节省带宽和服务器资源。如果不匹配，服务器则返回 200 OK 状态码和更新后的资源内容，并附带新的ETag。
Go语言客户端的ETag管理实现
为了演示ETag在客户端的实际应用，我们构建一个自定义的Go语言HTTP客户端，它能够自动存储和发送ETag。以下是该客户端的核心实现：
package util
import (
"net/http"
"net/url"
)
// HttpClient 扩展了标准的 http.Client，增加了 ETag 管理功能
type HttpClient struct {
http.Client
etags map[url.URL]string // 存储 URL 到 ETag 的映射
}
// Do 方法拦截请求，实现 ETag 的发送和存储逻辑
func (hc *HttpClient) Do(req *http.Request) (*http.Response, error) {
const ETAG_SERVER_HEADER = "ETag"
const ETAG_CLIENT_HEADER = "If-None-Match"
// 仅对 GET 请求处理 ETag
if req.Method != "GET" {
return hc.Client.Do(req)
}
// 检查是否存在当前 URL 的 ETag
// 注意：这里使用 *req.URL 作为 key，这在重定向场景下需要特别注意
etag, ok := hc.etags[*req.URL]
if ok {
// 如果存在 ETag，将其添加到 If-None-Match 请求头
if req.Header == nil {
req.Header = http.Header{}
}
req.Header.Add(ETAG_CLIENT_HEADER, etag)
}
// 执行实际的 HTTP 请求
response, err := hc.Client.Do(req)
// 如果请求成功且没有错误
if err == nil {
if hc.etags == nil {
hc.etags = make(map[url.URL]string)
}
// 从响应头中获取 ETag，如果存在则存储
// 关键点：这里应该使用 response.Request.URL 来存储 ETag，
// 因为它代表了经过重定向后的最终资源URL。
serverEtag := response.Header.Get(ETAG_SERVER_HEADER)
if len(serverEtag) != 0 {
// 修正：将 ETag 关联到最终请求的 URL
hc.etags[*response.Request.URL] = serverEtag
}
}
return response, err
}代码解析与改进点：
立即学习“go语言免费学习笔记（深入）”；
上述代码通过在 Do 方法中拦截请求，实现了ETag的自动管理。当发起 GET 请求时，客户端会检查本地缓存中是否存在该URL对应的ETag。如果存在，则将其添加到 If-None-Match 请求头中。请求完成后，如果响应成功，客户端会从响应头中提取 ETag，并将其存储起来以备后续使用。
重要改进点： 在原始代码中，ETag的存储使用了 *req.URL 作为 map 的键。然而，Go的 http.Client 默认会跟随重定向。这意味着，如果一个请求 http://foo.com/bar.html 最终被重定向到 http://foo.com/qux.html 并返回 200 OK 及 ETag，那么这个ETag实际上是属于 qux.html 的。因此，正确的做法是使用 response.Request.URL 作为存储ETag的键，因为 response.Request.URL 包含了所有重定向之后最终请求的URL。上述代码已对这部分进行了修正。
ETag与HTTP重定向的关联
当客户端请求一个URL，而服务器以 3xx 状态码（如 302 Found）进行重定向时，ETag的关联和处理会变得复杂。
ETag与最终资源URL的关联： 假设客户端请求 http://foo.com/bar.html，服务器响应 302 Found 并将 Location 头指向 http://foo.com/qux.html。客户端（或Go http.Client 自动）会再次请求 http://foo.com/qux.html，最终得到 200 OK 响应，其中包含一个 ETag。 在这种情况下，这个 ETag 应该被关联到 最终响应的资源URL，即 http://foo.com/qux.html。因为ETag代表的是 qux.html 的特定版本。客户端在后续对 qux.html 的请求中，应该使用这个ETag。
重定向响应中是否包含ETag？ 理论上，一个 302 Found 响应可以包含 ETag 头。根据RFC 7232的定义，ETag与“当前请求的选定表示”（selected representation）相关联。对于 302 响应，其“选定表示”通常是一个包含超链接到不同URI的简短超文本说明。因此，如果 302 响应包含ETag，它指的是 该重定向消息本身的ETag，而不是最终目标资源的ETag。
重定向优先于条件请求：核心注意事项
这是理解ETag与重定向交互中最关键的一点。RFC 7232 第5节明确指出：
服务器必须忽略所有收到的前置条件（如 If-None-Match），如果其在没有这些条件的情况下对同一请求的响应将是除 2xx (成功) 或 412 (前置条件失败) 之外的状态码。换句话说，重定向和失败的响应优先于条件请求中前置条件的评估。
这意味着：
- 如果客户端发送 If-None-Match 请求到 http://foo.com/bar.html，而服务器决定以 302 Found 重定向响应，那么服务器会 忽略 客户端发送的 If-None-Match 头。它不会尝试根据ETag来判断是否返回 304 Not Modified，而是直接执行重定向。
- 因此，即使一个 302 响应中包含了ETag，这个ETag对于后续针对 重定向目标资源 的条件请求来说，也 没有实际用途。客户端不应该依赖 3xx 响应中的ETag来构建对目标资源的条件请求。
总结与实践建议
在HTTP ETag与重定向的场景中，开发者应注意以下几点：
- ETag的关联性： 始终将ETag与 最终成功响应（200 OK）的资源URL 相关联。Go语言客户端在存储ETag时，应使用 response.Request.URL 作为键，而非最初的请求URL。
- 重定向响应中的ETag： 尽管 3xx 响应可以包含ETag，但它通常指的是重定向消息本身的ETag，并且由于服务器对前置条件的评估规则，其对目标资源的条件请求 没有实际意义。
- 服务器行为： 服务器在决定重定向时，会忽略客户端发送的 If-None-Match 等前置条件。这意味着，客户端无法通过发送ETag来阻止重定向的发生。
- 客户端策略： Go语言的 http.Client 默认会自动处理重定向。客户端应专注于从最终的 200 OK 响应中提取和管理ETag，并将其用于对该最终URL的后续条件请求。
通过理解这些机制，开发者可以构建出更健壮、更高效的HTTP客户端，在处理ETag和重定向时避免常见的陷阱。
