Add readpartial to rack.input spec?
Eric Wong
I just had to modify[1] the default TeeInput semantics of Unicorn to
work around (what I consider) a bug[2] in Rails request handling for
urlencoded forms.
And I'm willing to bet Rails isn't the only thing that doesn't check the
size of the return value for body.read(length) as Ruby's IO currently
always /seems/ to return the specified amount (except for the last block
before EOF). So I guess that's why Ruby has IO#readpartial
implemented...
So now for the majority of requests with a specified Content-Length,
TeeInput#read(length) will return length bytes. But for those rare
chunked bodies, TeeInput#read(length) will continue to behave like
IO#readpartial.
This may confuse some folks, but chunked request bodies are still rare,
maybe adding readpartial will be less confusing as chunked request
bodies become more common (I know some mobile devices send them,
especially for voice/video data).
In Unicorn, I kept the readpartial behavior for the chunked case because
some applications rely on bidirectional chunking. Both the client and
server can simultaneously send chunks back-and-forth and either side may
depend on the other before outputting more. With client support, this
allows any connection-based protocol to be tunneled through HTTP chunked
request/response bodies.
Of course Unicorn (and by extension, Rainbows![3]) are the only servers I
know with this bidirectional chunk streaming capability...
[1] http://git.bogomips.org/cgit/unicorn.git/commit/?id=438c99aec2d74489fa89b3a6c60d1fb41bb2f7e6
[2] https://rails.lighthouseapp.com/projects/8994/tickets/3343-ensure-raw_post-reads-all-of-the-specified-length#ticket-3343-1
[3] I expect to see this used from Rainbows! more since it can
do slow clients
--
Eric Wong