On 2/24/26 6:34 AM, Crystal Kolipe wrote:
 > 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.
 >

Thanks for pointing out the style guide. I'll clean up the patch and
resubmit later. Admittedly I sent it a little early. That will teach me
to compose directly in Thunderbird! :)

I did consider that the base system doesn't ship with a brotli library
or tool, but I felt that it doesn't necessarily need one even if httpd
can serve those files. httpd isn't compressing files on the fly so it
doesn't need access to a brotli lib any more than it currently needs to
reach out to gzip.

Also the user doesn't have to generate the compressed files on the
same machine that serves them. In my particular use case, I build a
static site on my desktop, compress certain files, and then rsync to my
webserver. In that workflow, the user doesn't need brotli on the
remote. But I understand the concern.

I do agree that this approach doesn't generalize. However as far as I
can tell, gzip and brotli are the only encodings worth supporting at the
moment. If something better comes along, a different approach can be
considered then.

I'm wary of feature-creep too. I'm using OpenBSD partially because
it is more trim than other options. So I'm happy to defer to y'all's
good judgement.

As an aside, you made me curious and at the moment it _might_ be
possible to serve IPv4 and v6 differently by using the `listen on`
directives in httpd.conf. But I didn't test that.