You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stapler adds some code to do gzip compression on the fly.
However there are various routes as pointed out in the code.
All modern containers (tomcat, weblogic, jetty) have support built in for doing compression which alleviates these tricks.
Therefore in the modern age, just remove any support in stapler for compression handling and make users user their servlet container appropriately if they desire the configuration.
The text was updated successfully, but these errors were encountered:
If you can patch Winstone to apply compression by default (or perhaps at an option—unclear you want it for clients on the same LAN) then sure, would be great to simplify the code here.
The Jetty GzipHandler is a compression handler that you can apply to any dynamic resource (servlet). It fixes many of the bugs in commonly available compression filters: it works with asynchronous servlets; it handles all ways to set content length. It has been tested with Jetty continuations and suspending requests.
my plan was to remove the support in stapler and then it is up to the end user using stapler to enable it (either via a load balancer, or configuration e.g. tomcat compression option in connector and to add the jetty servlet dynamically in winstone if a flag to disable compression it is not provided
Stapler adds some code to do gzip compression on the fly.
However there are various routes as pointed out in the code.
All modern containers (tomcat, weblogic, jetty) have support built in for doing compression which alleviates these tricks.
Therefore in the modern age, just remove any support in stapler for compression handling and make users user their servlet container appropriately if they desire the configuration.
The text was updated successfully, but these errors were encountered: