From: Crystal Kolipe Subject: Re: add support to httpd for serving static brotli encoded files To: Christian Schulte Cc: tech@openbsd.org Date: Tue, 24 Feb 2026 11:34:16 +0000 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.