Re: [Winstone-devel] Possible bug with filter/wrapped response and output/forwards

[Grégory J. <gre...@gm...>]

Hi,

If the attachments are allowed on this list, you should find attached
a zip that shows the issue. Attempting to access
/f/something-that-ends-in-x will forward to /f/chalala and yield no
output, while it should. (?)

Commenting out lines 339-341 in Winstone's RequestDispatcher class
(the "if (outsideFilter)" block) fixed/hid the issue for me, and
apparently does not cause any test to fail, but I don't suppose that
code was there for no reason.

Cheers,

-greg

2009/4/9 Grégory Joseph <gre...@gm...>:
> Hi list (and spammers...),
>
> I've just starting using Winstone; Rick's latest email on this list
> isn't exactly encouraging, but I'm still hoping someone's around and
> possibly willing to help/fix a potential bug I uncovered while trying
> to deploy Magnolia on Winstone. (0.9.10)
>
> I am currently trying to isolate it in a minimal webapp, but in short,
> it seems to happen when a filter wraps the response and output,
> forwards .. to a url mapped to the same filter.. which wraps it again,
> then writes something in the wrapped response -- the response somehow
> got committed to early, so the 2nd execution of the filter can't add
> headers, and no content is sent to the browser.
>
> As anyone seem something similar ?
>
> Background: in Magnolia, we map all requests and forwards to a single
> filter, which manages its own filter chain internally (so they can be
> plugged in/out without touching the app descriptor). What happens here
> is that we have a GZipFilter, which wraps the output, buffers it, and
> attempts to send the gzip'd output to the client once the chain calls
> have returned; and one of the filter further down the chain does a
> forward. The forwarded request passes again in the gzip'd filter, then
> content is pushed by yet another filter, but upon returning to the
> gzipfilter, eventhough it *sees* the content from the wrapped
> response, somehow it can't be sent to the browser. (and gzip headers
> can't either because the response was committed at some point).
>
> This works nicely in other containers, but it could still be we've
> messed something up. I currently have a minimal webapp that reproduces
> the "issue" outside the context of Magnolia, and I'm trying to reduce
> it as much as possible to try and pinpoint the issue. Is anyone
> willing to take a go at it? Should I attach it here, send it to
> Rick... and/or open a bug report, I suppose...
>
> Cheers, and thanks for any hint or even sign of life ;)
>
> -greg
>