SocketsHttpHandler (and WinHttpHandler) do not enforce response Content-Length correctness

[antonfirsov]

Discovered during #62870, similar to #62258:

In HTTP 2.0, a response payload body size that mismatches Content-Length is protocol violation, and should result in RST_STREAM according to the RFC:
https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.6
https://datatracker.ietf.org/doc/html/rfc7540#section-5.4.2

WinHttpHandler doesn't respect this either. Current behavior:

• SocketsHttpHandler:
  • HTTP 1.1: reads Content-Length bytes, no error
  • HTTP 2.0: reads the entire content, no error
• WinHttpHandler
  • HTTP2 before WinHttp: always read HTTP/2 streams to the end #62870: reads Content-Length bytes, no error
  • HTTP2 after WinHttp: always read HTTP/2 streams to the end #62870: reads all the bytes
  • HTTP11: reads Content-Length bytes, no error

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Discovered during #62870, similar to #62258:

A response payload body size that mismatches Content-Length is protocol violation, and should result in RST_STREAM according to the RFC:
https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.6
https://datatracker.ietf.org/doc/html/rfc7540#section-5.4.2

WinHttpHandler doesn't respect this either. Current behavior:

• SocketsHttpHandler:
  • HTTP 1.1: reads Content-Length bytes, no error
  • HTTP 2.0: reads the entire content, no error
• WinHttpHandler
  • HTTP2 before WinHttp: always read HTTP/2 streams to the end #62870: reads Content-Length bytes, no error
  • HTTP2 after WinHttp: always read HTTP/2 streams to the end #62870: reads all the bytes
  • HTTP11: reads Content-Length bytes, no error

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[karelz]

Triage:

• For HTTP 1.1 we should check both Content-Length mode only and chunked encoding (with Content-Length)
  • We should check spec correctness for chunked encoding with Content-Length -- see RFC
• It is ok to respect RFC and behave differently from WinHttp
• HTTP/2 we should follow spec and send RST_STREAM

Notes:

• We should decide in 7.0 what we want to change and perhaps then decide to punt it to Future.

[scalablecory]

There are three modes of operation to look at here:

• HTTP/1 - Content-Length, unchunked.
  • Note user is only sending us a single Content-Length here.
  • If server sends too little, we will hang with timeout.
  • If server sends too much, we will close connection via the read-ahead task OR throw a parse error when reading next response.
• HTTP/1 - Content-Length, chunked.
  • Now server is sending us two content lengths: one in Content-Length header and one that is the total number of bytes received via chunked encoding.
  • Spec says we can either handle it or treat it as an error, and that if we handle it, we should use the total chunked encoding bytes received and ignore the Content-Length header.
    • If we did choose to handle it, we need to make a choice of altering Content-Length header returned to caller, or if that inconsistency should be kept there for the caller to handle. It sounds like current behavior today is the latter.
• HTTP/2
  • This also has two content lengths: one in Content-Length header and one that is the total number of bytes received via DATA frames.
  • Spec says we should treat as error and RST_STREAM.

[MihaZupan]

For the HTTP/1 case of receiving both, my understanding is that we should handle it as chunk-encoded, whereas currently, we treat it as Content-Length.
This also changes what data the user will read from the content stream - we should be decoding chunked encoding framing.

[JamesNK]

Please also check HTTP/3 when you do this work. It should be similar to HTTP/2. Hopefully, the only difference in behavior is the error code.

[karelz]

Triage: No customer report. Not a regression, moving to Future.