On Tue, Feb 24, 2026 at 12:04:17PM +0100, Christian Schulte wrote:
> Am 24.02.2026 um 03:44 schrieb Adam Mullins:
> > The unified diff is included below.
> 
> From a syntax point of view the diff is lacking proper formatting
> according to [1]. Adding functionality to a daemon in base to support
> something not available in base may become a show stopper here. Even if
> the compression algorithm uses the MIT license, it is not in base, so
> whoever would want to use this functionality will have to install
> additional packages.

The problem is more generalised than that.

Is every new compression algorithm that comes along going to be implemented as
a discrete facility in httpd?

What happens when somebody eventually proposes to serve alternative static
files based on the HTTP_ACCEPT_LANGUAGE header?

Or based on the connection being IPv4 vs IPv6?

Are we going to add discrete code for each of these situations?

If this is going to grow beyond gzip, (and I'm already dubious about the
real-world benefit of that), we should consider replacing it with a more
generalised, 'serve alternative file', mechanism that can be configured by the
user, and move all of the actual decision logic out of httpd itself.

It would be much better if httpd could, (optionally), pass a list of HTTP
headers or whatever to another program listening on a socket, and that program
passes back a list of indicies to a previously configured list of extensions
that httpd can add to the requested file.

That way, the user can make it as complicated as they want to, but the logic
is moved out of httpd.