On 23/10/2019 11:09, ma...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > markt pushed a commit to branch 8.5.x > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > > The following commit(s) were added to refs/heads/8.5.x by this push: > new 9054e10 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63829 > 9054e10 is described below > > commit 9054e10d53170afcd7dd85bd22335238625958dc > Author: Mark Thomas <ma...@apache.org> > AuthorDate: Wed Oct 23 08:50:11 2019 +0200 > > Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63829 > > Improve the check of the Content-Encoding header when looking to see if > Tomcat is serving pre-compressed content. Ensure that only a full token > is matched and that the match is case insensitive.
This isn't complete for 8.5.x because only HTTP/2 uses CompressionConfig to make the compress / don't compress decision. I could apply a similar change to the relevant parts of Http11Processor but I was wondering about the possibility of a more extensive back-port that aligned the 8.5.x implementation with 9.0.x. This would involve API changes including: - retain a reference to the Protocol - change to constructor signature - remove unnecessary getters and setters While this is tempting from both a simplification PoV and from an aligning 8.5.x and 9.0.x PoV I do wonder what the risk of breakage is if users are extending Http11Processor. It is an internal API but I suspect it is still used by some. I think I am going to look at see if there is some sort of middle ground to be found. Meanwhile, what do people think about API changes along the lines of the above. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
