Understood. Seemed I missed the fact that your interceptor is *optionally*
applied.
You are right, it would be beneficial if the example would add ETag and
Content-Encoding headers. If you file a JIRA issue I'll vote for it.
> -----Original Message-----
> From: Jan Algermissen [mailto:jan.algermissen_at_nordsc.com]
> Sent: Samstag, 27. Oktober 2012 00:39
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Gzipping Interceptors
>
>
> On Oct 26, 2012, at 11:30 PM, Markus KARG <markus_at_headcrashing.eu>
> 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?
>
> Jan
>
> [1] http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-
> 21#section-2.3.3
>
>
>
>
>
> >
> >> -----Original Message-----
> >> From: Bill Burke [mailto:bburke_at_redhat.com]
> >> Sent: Freitag, 26. Oktober 2012 23:09
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> 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
> >> http://bill.burkecentral.com
> >