PSGI Plugin: psgix.input.buffered should *not* be set to whatever post_b... #211
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.
...uffering is set to
The psgix.input.buffered variable doesn't just mean "hey, I happen to
be buffering things internally in case you were interested". From the
PSGI spec:
While uWSGI technically complies with that with this stub method:
It doesn't actually sync, this means that the first thing that reads
psgi.input via uwsgi::input will get content, but everything else
doesn't. This plays very badly with
Plack::Request::_parse_request_body() which does:
And later:
So $buffer never ends up being true if psgix.input.buffered=1, so
Plack::Request doesn't save away what it just read (since it assumes
it can get it back!), so later calling e.g. Plack::Request::raw_body()
does:
And gets nothing! All of this fail is avoided if we just set
psgix.input.buffered=0 which'll cause Plack itself to buffer things up
via Stream::Buffered. In the future this could be set to true if uWSGI
actually implements the interface psgix.input.buffered requires.