Well, ETag is not a MUST but a SHOULD in http/1.1, as it solves several
caching problems of http/1.0.
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Samstag, 27. Oktober 2012 05:56
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Gzipping Interceptors
>
> Err.. i don't see where ETag is a required header anywhere in the
> document you referenced.
>
> On 10/26/2012 6:38 PM, Jan Algermissen wrote:
> >
> > 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#sectio
> > n-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
> >>
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com