本文深入探讨了http etag与重定向（如302 found）之间的复杂交互。我们将通过一个go语言实现的自定义http客户端示例，分析etag在条件请求和缓存管理中的作用。重点阐述了当请求遇到重定向时，etag应与哪个url关联，以及http规范中关于服务器如何处理重定向与条件请求优先级的重要规则，揭示了重定向响应中etag的实际效用。
HTTP ETag与条件请求概述
HTTP ETag（实体标签）是HTTP协议中用于缓存验证和条件请求的强大机制。它是一个服务器生成的、表示资源特定版本的字符串标识符。当客户端首次请求资源并收到ETag后，可以在后续请求中通过If-None-Match请求头将该ETag发送回服务器。如果服务器上资源的当前ETag与客户端提供的ETag匹配，则服务器可以返回304 Not Modified状态码，指示客户端使用其本地缓存的副本，从而节省带宽和服务器处理能力。
Go语言中的Etag客户端实现示例
为了更好地管理ETag，我们可以构建一个自定义的HTTP客户端。以下是一个Go语言实现的示例，它扩展了Go标准库的http.Client，增加了自动处理If-None-Match和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 方法拦截并增强了原始的http.Client.Do方法
func (hc *HttpClient) Do(req *http.Request) (*http.Response, error) {
const ETAG_SERVER_HEADER = "ETag"
const ETAG_CLIENT_HEADER = "If-None-Match"
// 仅对GET请求处理ETag，因为ETag主要用于缓存验证
if req.Method != "GET" {
return hc.Client.Do(req)
}
// 检查是否存在当前URL的ETag
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，如果存在则存储
etag = response.Header.Get(ETAG_SERVER_HEADER)
if len(etag) != 0 {
// 将接收到的ETag与当前请求的URL关联
hc.etags[*req.URL] = etag
}
}
return response, err
}这个HttpClient通过维护一个map[url.URL]string来存储每个URL对应的ETag。在发起GET请求前，它会检查是否有该URL的ETag，并将其作为If-None-Match头发送。请求完成后，如果响应包含ETag头，它会更新内部的ETag映射。
ETag与HTTP重定向的关联挑战
在上述客户端实现中，一个核心问题是当请求遇到重定向时，ETag应该与哪个URL关联。例如，如果客户端请求http://foo.com/bar.html，服务器响应302 Found并指定Location: http://foo.com/qux.html。客户端随后请求http://foo.com/qux.html并获得200 OK及一个ETag头。此时，这个ETag应该与http://foo.com/bar.html关联，还是与http://foo.com/qux.html关联？
ETag与重定向响应的语义
根据HTTP规范（RFC 7232），一个ETag是与当前请求的“选定表示”（selected representation）相关联的。对于302 Found这样的重定向响应（RFC 7231），其响应体通常包含一个简短的超文本说明，指向新的URI。因此，如果一个302响应包含了ETag，这个ETag是与该重定向响应体中的超文本相关联的，而不是与最终重定向到的资源。
这意味着，即使服务器在302响应中发送了ETag，它通常也不是为了标识最终目标资源，而是标识重定向本身所返回的那个临时文档。
条件请求与重定向的优先级规则
更重要的是，HTTP规范对服务器处理条件请求（如带有If-None-Match的请求）与重定向响应之间的优先级有明确规定。根据RFC 7232的第5节，服务器在以下情况下必须忽略所有收到的条件请求头：
服务器必须忽略所有收到的条件请求头，如果其在没有这些条件的情况下对相同请求的响应状态码不是2xx (成功) 或 412 (前置条件失败)。 换句话说，重定向和失败状态码优先于条件请求的评估。
这意味着：
- 如果客户端发送一个带有If-None-Match头的请求到http://foo.com/bar.html。
- 服务器判断该请求应该返回一个重定向（例如302 Found）。
- 在这种情况下，服务器会忽略客户端发送的If-None-Match头。它不会尝试验证ETag来决定是否返回304 Not Modified，而是直接返回重定向响应。
因此，即使一个302响应能够包含ETag，客户端将其存储并尝试在后续对原始URL的请求中使用If-None-Match头，其效果也是有限的。因为只要服务器仍然决定重定向，它就会忽略这个If-None-Match头。
实践建议与总结
基于上述分析，对于ETag与重定向的交互，我们得出以下结论和实践建议：
- ETag与最终URL关联：当客户端请求一个URL并最终通过重定向链条获得一个200 OK响应时，该200 OK响应中包含的ETag应该与最终成功获取资源的URL（即重定向链条的终点）关联。在上述Go语言客户端示例中，hc.etags[*req.URL] = etag这行代码，在Go标准库的http.Client自动处理重定向后，req.URL通常会是最终重定向到的URL，因此其行为是正确的。
- 重定向响应中的ETag作用有限：即使重定向响应（如302 Found）包含了ETag，这个ETag也是针对重定向本身所返回的临时内容，而不是最终目标资源。更重要的是，服务器在发出重定向时会忽略客户端的条件请求头（如If-None-Match），这使得从重定向响应中获取ETag并尝试用于后续对原始URL的条件请求变得没有实际意义。
- 客户端应遵循重定向：当客户端收到重定向响应时，其主要任务是遵循Location头指向的新URI，发起新的请求。ETag的管理应集中在最终获取到200 OK响应的资源上。
总之，在处理HTTP ETag和重定向时，应将ETag视为与特定资源版本紧密绑定的标识符。当发生重定向时，客户端的核心任务是追踪到最终资源，并将其ETag与该最终资源的URL进行关联，而非试图从重定向响应中提取并利用ETag进行条件请求。
