-
-
Notifications
You must be signed in to change notification settings - Fork 145
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
Support buffering requests with unknown length (Transfer-Encoding: chunked) in RequestBodyBufferMiddleware #235
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this check be moved up as this type of stream won't be buffered anyway? Why complain about size in this case (shouldn't happen when using the server at all, might as well just throw)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO it makes sense to keep this like this in (the rare) case this middleware is used behind another buffering middleware handler, see also #235 (comment) 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@clue What I mean is that- if not a
ReadableStreamInterface
, which means we won't buffer it, we're still returning 413 although the middleware is not responsible for handling this request as it is right now.My suggestion would be to move the
ReadableStreamInterface
to the Beginning of the method?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ping @clue could you check my question above?
What's missing to make make progress with this PR (and 0.8 in general)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, technically buffering and limiting sizes are in fact independent responsibilities. For practical reasons however, I think that it makes sense to bring them close together because buffering without applying a limit is actually harmful (potential for trivial DOS otherwise). If we accept the fact that checking size limits here, then I think it makes sense to also support buffered requests here. This means that I think it makes sense to also reject buffered requests that exceed the given size limits.
Accordingly, I think this code LGTM 👍 What do you think about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@clue scratch head. I'm not getting my point across. We're only buffering and limiting PSR streams. We are however still limiting react-only streams.
This is imho wrong- as the buffering middleware is not responsible for these requests. I'm proposing- to be explicit- to change order of things like this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it looks like we're talking past one another 🤷♂️ :-)
The
getBody()
method is guaranteed to always return an instance ofPsr\Message\StreamInterface
. This very instance may also implement theReact\Stream\ReadableStreamInterface
("streaming state"), but this is not guaranteed (already in "buffered state").When this middleware handler is used as documented, then the body is always in a "streaming state". If one were to use this middleware handler twice in the same stack (conceived example), then the first will see a body in "streaming state" while the second will see it in "buffered state".
If this conceived(!) second middleware handler uses a smaller size limit (which I would expect to be more of a programming error than intentional), then IMO the second middleware handler should still reject the message in my opinion.
If I understand your above suggestion correctly, then it looks like this would actually allow the body to pass through without applying the second limit at all.
I think it makes sense to add a test for this behavior to ensure that this is properly covered. Can you add a test for this or would you rather want me to add this to this PR? 👍