[#CACHE-155] Support of GZip filters in the filter chain

OSCache

Support of GZip filters in the filter chain

Created: 21/Mar/05 03:44 PM Updated: 06/Nov/05 11:19 AM

Component/s:

Filters

Affects Version/s:

2.1

Fix Version/s:

2.2 RC

Issue Links:

Related

This issue is related to:

CACHE-49 Add Http1.1 Compression (GZip) and increase efficiency

Description

« Hide

OSCache should support GZip compression filters in the filter chain.

To have the cache filter be aware of the potential existence of gzip filters down the filter chain and behave appropriately in those cases the attachments of CACHE-49 were added here.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Lars Torunski added a comment - 21/Mar/05 04:30 PM

Sources from Fernando Martins were modified and added to the CVS.

[ Permlink | « Hide ]

Lars Torunski added a comment - 21/Mar/05 04:33 PM

The sources from Fernando Martins were moved to ~~CACHE-155~~ (Support of GZip filters in the filter chain), because this issue contains a full gzip compression support.

[ Permlink | « Hide ]

Fernando Martins added a comment - 22/Mar/05 02:37 AM

Lars,
thanks for separating the issues.

I just reviewed CVS changes, and noticed that you check for gzip support (acceptsGZipEncoding) always, no matter if the responseContent is gziped or not. Shouldn't this be done only in the case when the cached response is in fact gziped (responseContent.isContentGziped())?
The reason is not only semantical but also performance related, since isContentGziped only performs a simple String equals, when acceptsGzipEncoding has to get the headers from the request and check for indexOf which I believe is slower. Besides the method is protected and thus can/should be overriden so that more extensive (and performance expensive) checks can be done for browser agents etc.
Sorry for insisting about it, but this is code which is executed on each request and when you're dealing with millions of requests per day it can start to make a difference.

Also notice the unused import statements in ResponseContent.
The rest looks ok.
Thanks

[ Permlink | « Hide ]

Lars Torunski added a comment - 23/Mar/05 12:58 AM

This check is needed for the full gzip support (CACHE-49): If the content is not gzipped and the browser supports gzip encoding, we will be able to gzip the content in ResponseContent. Should I remove the check in this release?