[ANN] unicorn 0.93.2 - more compatible with Rails

[ANN] unicorn 0.93.2 - more compatible with Rails

[Eric Wong]

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.

* http://unicorn.bogomips.org/
* mongrel-unicorn@rubyforge.org
* git://git.bogomips.org/unicorn.git

Thanks to Chris Wanstrath 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.

A ticket has been opened here to track the issue:
  https://rails.lighthouseapp.com/projects/8994/tickets/3343

Also there are some minor documentation improvements.

Eric Wong (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
-- 
Eric Wong

Re: [ANN] unicorn 0.93.2 - more compatible with Rails

[Chris Wanstrath]

On Wed, Oct 7, 2009 at 1:58 AM, Eric Wong <normalperson@yhbt.net> wrote:

> 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.
>
> A ticket has been opened here to track the issue:
>  https://rails.lighthouseapp.com/projects/8994/tickets/3343

This release fixes the POST issue we saw. Thanks!

-- 
Chris Wanstrath
http://github.com/defunkt