为支持Digest auth-int，如何从HttpURLConnection提取请求实体体？

好问题！我之前在实现Digest认证的auth-int扩展时也踩过类似的坑，HttpURLConnection确实没有直接暴露完整请求或原始实体体的API，但咱们可以通过主动缓存请求体的方式完美解决这个问题，下面是两种可靠的实现思路：

1. 直接缓存手动构造的请求体（最简单的方案） #

如果你的库是自己构造请求体字节数组后写入输出流，那最直接的方式就是在发送前先缓存一份副本：

// 假设你已经构造好了请求体字节数组
byte[] requestBody = buildYourRequestBody();

// 获取连接的输出流
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
OutputStream out = conn.getOutputStream();

// 先缓存请求体，再发送
byte[] cachedBody = Arrays.copyOf(requestBody, requestBody.length);
out.write(requestBody);
out.flush();

// 后续计算auth-int的A2哈希时，直接用cachedBody即可
String entityHash = calculateHash(cachedBody, conn.getRequestProperty("Content-Encoding"));
String a2 = conn.getRequestMethod() + ":" + conn.getURL().getPath() + ":" + entityHash;

这个方案完全避开了HttpURLConnection的内部处理逻辑，你能100%控制请求体的原始内容，不会出现头顺序或内容不一致的问题，是最推荐的方式。

2. 用代理OutputStream自动缓存请求体（适合动态写入场景） #

如果请求体不是一次性构造的，而是通过多次写入输出流生成的（比如上传文件时的分段写入），可以自定义一个代理OutputStream来自动记录所有写入的内容：

public class CachingOutputStream extends OutputStream {
    private final OutputStream delegate;
    private final ByteArrayOutputStream cacheStream;

    public CachingOutputStream(OutputStream delegate) {
        this.delegate = delegate;
        this.cacheStream = new ByteArrayOutputStream();
    }

    @Override
    public void write(int b) throws IOException {
        delegate.write(b);
        cacheStream.write(b);
    }

    @Override
    public void write(byte[] b) throws IOException {
        delegate.write(b);
        cacheStream.write(b);
    }

    @Override
    public void write(byte[] b, int off, int len) throws IOException {
        delegate.write(b, off, len);
        cacheStream.write(b, off, len);
    }

    // 获取缓存的完整实体体字节数组
    public byte[] getCachedRequestBody() {
        return cacheStream.toByteArray();
    }

    @Override
    public void flush() throws IOException {
        delegate.flush();
    }

    @Override
    public void close() throws IOException {
        delegate.close();
        cacheStream.close();
    }
}

然后在你的库中包装HttpURLConnection的输出流：

HttpURLConnection conn = (HttpURLConnection) url.openConnection();
// 替换原始输出流为缓存版
CachingOutputStream cachingOut = new CachingOutputStream(conn.getOutputStream());

// 正常写入请求体（比如分段写入文件内容）
writeRequestContentToStream(cachingOut);
cachingOut.flush();

// 获取缓存的实体体
byte[] cachedBody = cachingOut.getCachedRequestBody();
// 后续计算A2哈希即可

为什么不能直接从HttpURLConnection获取完整请求？ #

HttpURLConnection是一个高层封装API，它的设计目标是隐藏底层HTTP通信的细节：

• 请求体一旦写入输出流并发送，数据就会被传输到服务器，不会在内存中保留副本；
• 它也不会记录请求头的原始顺序，而部分严格的服务器会依赖头顺序计算Digest哈希，这就是你担心的401错误的根源。

所以主动缓存请求体是唯一可靠的方式，既能保证内容的原始性，又能完全控制哈希计算的输入。

最后补充下auth-int的A2计算规则（来自RFC 7616第3.4.3节）：

A2 = Method ":" digest-uri ":" H(entity-body)

这里的H(entity-body)是用请求指定的摘要算法（比如MD5）对原始实体体计算的哈希值，用缓存的实体体直接计算即可。

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