Closed dougbu closed 1 year ago
/fyi @Tratcher, @stephentoub, @mkArtakMSFT, @javiercn, @MackinnonBuck, @wtgodbe
Note I already have a fix ready for this. It's not normally something we'd change in this repo (because I can't see a security angle). But HttpMessageContent
has received some attention lately and this came up as part of that work. I also confirmed things w/ a bunch of tests.
(You can tell the above came from unit testing by looking closely at the second stack trace in the description 😉)
As mentioned in hidden comments in #384 (because I changed the relevant lines slightly),
HttpMessageContent.ValidateStreamForReading(...)
usesCanRead
whereCanSeek
would be more appropriate. This causes problems when the innerHttpContent.ReadAsStreamAsync()
returns aStream
that is readable but not seekable.EmptyContent
provides such aStream
. Specifically, error messages are unintelligible.HttpContent
provides an unreadableStream
,HttpMessageContent.ValidateStreamForReading(...)
ignores the problem entirely. This allows execution to continue past where problems should have been detected.HttpContent
provides a readable but unseekableStream
,HttpMessageContent.ValidateStreamForReading(...)
again misses the issue and attempts to usestream.Position
instead of providing a useful message.