users@jax-rs-spec.java.net

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

From: Markus KARG <markus_at_headcrashing.eu>
Date: Fri, 26 Oct 2012 23:30:47 +0200

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?

> -----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