Hi, As you might have worked out from my commits, I'm working on a fix for bug 60276 [1] to add gzip compression support to HTTP/2. As usual, I want to reduce duplication / copy/paste so I am looking to re-use the GzipOutputFilter from HTTP/1.1.
As I have been working on this it has become apparent that there is a set of existing classes that are potentially common to HTTP/1.1 and HTTP/2 and that the HTTP/2 compression implementation will introduce a few new classes / interfaces that are HTTP specific but not HTTP version specific. I have therefore been thinking about the following refactoring: Plan A: - Create a new package org.apache.coyote.http - Move org.apache.coyote.http11.filters.* to org.apache.coyote.http.filters.* - Move org.apache.coyote.http11.(In|Out)putFilter to org.apache.coyote.http - Put the new HTTP version neutral classes in org.apache.coyote.http My current response compression solution means HTTP/2 only needs the GzipOutputFilter. I think there is scope to use some of the other filters as well. Thoughts? Is this too much refactoring (and potential disruption) for too little benefit? Plan B is too leave the existing classes where they are and put the new classes common to HTTP/1.1 and HTTP/2 in org.apache.coyote.http11 (since the existing classes common to both are under that package). I do like the idea of having the HTTP version neutral classes in a separate package. That said, the chunking filters aren't version neutral. They only apply to HTTP/1.1. While we could keep them in their existing package splitting the filters across multiple packages really does seem wrong. As I have been typing this e-mail I think I have convinced myself that plan B is the better option. I'll look at this again tomorrow with a fresh pair of eyes but I'd appreciate some community feedback on the two options above (or a suggestion of an alternative approach). Thanks, Mark [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60276 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
