如何在Lambda@Edge中哈希请求URI生成自定义ETag

完全可以在Lambda@Edge函数内部不依赖任何第三方Node模块实现动态ETag生成，一次部署后不需要额外维护，完全适配自定义源站场景。

核心实现逻辑 #

你当前的测试代码是直接构造固定响应返回，生产环境需要将Lambda触发器绑定到**源站响应（Origin Response）**事件：这个触发时机是CloudFront接收到自定义源站返回的内容后、将内容写入缓存并返回给用户前执行，你可以同时拿到请求元数据、源站返回的完整响应元数据/小尺寸响应体，刚好满足ETag生成的所有数据需求。

不需要引入第三方包：Lambda@Edge支持的所有Node.js runtime（16.x/18.x/20.x）都内置了原生crypto加密模块，可以直接用来做哈希运算，不需要额外npm安装。

ETag生成的哈希输入需要覆盖两类信息，避免内容更新后ETag不失效：

• 请求维度：请求URI、排序后的查询字符串（避免查询参数顺序不同导致同内容生成不同ETag）
• 响应维度：优先使用源站返回的实际响应体内容做哈希（最准确，内容变ETag必变）；如果响应体超过Lambda@Edge源站响应事件的40KB读取上限，就改用源站返回的Last-Modified、Content-Length响应头值做哈希，这两个字段组合可以覆盖99%以上的内容版本标识场景，不会出现误判。

可直接部署的代码实现 #

const crypto = require('crypto');

exports.handler = async (event, context) => {
    const { request, response } = event.Records[0].cf;
    const hash = crypto.createHash('sha256');

    // 写入请求维度特征
    hash.update(request.uri);
    // 处理查询字符串，按参数名排序后写入哈希，避免参数顺序干扰
    if (request.querystring) {
        const sortedQuery = Object.entries(
            Object.fromEntries(new URLSearchParams(request.querystring))
        ).sort(([a], [b]) => a.localeCompare(b)).toString();
        hash.update(sortedQuery);
    }

    // 写入响应维度特征
    const headers = response.headers;
    // 优先用响应体做哈希（仅当响应体可读取时，即大小≤40KB）
    if (response.body && response.body.data) {
        hash.update(response.body.data);
        if (response.body.encoding) {
            hash.update(response.body.encoding);
        }
    } else {
        // 大文件场景用源站返回的元数据做哈希
        if (headers['last-modified']?.[0]?.value) {
            hash.update(headers['last-modified'][0].value);
        }
        if (headers['content-length']?.[0]?.value) {
            hash.update(headers['content-length'][0].value);
        }
        if (headers['content-type']?.[0]?.value) {
            hash.update(headers['content-type'][0].value);
        }
    }

    // 生成符合规范的ETag值，截短到合理长度避免头过长
    const etagValue = `"${hash.digest('base64url').slice(0, 27)}"`;
    // 注入ETag头，覆盖源站可能返回的空值/错误值
    response.headers['etag'] = [{
        key: 'ETag',
        value: etagValue
    }];

    return response;
};

注意事项 #

• 不要把触发器绑定到查看器请求/查看器响应事件：查看器端触发时如果命中CloudFront缓存，你拿不到源站的实际内容，会导致ETag和实际缓存内容不匹配。
• 不需要额外写304协商缓存逻辑：只要你正确注入ETag头，CloudFront会自动将ETag和缓存内容关联，后续请求带If-None-Match头时会自动返回304响应，不需要额外代码处理。
• 上述逻辑完全不依赖S3特有元数据，无论你的自定义源站是自建服务器、EC2、其他云厂商的存储服务都可以正常运行。
• 生成ETag时保留了标准要求的双引号包裹格式，不会出现浏览器/客户端不识别的问题。

内容的提问来源于stack exchange，提问作者Reploid