[jax-rs-spec users] [jsr339-experts] Re: Gzipping Interceptors

From: Jan Algermissen <>
Date: Sat, 27 Oct 2012 00:38:34 +0200

On Oct 26, 2012, at 11:30 PM, Markus KARG <> wrote:

> Yes, Bill is right, ETags in fact are opaque and have no deeper sense or
> syntax, unless the server application internally defines one for itself. So
> Jan, can you explain why you think that ETags have to be modified?

If the server is serving different representations for the same URI every representation must have its own entity tag[1]

Hence, if a given gzipping writer interceptor is not guaranteed to be applied to all responses to a given resource method, the ETag must be ensured to be unique.

Apache, for example, has (or at least had - no time to check) the behaviour of appending '-gzip' to the entity tag already present.

I am not so much worried about documenting what exactly the mechanics are, but I think that readers of the spec deserve at least a note that gzipping interceptors might be a slippery slope.

There are also the issues:

- Correctly setting Content-Encoding (add 'gzip' to any existing value at the right position)
- Checking that Accept-Encoding does not say that client is not capable of processing 'gzip' Content-Encoding

I simply wonder whether an example with less relation to HTTP nitty gritty details (and possible confusion should problems occur) isn't more appropriate.

Any suggestions for 'better' examples that are equally compelling?



>> -----Original Message-----
>> From: Bill Burke []
>> Sent: Freitag, 26. Oktober 2012 23:09
>> To:
>> Subject: [jsr339-experts] Re: Gzipping Interceptors
>> Isn't ETag opaque? Its only meaningful to the application itself?
>> On 10/26/2012 4:59 PM, Jan Algermissen wrote:
>>> Hi,
>>> Section 4.2.6 correctly says:
>>> "Content encoding is the responsibility of the application.
>> Application-supplied entity providers MAY per- form such encoding and
>> manipulate the HTTP headers accordingly."
>>> Section 6.3 then provides the gzip example for writer interceptors
>> but does not set the corresponding HTTP header. It also does not modify
>> the ETag header, should one be present.
>>> The later I am currently checking up on, but I am currently quite
>> convinced the Etag should be modified to achieve correct cache
>> behavior.
>>> Bothe (or at least the former) cases should IMHO be shown or at least
>> noted as a comment, e.g. // ...adjust Content-Encoding and ETag
>> response headers.
>>> As it stands the example can be quite misleading to developers
>> without deep interest in HTTP mechanics (that is almost all
>> developers).
>>> Thoughts?
>>> Jan
>> --
>> Bill Burke
>> JBoss, a division of Red Hat