On 23/10/2019 13:28, Mark Thomas wrote: > 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.
Looking at the history, we have changed the API for the constructor in the past so I think it would be safe to do that again. My plan is to replace most of the parameters with the Protocol. I think the getters and setters will need to stay. They can/should probably be deprecated as they are removed in 9.0.x. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
