RQFR: multipart bug

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  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: RQFR: multipart bug

[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

Re: RQFR: multipart bug

[Bosko Milekic]

On Nov 11, 3:53 pm, Bosko Milekic <bosko.mile...@gmail.com> wrote:
> 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

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