From: Eric Wong <normalperson@yhbt.net>
To: rack-devel@googlegroups.com
Subject: Add readpartial to rack.input spec?
Date: Wed, 7 Oct 2009 01:34:58 -0700 [thread overview]
Message-ID: <20091007083458.GB20541@dcvr.yhbt.net> (raw)
Hi all,
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
reply other threads:[~2009-10-07 8:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://groups.google.com/group/rack-devel
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091007083458.GB20541@dcvr.yhbt.net \
--to=rack-devel@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).