opnsense
os-caddy: support response compression (zstd/gzip)
It would be great if the interface would allow the encode parameter to be set to allow compression when responding to the client.
This could be as simple as having a "compress" check box to include encode zstd gzip in the global config in keeping with the Caddy-has-sensible-defaults-mentality, though a fuller implementation wouldn't be unwelcome.
https://caddyserver.com/docs/caddyfile/directives/encode
Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.
For more information about the policies for this repository, please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.
The easiest option to gain traction is to close this ticket and open a new one using one of our templates.
I'd prefer not to offer compression.
https://caddy.community/t/caddy-gzip-and-crime-breach/487 https://en.wikipedia.org/wiki/BREACH
Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.
For more information about the policies for this repository, please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.
The easiest option to gain traction is to close this ticket and open a new one using one of our templates.
I'd prefer not to offer compression.
https://caddy.community/t/caddy-gzip-and-crime-breach/487 https://en.wikipedia.org/wiki/BREACH
Everything can be configured somewhere along the sliding scale-of-security from fully-open at one end to air-gapped at the the other. It's all about risk versus benefit (otherwise we'd have no Internet at all).
Why not let the user choose for their risk posture? Caddy clearly felt it acceptable to include the functionality within the Caddy codebase, and it's in very common use - indeed I'd almost argue it's commonly accepted best practice.
It feels a bit overbearing to block the user from enabling it. If we removed all options that could be configured in an insecure manner, then half the services in OPNsense would be gone...
With every respect, it just seems a bit arbitrary to me.
I'm open to review a PR that adds it in a contained scope.
I currently don't want to add this as new feature myself.
I'm open to review a PR that adds it in a contained scope.
I currently don't want to add this as new feature myself.
I might have a look at it in a month or two when some other things have calmed down.
Thanks, if you want to take this, please make it configurable per handler, for example putting the option in the transport header as dropdown.
https://github.com/opnsense/plugins/blob/b850e22ee82b12a8aa0801f9844dbdc582c490d5/www/caddy/src/opnsense/mvc/app/controllers/OPNsense/Caddy/forms/dialogHandle.xml#L108-L146
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.