Is this still maintained?

[vardumper]

I have last been able to successfully compile this module into nginx in v1.23.+
Recently I am seeing constant version errors on Ubuntu 24.0.4.
I tried both the stable 1.26.2 as well as the mainline 1.27.2 versions of nginx.

The exact error I get is: version 1023002 instead of 1027002

[dvershinin]

@vardumper The module works fine with recent NGINX releases. The error you are seeing is caused by compiling the module with one version of NGINX but attempting to use it with a different version. For E.g. you compiled a module on against 1.23.2 but attempted to load it in 1.26.2.

[Eagle3386]

How about Google finally doing a good job, making it work version-independent of any NGinX update from now on?

Seriously, that whole re-compiling stuff is nothing but a PITA given any decent micro-services architecture using it - most companies don't have the resources, let alone developers or even admins with time to re-compile this module's code each time NGinX fixes a security whole in one of its used base libraries, forcing a re-compile for those using Brotli support & literally not buying the "plus" product.

[dvershinin]

@Eagle3386 It has nothing to do with Google.

It is NGINX that requires the dynamic modules to be used with the version they are compiled against.

If you don't want to recompile you're more than welcome to use NGINX Extras, I'm its maintainer but your concern is exactly addressed by either NGINX Extras or NGINX Plus packages.

[Eagle3386]

A couple of years ago, Infragistics acted just the same: each update on their end required a rebuild due to their version-dependent libraries being compiled into any application. It even included changing the filenames, thanks to them adding the version to those files.
Later, they provided version-free libraries & allowed for drop-in updates without recompiling, because customers threatened to leave if no improvement happened - maybe we should do that, too.

I expect libraries to work & if there's an update in Brotli, but not in NGinX, I expect it to continue with an updated Brotli module - just as I do with an updated NGinX whose Brotli module didn't change.
And no, paying for that isn't even an option to start with - rather its a basic requirement for any software.

Lastly, I can almost clearly see why NGinX did that move & I want to express fully how much of a disgrace this is in my opinion.

[mnordhoff]

Y'all don't pay F5 or Google for NGINX or ngx_brotli and now aggressively post threats in this GitHub repostiory to... continue not to pay them, but harder?

[dvershinin]

@Eagle3386, I understand your frustration, but nobody had an evil intention from NGINX side to inconvenience users. The fact is, NGINX internal structures can change between versions, and NGINX being open source, consider that maintaining version-independent compatibility would be a massive burden. It's not unique to NGINX—Varnish, for example, follows a similar approach.

[wyattoday]

If you're building one part of Nginx, then build the whole thing statically. It'll be faster and only contain the code you need. Or depend on whatever your Linux / BSD distro makes and distributes (including their modules).

Trying to build part and depend on the distro for the other part is a fools errand.

The dynamic modules are meant for distros, not for people build a part of Nginx themselves.

[Eagle3386]

@mnordhoff

Y'all don't pay F5 or Google for NGINX or ngx_brotli and now aggressively post threats in this GitHub repostiory to... continue not to pay them, but harder?

First things first: Google doesn't deserve a dime & I'm all in for the divestiture of Alphabet, period.
NGinX on the other hand is only (t)here, because it's free. Start charging 1 cent for its usage & you'll see the whole internet moving on within weeks, if not less.
The very first website was born from free software & anyone trying to tell a different story or suggesting to anyone to feel "guilty", like, e.g., "turn off your uBlock Origin on Google, YouTube or whatever", should become public enemy number one right away.

@dvershinin I do understand that. That's why I brought Infragistics as another example. I do get the technical debt that got built over the years inside of NGinX just as your point of the future burden it would bear on it.
However, I still truly believe it should be possible to support - within specific boundaries - updates of either NGinX or a module without requiring the other to be recompiled against it. After all, that's what interfaces were made for, right? 😉

@wyattoday The "problem" with our chosen distribution, Ubuntu, is its huge "one size fits all" approach for their NGinX package.
It carries so many modules - which we simply don't need. In fact, the setup is:

1. Micro-services architecture, soon to be setup using Docker containers
2. [NGinX as gRPC reverse proxy] <-> [ASP.NET's built-in web server, Kestrel, configured to support gRPC only]
3. [NGinX as gRPC endpoint] <-> [any browser with support for gRPC-Web as public client]

For the last one (3.), we'd like to respond with - already by .NET compiled/produced - .br files instead of the non-compressed ones.

However, compiling NGinX and/or the Brotli module due to an update of either, requires downloading all of them, as source code, compile them & then deploy those binaries throughout our systems.
On. Each. And. Every. Update. Of. Either. Component.

I'd rather expect downloadable binaries, much like one could in earlier days with WinAmp: download the DLL, put it into the plugins folder & you're good to go.

[vardumper]

To clarify, I did not intend to stir up the crowd. I managed to compile nginx with brotli, again:

1. First option was to downgrade nginx to 1.24.0, and compile ngx_brotli (not ideal)
2. Finally found the missing step for me, which was the git revert mentioned here

So the problem is solved for me, but having to recompile on each update is somewhat tidious...