https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #21 from Mark Thomas ---
(In reply to thorsten.meinl from comment #19)
Can you clarify what role, if any Tomcat's default servlet plays in your app.
Tomcat aims to be specification compliant.
Container provided compression and ap
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #20 from Michael Osipov ---
(In reply to thorsten.meinl from comment #19)
> We recently stumbled upon this change because after an upgrade from Tomcat
> 8.5 to the lastet Tomcat 9 compression suddenly didn't work any more. We do
> u
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #19 from thorsten.me...@knime.com ---
We recently stumbled upon this change because after an upgrade from Tomcat 8.5
to the lastet Tomcat 9 compression suddenly didn't work any more. We do use
strong ETags because it's the only way t
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #17 from Konstantin Kolinko ---
(In reply to Michael Osipov from comment #16)
> (In reply to Mark Thomas from comment #15)
>
> > Of all the ideas, disabling compression in the presence of a strong ETag
> > seems like the best solut
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #16 from Michael Osipov ---
(In reply to Mark Thomas from comment #15)
> There is a long discussion on the httpd ticket on the merits of adding
> "-gzip" or similar to a strong ETag and removing it when seen on a request.
> The sho
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #15 from Mark Thomas ---
There is a long discussion on the httpd ticket on the merits of adding "-gzip"
or similar to a strong ETag and removing it when seen on a request. The short
version is that unless a server tracks the ETags
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #14 from Michael Osipov ---
(In reply to Remy Maucherat from comment #12)
> Doing cosmetic configuration changes like this is not a good idea. When the
> subelements of Connector were introduced, it was out of necessity to
> impleme
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #13 from Michael Osipov ---
(In reply to Konstantin Kolinko from comment #11)
> (In reply to Michael Osipov from comment #8)
> >
> > I get the feeling that compression configuration must be moved sooner or
> > later to a subelement
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #12 from Remy Maucherat ---
Doing cosmetic configuration changes like this is not a good idea. When the
subelements of Connector were introduced, it was out of necessity to implement
SNI, not to beautify. It caused a lot of bugs and
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #11 from Konstantin Kolinko ---
(In reply to Michael Osipov from comment #8)
>
> I get the feeling that compression configuration must be moved sooner or
> later to a subelement beneath a connector.
Enabling compression globally
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #10 from Michael Osipov ---
(In reply to Remy Maucherat from comment #9)
> (In reply to Mark Thomas from comment #5)
> > Where things get "interesting" is when resources set their own, strong ETag.
> > It looks to me that the simple
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #9 from Remy Maucherat ---
(In reply to Mark Thomas from comment #5)
> 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 co
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
Michael Osipov changed:
What|Removed |Added
CC||micha...@apache.org
--
You are recei
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #8 from Michael Osipov ---
(In reply to Konstantin Kolinko from comment #6)
> (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 valid
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- 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)
>
> Likewise
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #6 from Konstantin Kolinko ---
(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)
> [...]
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #5 from Mark Thomas ---
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)
Likewise, a validator is weak if it is shared by two or more
repr
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #4 from Michael Osipov ---
(In reply to Remy Maucherat from comment #2)
> The purpose of the tag is to know if there is an update. Thus, it is ok if
> compression does not change the etag, regardless of what the specification
> migh
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #3 from Julian Reschke ---
Hm, no.
If the payload is different, it can't have the same strong etag.
Consider the impact on conditional requests.
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #2 from Remy Maucherat ---
The purpose of the tag is to know if there is an update. Thus, it is ok if
compression does not change the etag, regardless of what the specification
might imply in its language.
--
You are receiving thi
https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #1 from Michael Osipov ---
I think this also applies to the DefaultServlet for weak Etags:
An origin server
SHOULD change a weak entity-tag whenever it considers prior
representations to be unacceptable as a substitute for th
22 matches
Mail list logo
