Hello,
> Hum..I think the client will send the appropriate header if he
> supports it. Based on that header, Grizzly will GZIP the response.
> Class com.sun.grizzly.http.DefaultProcessorTask has:
>
>> /**
>> * Check for compression
>> *
>> */
>> private boolean isCompressable(){
>> // Compression only since HTTP 1.1
>> if (! http11)
>> return false;
>>
>> // Check if browser support gzip encoding
>> MessageBytes acceptEncodingMB =
>> request.getMimeHeaders().getValue("accept-encoding");
>> if ((acceptEncodingMB == null) ||
>> (acceptEncodingMB.indexOf("gzip") == -1))
>> return false;
>>
>> // Check if content is not allready gzipped
>> MessageBytes contentEncodingMB =
>> response.getMimeHeaders().getValue("Content-Encoding");
>>
>> if ((contentEncodingMB != null) &&
>> (contentEncodingMB.indexOf("gzip") != -1))
>> return false;
>>
>> // If force mode, allways compress (test purposes only)
>> if (compressionLevel == 2)
>> return true;
>>
>> // Check for incompatible Browser
>> if (noCompressionUserAgents != null) {
>> MessageBytes userAgentValueMB =
>> request.getMimeHeaders().getValue("user-agent");
>> if (userAgentValueMB != null) {
>> String userAgentValue = userAgentValueMB.toString();
>>
>> if (inStringArray(noCompressionUserAgents, userAgentValue))
>> return false;
>> }
>> }
>>
>> // Check if suffisant len to trig the compression
>> int contentLength = response.getContentLength();
>> if ((contentLength == -1) || (contentLength >
>> compressionMinSize)) {
>> // Check for compatible MIME-TYPE
>> if (compressableMimeTypes != null)
>> return (startsWithStringArray(compressableMimeTypes,
>> response.getContentType()));
>> }
>>
>> return false;
>> }
>>
>
> Hence if your client add the accept-encoding: gzip, compression should
> starts. If that's not the case, then we have a bug :-)
It's also possible to tune Grizzly SelectorThread for better GZIP control.
Please take a look at following SelectorThread methods:
(1) public void setCompression(String compression);
(2) public void setCompressableMimeTypes(String compressableMimeTypes);
(3) public void setCompressionMinSize(int compressionMinSize);
Please look at [1], to see expected parameters for those methods.
Hope this will help a little :)
WBR,
Alexey.
[1]
http://weblogs.java.net/blog/jfarcand/archive/2006/06/enabling_http_c_1.html
>
> A+
>
> -- Jeanfrancois
>
>
>
>>
>> Jeanfrancois Arcand wrote:
>>> Hi Alan,
>>>
>>> Alan Williamson wrote:
>>>> Can some explain how outgoing compression is suppose to work within
>>>> Grizzly?
>>>>
>>>> I *think* i may have misunderstood it. I have it set to on, and
>>>> compress anything above 15KB. However nothing is being compressed.
>>>>
>>>> I take it then when i do something like this:
>>>>
>>>> OutputBuffer buffer = response.getOutputBuffer();
>>>> buffer.doWrite(chunk, response);
>>>>
>>>> Grizzly isn't automatically compressing this if the outgoing client
>>>> supports GZIP?
>>>
>>> Yes, via its output filter
>>>
>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/http11/filters/GzipOutputFilter.html
>>>
>>>>
>>>> does that mean i have to manage this myself?
>>>
>>> No grizzly supports it (at least in GlassFish :-))
>>>
>>> http://weblogs.java.net/blog/jfarcand/archive/2006/06/enabling_http_c_1.html
>>>
>>>
>>> How did you configure it exactly? If it doesn't work, it probably
>>> because of a bug. Last week I've ported some final fix from 1.0
>>> which we missed. Which version of Grizzly are you using?
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>>
>>>> thanks
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>