-
Notifications
You must be signed in to change notification settings - Fork 351
MessageHttpContext
does not handle unreadable/unseekable Stream
s well
#389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
/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 (You can tell the above came from unit testing by looking closely at the second stack trace in the description 😉) |
- fix aspnet#389 - check `Stream` before first read attempt - check `CanRead` (not `CanSeek`) before second or later read attempts - add lots of tests of related scenarios - nit: correct a recent `HttpContentMessageExtensions` comment
- fix aspnet#389 - check `Stream` before first read attempt - check `CanRead` (not `CanSeek`) before second or later read attempts - add lots of tests of related scenarios - nit: correct a recent `HttpContentMessageExtensions` comment
- fix aspnet#389 - check `Stream` before first read attempt - check `CanRead` (not `CanSeek`) before second or later read attempts - add lots of tests of related scenarios - nit: correct a recent `HttpContentMessageExtensions` comment
- fix #389 - check `Stream` before first read attempt - check `CanRead` (not `CanSeek`) before second or later read attempts - add lots of tests of related scenarios - nit: correct a recent `HttpContentMessageExtensions` comment Apply suggestions from code review - specifically, correct an `HttpMessageContent` comment Co-authored-by: Chris Ross <Tratcher@Outlook.com>
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.The text was updated successfully, but these errors were encountered: