RQFR: multipart bug

[Christian Neukirchen]

> Introduce failing test case for multipart parser when it slices
> exactly on a boundary and patch multipart parser so it passes it -
> the failing test case comes with a sample payload specific to the
> fact that the default bufsize used by the multipart parser is
> exactly 16384. should this default be changed, the test will no
> longer apply.

http://github.com/bloom/rack/commit/8f4bfced74e7a07d0f0f47705b763c7efc2f2aa7

--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org

[Bosko Milekic]

On Nov 6, 1:01 pm, Christian Neukirchen <chneukirc...@gmail.com>
wrote:

> > Introduce failing test case for multipart parser when it slices
> > exactly on a boundary and patch multipart parser so it passes it -
> > the failing test case comes with a sample payload specific to the
> > fact that the default bufsize used by the multipart parser is
> > exactly 16384.  should this default be changed, the test will no
> > longer apply.
>

> http://github.com/bloom/rack/commit/8f4bfced74e7a07d0f0f47705b763c7ef...

Obviously I'll +1 here, but I'm clearly biased. :-)

In all honesty, though, I think the "correct" thing to do is rewrite
the multi-parser method, which is really non obvious and not exactly
what one would call idiomatic ruby, but since this is much easier said
than done, I'm all for patching the edge case. Took a while to
isolate this, especially since only Safari was sending payloads that
happened to, in very specific and isolated cases, fall exactly on the
end of the boundary at the 16384 byte offset.

Best,
Bosko

[Bosko Milekic]

FWIW:
Feel free to pull bloom/rack. gdi contributed a cleaner fix and tests
and we've been running this in production for a month now.

Best,
Bosko