Unicorn is a HTTP server for Rack applications designed to take
advantage of features in Unix/Unix-like kernels and only serve fast
clients on low-latency, high-bandwidth connections. Slow clients should
only be served by placing a reverse proxy capable of fully-buffering
both the the request and response in between Unicorn and slow clients.
Thanks to Chris W. for reporting issues with large
POST bodies and for helping me test.
Changes:
Avoid truncated POST bodies with URL-encoded forms in Rails
by switching TeeInput to use read-in-full semantics (only) when
a Content-Length: header exists. Chunked request bodies
continue to exhibit readpartial semantics to support
simultaneous bidirectional chunking.
The lack of return value checking in Rails to protect against a
short ios.read(length) is entirely reasonable even if not
pedantically correct. Most ios.read(length) implementations
return the full amount requested except right before EOF.
Also there are some minor documentation improvements.
Eric W. (8):
Fix NEWS generation on single-paragraph tag messages
Include GPLv2 in docs
doc: make it clear contributors retain copyrights
TODO: removed Rainbows! (see rainbows.rubyforge.org)
Document the START_CTX hash contents
more-compatible TeeInput#read for POSTs with Content-Length
tests for read-in-full vs readpartial semantics
unicorn 0.93.2
Thanks to Chris W. for reporting issues with large
The lack of return value checking in Rails to protect against a
Fix NEWS generation on single-paragraph tag messages
Include GPLv2 in docs
doc: make it clear contributors retain copyrights
TODO: removed Rainbows! (see rainbows.rubyforge.org)
Document the START_CTX hash contents
more-compatible TeeInput#read for POSTs with Content-Length
tests for read-in-full vs readpartial semantics
unicorn 0.93.2
Eric W.
There was a pretty good blog entry on Unicorn recently:
Unicorn is a HTTP server for Rack applications designed to take
advantage of features in Unix/Unix-like kernels and only serve fast
clients on low-latency, high-bandwidth connections. Slow clients should
only be served by placing a reverse proxy capable of fully-buffering
both the the request and response in between Unicorn and slow clients.
There was a pretty good blog entry on Unicorn recently:
