implement HttpContentReadStream.Position getter #31000
Labels
area-System.Net.Http
enhancement
Product code improvement that does NOT require public API changes/additions
Milestone
There are some scenarios where knowing the number of bytes downloaded from an HttpClient response stream would be useful. For example, showing progress during a large download, or reporting on how many bytes were transferred after the response stream is processed, when
HttpResposeMessage.Content.Headers.ContentLength
is not available and a buffered stream of the entire response was not used. I'm fine with this not working with the WinHttpHandler, but working in both the HTTP 1.x SocketsHttpHandler and the HTTP2 handler would be useful.I think complexities from HTTP keepalive, pipelineing and HTTP2 streams are out of scope. I think this code snippet explains why better than I can describe with words:
I care about the position of the individual response stream. The total number of bytes received since the TCP connection was opened is not important to me (and if needed should be obtained though something other than the HTTP response's content stream).
HttpBaseStream
currently throws aNotSupportedException
. I do have a workaround, which is to use my own stream wrapper, something similar to:This is what I'd like
HttpConentReadStream
to implement. While this is a simple workaround and therefore it's tempting to keep it out of the BCL, the problem is that whenAutomaticDecompression
is used, it measures a different number of bytes that may be relevant, depending on what the app author wants to measure.SocketsHttpHandler already has code to use the correct decompression algorithm based on content encoding, but it's in a private class, so I can't call it from my own code, meaning if a new compression type becomes available, I'd have to update my code. Perhaps if the code that uses the right decompression based on
AutomaticDecompression
settings and content-encoding, if that is made public, then it would be an alternative to my proposal as it would be possible to use my own byte-counting stream wrapper while also being forwards-compatible with new compressions types being added to HTTP responses in the future.Here's a simple example of what I'd like to be able to do:
The text was updated successfully, but these errors were encountered: