Re: JSR311: gzip encoding

From: Bill Burke <>
Date: Tue, 31 Mar 2009 20:16:10 -0400

Paul Sandoz wrote:
> On Mar 31, 2009, at 10:11 AM, Julian Reschke wrote:
>> Stephan Koops wrote:
>>> Hi,
>>> -1
>>> If the accept-Encoding allows GZIP, than the JAX-RS runtime could
>>> decide on its own, that it gzip the data. This it could do with all
>>> encodings, that are allowe. So there is no additional annotation
>>> required.
>>> Ot course the runtime must set the content-encoding header, if it
>>> encode the data.
>>> ...
>> Keep in mind that if the runtime handles this, it will also have to
>> worry about Vary, and do rewriting both outgoing *and* incoming ETags
>> (conditional headers!).
> Since GZIP is a lossless encoding is it absolutely necessary to rewrite
> the ETags?

*GZIP encoding comes at a CPU cost. Does it really make sense to encode
everything if the client says Accept-Encoding: gzip, deflate? This is
why I thought it should be settable by the resource via annotation or

* To Marc's point: I never understood why encoding was a part of the
content negotiation apis of JAX-RS. If there is a special encoding,
JAX-RS has no way of using MessageBodyReaders and the app-developer will
have to do their own stream processing. IMO, there should have been a
ProducesLanguage ConsumesLanguage annotations too.

* To Ryan's point of there being different encodings. Resteasy came up
with a Meta Annotation in the spirit of HttpMethod for encoding.


public @interface GZIP {}

* To the ETag point. If gzip is a performance boost, isn't generating a
hash of the output yet another CPU performance loss? Meaning, you
shouldn't be hashing the message body for large responses? A guy from
Apple brought this point up in one of my talks at TSSJS.

Bill Burke
JBoss, a division of Red Hat