-
Notifications
You must be signed in to change notification settings - Fork 59
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
Twirp::Service fails to rewind the rack.input #50
Comments
Thanks for the report! I understand this causes And this would be avoided if Twirp rewinds the request body after reading it: body_str = rack_request.body.read
rack_request.body.rewind # so downstream middleware can read again
input = Encoding.decode(body_str, env[:input_class], content_type) Do you know about any performance implications? Is this a common use case for Rack apps after reading a POST request body? |
Sorry it took so long to get back to this issue 😅 |
Believe me, I know how it goes. 😂 |
The Rack app attempts to route the request by reading in the POST body from
Rack::Request#body
and decoding it on this line: https://github.com/twitchtv/twirp-ruby/blob/c8520030b3e4eb584042b0a8db9ae606a3b6c6f4/lib/twirp/service.rb#L138Underneath the hood, this is invoking
IO#read
on therack.input
stream, which forwards the stream to its end. When downstream middleware attempt to re-read from the input stream, they won't get back any data. For exactly this reason, Rack apps that handle the input stream should generallyIO#rewind
it once they're done reading.Specifically, we saw this bug cause exceptions when the Honeycomb Rails middleware attempted to parse the HTTP parameters again. See:
The text was updated successfully, but these errors were encountered: