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 [cid:[email protected]] | Mike Pilone | Software Architect, Distribution | [email protected]<mailto:[email protected]> | o: 202-513-2679 m: 703-969-7493
<<inline: image001.jpg>>
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
