tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 63932] Content compression breaks contract of ETag
Date Tue, 19 Nov 2019 09:36:52 GMT

--- Comment #7 from Michael Osipov <> ---
(In reply to Mark Thomas from comment #5)
> Please take care, as Julian did, to be specific about whether you are
> talking about weak or strong validators.
> RFC 7232 states (section 2.1)
> <quote>
> Likewise, a validator is weak if it is shared by two or more
> representations of a given resource at the same time, unless those
> representations have identical representation data.  For example, if
> the origin server sends the same validator for a representation with
> a gzip content coding applied as it does for a representation with no
> content coding, then that validator is weak.
> </quote>
> So the Default servlet (that only ever sets a weak ETag) is fine. As is the
> WebDAV servlet.

I agree. Is there a possibility that a custom resource is added to the context
with issues strong validators?

> Where things get "interesting" is when resources set their own, strong ETag.
> It looks to me that the simplest solution would be for the container
> provided compression to check for the presence of a strong ETag and, if it
> finds one, prepend the weakness indicator to the ETag if it is going to
> compress the resource.

That would be wrong, imho. The servlet expects the ETag to retain strong and
not to be modified in terms of comparison strength.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message