Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Content-Length not passed to wrapped response in GZipFilter

Done. It is filed as https://bugs.eclipse.org/bugs/show_bug.cgi?id=354014

 

-mike

 

* | Mike Pilone | Software Architect, Distribution | mpilone@xxxxxxx | o: 202-513-2679  m: 703-969-7493

 

From: jetty-users-bounces@xxxxxxxxxxx [mailto:jetty-users-bounces@xxxxxxxxxxx] On Behalf Of Michael Gorovoy
Sent: Friday, August 05, 2011 10:50 AM
To: JETTY user mailing list
Subject: Re: [jetty-users] Content-Length not passed to wrapped response in GZipFilter

 

Mike, please open a ticket in Bugzilla (if using Jetty 7) or JIRA (if using Jetty 6). This sounds like a bug, and most likely needs to be fixed.

 

-Michael

 

On Fri, Aug 5, 2011 at 10:41 AM, Mike Pilone <MPilone@xxxxxxx> wrote:

I spent the last half a day trying to figure out why I was getting "Transfer-Encoding: chunked" in my responses from Jetty even though I was setting the Content-Length header. What I finally figured out is that there is a bug/strange interaction with the GZipFilter.

 

The GZipFilter wraps the response object and filters any addHeader calls. If the header is content-length, it stores the length but doesn't pass the header on to the real response. This is fine if the response is to be zipped, but when the content-type header is set, the gzip response wrapper properly determines that the response should not be zipped based on my mime type list. However it never passes on the content-length header to the original response. This causes the HttpGenerator to default to chunked encoding.

 

It looks like line GZipStream tries to be good about passing on the content-length header if there is data in the buffer and it is told not to gzip (around line 252). But if there is no gzip stream created, as is the case around line 299 of GzipResponseWrapper, the header is never passed on. It looks like the GzipStream should always be created but set to doNotGzip during mime-type filtering or the wrapper needs to be smarter about passing on the header when short-cutting the GzipStream.

 

Unfortunately I don't think I can use the GZipFilter until this is fixed because my client (Windows Media Player) won't buffer/live stream a response unless it gets a Content-Length header in the initial response. I don't see any good work around other than trying to limit the filter by pattern in my web.xml to avoid particular files.

 

-mike

 

* | Mike Pilone | Software Architect, Distribution | mpilone@xxxxxxx | o: 202-513-2679  m: 703-969-7493

 


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users

 


Back to the top