Redo gzipping of response's content if user agent supports it

Description

In a preliminar test version of the new service architecture, there were the possibility of compressing the response's content if the user agent supplied a HTTP header saying that it can automatically handle it. Although it was proposed to move this logic to a Filter servlet, may be it is not actually necessary since it can be well done in AbstractService.

The problem is now to find a way for identifying wich response content can be benefited of such encoding. i.e., all xml responses will, but JPEG images not really. May be it should be related to a mapping of "compressable" MIME types, but still needs to figure out the best way of doing it.

Environment

None

Activity

Show:
codehaus
April 10, 2015, 4:28 PM

CodeHaus Comment From: cholmes - Time: Sat, 31 Jan 2004 12:37:45 -0600
---------------------
<p>Hey Gabriel, what would you think of a less ambitious version of this task? Instead of trying to figure out what the client can actually handle we just do it for GetFeatures. The WFS spec already has measures in place to handle this - we just add another output format - gml2.gz. This leaves it to the clients to actually request the gzipped format if they can handle it <em>and</em> want it. From our end it is just part of the GetFeature request, and our GetFeatureResponse should just write out the gzipped response if it is requested. This will make many people happy, and later we can figure out automatic support with the http header. If we could get this in 1.2 that'd be great, if not then just move this issue to 1.2.1</p>

codehaus
April 10, 2015, 4:29 PM

CodeHaus Comment From: groldan - Time: Mon, 2 Feb 2004 06:47:57 -0600
---------------------
<p>Ok Chris, no problem with adding support based on request's output format parameter.

I'll manage it today.</p>

codehaus
April 10, 2015, 4:29 PM

CodeHaus Comment From: cholmes - Time: Tue, 17 Feb 2004 15:29:03 -0600
---------------------
<p>Did you do this yet? If so then mark it as closed. If not and you don't have time we can move to 1.2.1</p>

codehaus
April 10, 2015, 4:29 PM

CodeHaus Comment From: groldan - Time: Wed, 10 Mar 2004 19:20:25 -0600
---------------------
<p>Added a new output format, GML2.gz

refactored FeatureResponse and added the following new classes:</p>
<ul class="alternate" type="square">
<li>FeatureResponseDelegate interface to delegate the encoding of the results of executing a getfeature request into the desired output format</li>
<li>FeatureResponseDelegateFactory factory of encoders, to add a new one, implement FeatureResponseDelegate to deal with a specific output format and add it here</li>
<li>GetFeatureResults parameter objects wich holds the results and metadata of the execution (FeatureResults, FeatureLock, FeatureRequest and FeatureTypeInfo). Used as argument for telling a delegate to prepare for encoding. The prepare() method of the delegate is the equivalent of execute in Response, but recieves the results of the execution to set up any resource/state it will need at encoding time</li>
<li>GML2FeatureResponseDelegate delegate wich deals with the encoding of GML2 and GML2.gz output formats</li>
</ul>

<p>Also added &lt;b&gt;String getContentEncoding()&lt;/b&gt; to Response, wich returns null by default or the specific encoding ("gzip" in this case). Updated AbstracService to set this encoding to the HttpServletResponse object so a user agent can recognize the gzipped content</p>

Fixed

Assignee

Unassigned

Reporter

codehaus

Triage

None

Fix versions

Affects versions

Components

Priority

Low