tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 63932] Content compression breaks contract of ETag
Date Tue, 19 Nov 2019 09:36:52 GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

--- Comment #7 from Michael Osipov <michaelo@apache.org> ---
(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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message