|Re: [jetty-users] Null HttpChannel.getCurrentHttpChannel() in ServletHandler.doFilter()|
On Thu, Oct 23, 2014 at 8:29 PM, Matt Deimel <mdeimel@xxxxxxxxx> wrote:
> Thanks for taking a look at this - I've updated the README for the project
> with a "How to build" section, and also tweaked the pom.xml file, so please
> download a fresh version of the repo. I used gradle 1.10 for building, I
> imagine 1.7 would work too, but I haven't tested (I included this detail in
> the added section to the README). Following these steps on a fresh Ubuntu
> install (virtualbox) I was able to get it running, please let me know if you
> encounter any issues.
Nope all good, thank you for updating the instructions.
So I fixed the issue, so that the NPE is now gone.
However, the "proxy" test is probably broken, but I'd like your comments on it.
What happens with the "proxy" test is that the browser performs a
request with Accept-Encoding: gzip, deflate.
The proxy will forward this header to the server, and when the
response comes back it is actually gzipped and with Content-Encoding:
Then Sitemesh adds the header and the footer, but uncompressed, so
that now the content has Content-Encoding: gzip but its bytes are:
<title>Sitemesh3 Jetty 9 Async Attempt</title>
<link rel="stylesheet" href="">
Sitemesh styled content: (adding yellow background color to the
body tag)</p> <br>
<bunch of gzipped bytes>
When this arrives to the browser, it chokes thinking it's gzip but it's not.
I think this is more a problem of the test / use case / sitemesh, not
sure exactly where :)
But I think now Jetty behaves correctly.
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top