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#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
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com