ASP.NET Core 问题排查：Request.EnableRewind 后第一次读取不到 Request.Body

实际应用场景是将用户上传的文件依次保存到阿里云 OSS 与腾讯云 COS ，实现方式是在启用 Request.EnableRewind() 的情况下通过 Request.Body 读取流，并依次通过 2 个 StreamContent 分别上传到阿里云 OSS 与 腾讯云 COS ，在集成测试中可以正常上传（用的是 TestServer 启动站点），而部署到服务器上通过浏览器上传却出现了奇怪的问题 —— 第一个 StreamContent 上传后的文件大小总是0，而第二个 StreamContent 上传正常。上传文件大小为 0 时，对应的 Request.Body.Length 也为 0 。（注：如果不使用 Request.EnableRewind ，Request.Body 只能被读取一次）

而如果在第一个 StreamContent 读取 Request.Body 之前先通过 MemoryStream 进行一次流的 Copy 操作，就能正常读取。

using (var ms = new MemoryStream())
{
    await Request.Body.CopyToAsync(ms);
}

好奇怪的问题！要牺牲第一个流，才能让后面的 StreamContent 从 Request.Body 中读到数据。 为什么会这样？

先从 Request.EnableRewind() 下手，通过它的实现源码知道了 EnableRewind 之后 Request.Body 被替换为 FileBufferingReadStream ，所以 StreamContent 实际读取的是 FileBufferingReadStream ，问题可能与 FileBufferingReadStream 有关。

public static HttpRequest EnableRewind(this HttpRequest request, int bufferThreshold = DefaultBufferThreshold, long? bufferLimit = null)
{
    //..
    var body = request.Body;
    if (!body.CanSeek)
    {
        var fileStream = new FileBufferingReadStream(body, bufferThreshold, bufferLimit, _getTempDirectory);
        request.Body = fileStream;
        request.HttpContext.Response.RegisterForDispose(fileStream);
    }
    return request;
}

向前进，查看 FileBufferingReadStream 的实现源码。

在构造函数中 _buffer 的长度被设置为 0 ：

if (memoryThreshold < _maxRentedBufferSize)
{
    _rentedBuffer = bytePool.Rent(memoryThreshold);
    _buffer = new MemoryStream(_rentedBuffer);
    _buffer.SetLength();
}
else
{
    _buffer = new MemoryStream();
}

FileBufferingReadStream 的长度实际就是 _buffer 的长度：

public override long Length
{
    get { return _buffer.Length; }
}

ReadAsync 读取流的代码（已移除不相关的代码）：

public override async Task<int> ReadAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
{
    ThrowIfDisposed();
    if (_buffer.Position < _buffer.Length || _completelyBuffered)
    {
        // Just read from the buffer
        return await _buffer.ReadAsync(buffer, offset, (int)Math.Min(count, _buffer.Length - _buffer.Position), cancellationToken);
    }

    int read = await _inner.ReadAsync(buffer, offset, count, cancellationToken);
    //...
    if (read > )
    {
        await _buffer.WriteAsync(buffer, offset, read, cancellationToken);
    }
    //...
    return read;
}

从 FileBufferingReadStream 的实现代码中没有发现问题。

只有 StreamContent 才会出现这个问题吗？写了个简单的 ASP.NET Core 程序验证了一下：

public async Task<IActionResult> Index()
{
    Request.EnableRewind();

    Request.Body.Seek(, );
    Console.WriteLine("First Read Request.Body");
    await Request.Body.CopyToAsync(Console.OpenStandardOutput());
    Console.WriteLine();

    Request.Body.Seek(, );
    Console.WriteLine("Second Read Request.Body");
    await Request.Body.CopyToAsync(Console.OpenStandardOutput());
    Console.WriteLine();

    Request.Body.Seek(, );
    using (var sr = new StreamReader(Request.Body))
    {
        return Ok(await sr.ReadToEndAsync());
    }
}

控制台输出流（System.ConsolePal+WindowsConsoleStream）没这个问题。

是 StreamContent 的问题吗？用下面的代码验证一下

public async Task<IActionResult> Index()
{
    Request.EnableRewind();
    var streamContent = new StreamContent(Request.Body);
    return Ok(await streamContent.ReadAsStringAsync());
}

奇怪了，StreamContnent 也没问题，只是剩下唯一的嫌疑对象 —— HttpClient 。

写测试代码进行验证，站点A的代码（监听于5000端口）

public async Task<IActionResult> Index()
{
    Request.EnableRewind();
    var streamContent = new StreamContent(Request.Body);
    var httpClient = new HttpClient();
    var response = await httpClient.PostAsync("http://localhost:5002", streamContent);
    return Ok(await response.Content.ReadAsStringAsync());
}

站点B的代码（监听于5002端口）

public async Task<IActionResult> Index()
{
    using (var ms = new MemoryStream())
    {
        await Request.Body.CopyToAsync(ms);
        return Ok(ms.Length);
    }
}

站点 A 启用 EnableRewind 并直接将 Request.Body 流 POST 到站点 B ，模拟实际应用场景。

测试得到的返回值是 0 ，问题重现了。

为了进一步验证是否是 HttpClient 的问题，将 HttpClient 改为 WebRequest 。

public async Task<IActionResult> Index()
{
    Request.EnableRewind();
    var request = WebRequest.CreateHttp("http://localhost:5002");
    request.Method = "POST";
    using (var requestStream = await request.GetRequestStreamAsync())
    {
        await Request.Body.CopyToAsync(requestStream);
    }
    using (var response = await request.GetResponseAsync())
    {
        using (var sr = new StreamReader(response.GetResponseStream()))
        {
            return Ok(await sr.ReadToEndAsync());
        }
    }
}

测试结果显示 WebRequest 没这个问题，果然与 HttpClient 有关。

向 HttpClient 的源代码进军。。。

从 HttpClient.SendAsync 到 HttpMessageInvoker.SendAsync 再到 HttpMessageHandler.SendAsync ，默认用的是 SocketsHttpHandler ，从 SocketsHttpHandler.SendAsync 到 HttpConnectionHandler.SendAsync 到 HttpConnectionPoolManager.SendAsync 。。。翻山越岭，长途跋涉，来到了 HttpConnection 的 SendAsyncCore 方法。

public async Task<HttpResponseMessage> SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
{
    //..
    await SendRequestContentAsync(request, CreateRequestContentStream(request), cancellationToken).ConfigureAwait(false);
    //...
}

原来是调用 SendRequestContentAsync 方法发送请求内容的

private async Task SendRequestContentAsync(HttpRequestMessage request, HttpContentWriteStream stream, CancellationToken cancellationToken)
{
    // Now that we're sending content, prohibit retries on this connection.
    _canRetry = false;

    // Copy all of the data to the server.
    await request.Content.CopyToAsync(stream, _transportContext, cancellationToken).ConfigureAwait(false);

    // Finish the content; with a chunked upload, this includes writing the terminating chunk.
    await stream.FinishAsync().ConfigureAwait(false);

    // Flush any content that might still be buffered.
    await FlushAsync().ConfigureAwait(false);
}

从 request.Content.CopyToAsync 追踪到 HttpConnection 的  WriteAsync 方法

private async Task WriteAsync(ReadOnlyMemory<byte> source)
{
    int remaining = _writeBuffer.Length - _writeOffset;

    if (source.Length <= remaining)
    {
        // Fits in current write buffer.  Just copy and return.
        WriteToBuffer(source);
        return;
    }

    if (_writeOffset != )
    {
        // Fit what we can in the current write buffer and flush it.
        WriteToBuffer(source.Slice(, remaining));
        source = source.Slice(remaining);
        await FlushAsync().ConfigureAwait(false);
    }

    if (source.Length >= _writeBuffer.Length)
    {
        // Large write.  No sense buffering this.  Write directly to stream.
        await WriteToStreamAsync(source).ConfigureAwait(false);
    }
    else
    {
        // Copy remainder into buffer
        WriteToBuffer(source);
    }
}

看这部分代码实在毫无头绪，于是采用笨方法——手工打点在控制台显示信息，在 WriteToStreamAsync 进行打点

private ValueTask WriteToStreamAsync(ReadOnlyMemory<byte> source)
{
    if (NetEventSource.IsEnabled) Trace($"Writing {source.Length} bytes.");
    Console.WriteLine($"{_stream} Writing {source.Length} bytes.");
    Console.WriteLine("source text: " + System.Text.Encoding.Default.GetString(source.ToArray()));
    return _stream.WriteAsync(source);
}

编译 System.Net.Http 解决方案，将编译输出的 corefx\bin\Windows_NT.AnyCPU.Debug\System.Net.Http\netcoreapp\System.Net.Http.dll 复制到 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.1.2 文件夹中，然后就可以使用自己编译的 System.Net.Http.dll 运行 ASP.NET Core 程序。

运行测试站点（见之前的站点A与站点B的代码，站点 A 将 Request.Body 流中的内容通过 HttpClient POST 到站点 B ），站点 A 的控制台显示了下面的打点信息：

System.Net.Sockets.NetworkStream Writing 10 bytes.
source text: POST / HTT
System.Net.Sockets.NetworkStream Writing 10 bytes.
source text: P/1.1
Con
System.Net.Sockets.NetworkStream Writing 10 bytes.
source text: tent-Lengt
System.Net.Sockets.NetworkStream Writing 10 bytes.
source text: h: 0
Host
System.Net.Sockets.NetworkStream Writing 10 bytes.
source text: : localhos
_writeBuffer.Length: 10
_writeOffset: 10
remaining: 0
source.Length: 4
System.Net.Sockets.NetworkStream Writing 10 bytes.
source text: t:5002

System.Net.Sockets.NetworkStream Writing 4 bytes.
source text: test

将上面的 source text 内容连接起来，到下面的 http 请求内容：

POST / HTTP/1.1
Content-Length: 0
Host: localhost:5002

test

立马就发现了问题：Content-Length: 0 ，原来是 Content-Length 惹的祸，怎么会是 0 ？

继续打点。。。

找到了 "Content-Length: 0" 是  StreamContent 中的 TryComputeLength 方法引起的

protected internal override bool TryComputeLength(out long length)
{
    if (_content.CanSeek)
    {
        length = _content.Length - _start;
        return true;
    }
    else
    {
        length = ;
        return false;
    }
}

上面的代码中 _content.Length 的值为 0 （在博文的开头我们提到过 FileBufferingReadStream 在未被读取时 Length 的值为 0 ），于是 length 为 0 并返回 true ，所以生成了 "Content-Length: 0" 请求头。

如果当 length 为 0 时，让 TryComputeLength 返回 false ，这样就不会生成 "Content-Length: 0" 请求头，是不是可以解决问题呢？

protected internal override bool TryComputeLength(out long length)
{
    if (_content.CanSeek)
    {
        length = _content.Length - _start;
        return length > ;
    }
    else
    {
        length = ;
        return false;
    }
}

这样会产生下面的请求内容：

POST / HTTP/1.1
Transfer-Encoding: chunked
Host: localhost:5002

4
test
0

这样的请求内容在示例程序服务端就可以正常读取到 Request.Body ，但是无法将文件上传到阿里云 OSS 与腾讯云 COS ，应该是 "Transfer-Encoding: chunked" 请求头的原因。

后来改为从 HttpAbstractions 下手，修改了 BufferingHelper.cs 与 FileBufferingReadStream.cs 的代码，终于解决了这个问题。

给 FileBufferingReadStream.cs 添加一个私有字段 _innerLength ，在 Request.EnableRewind 时通过构造函数将 Request.ContentLength 的值传给 _innerLength 。

var fileStream = new FileBufferingReadStream(body, request.ContentLength, bufferThreshold, bufferLimit, _getTempDirectory);

在 FileBufferingReadStream 的 Length 属性中，如果流还没被读取过，就返回 _innerLength 的值。

public override long Length
{
    get
    {
        var useInnerLength = _innerLength.HasValue && _innerLength >
            && !_completelyBuffered && _buffer.Position == ;
        return useInnerLength ?_innerLength.Value : _buffer.Length;
    }
}

修改 HttpAbstractions 的源代码后，需要将编译生成的下面5个文件都复制到 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.1.2 文件夹中。

Microsoft.AspNetCore.Http.Abstractions.dll
Microsoft.AspNetCore.Http.dll
Microsoft.AspNetCore.Http.Features.dll
Microsoft.Net.Http.Headers.dll
Microsoft.AspNetCore.WebUtilities.dll

如果用的是 Linux ，需要复制到 /usr/share/dotnet/shared/Microsoft.AspNetCore.App/2.1.2/ 目录中。

后来发现基于 request.ContentLength 的解决方法不适用于 chunked requests ，将 CanSeek 属性改为下面的实现（原先是直接返回true）

public override bool CanSeek
{
    get { return Length > ; }
}

这样第一读 Request.Body 正常，但之后继续读会出现下面的错误：

System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'FileBufferingReadStream'.
   at WebsiteA.FileBufferingReadStream.ThrowIfDisposed()