Inconsistent NGINX version on nginx.org

[NotSlow]

I use my own script to check current nginx version from time to time.

And today noticed that my script says 1.29.0 when i clearly see 1.29.1 on nginx: download

Also i have a nginx repo in one debian server, which also says 1.29.1

I try to manually wget/curl that page from various vps around the world and they all get 1.29.0

I even tried to faking user agent - still the same result.

Then i tried google translate that page:

Google sees 1.29.0 as well

I’d listen some explanation. No, i understand that it’s something related to your cdn/caching. But i don’t think that such de-sync is normal.

[MikeJang]

Maybe we just had to wait a day? I see 1.29.1

[MikeJang]

Oh I think I see what you mean. After running Google Translate, I see 1.29.0

[NotSlow]

Yes. The problem is that people and “scripts” see different content

[davemc]

Is your script looking at the server header?

[NotSlow]

You may try any of your own script and see what response will it get.

I just wonder what’s the catch, how to simulate request to get proper response with actual 1.29.1 version

[liam]

The nginx.org website uses pre-compressed pages (with the gzip_static module). It seems that the .gz pages are up do date, but the uncompressed pages are stale. Therefore scripts which do not ask for compressed content are seeing content from 02-Sep-2025 (prior to the 1.29.1 release).

See how the e-tag and last-modified dates vary, based on Accept-Encoding request header:

$ curl -I https://nginx.org/en/download.html
HTTP/1.1 200 OK
Server: nginx/1.29.0
Date: Fri, 05 Sep 2025 08:38:36 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 9367
Last-Modified: Sat, 02 Aug 2025 16:00:23 GMT
Connection: keep-alive
Keep-Alive: timeout=15
ETag: "688e3617-2497"
Strict-Transport-Security: max-age=31536000
Accept-Ranges: bytes

$ curl -I https://nginx.org/en/download.html -H "Accept-Encoding: gzip"
HTTP/1.1 200 OK
Server: nginx/1.29.0
Date: Fri, 05 Sep 2025 08:38:02 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1714
Last-Modified: Wed, 13 Aug 2025 15:53:18 GMT
Connection: keep-alive
Keep-Alive: timeout=15
ETag: "689cb4ee-6b2"
Content-Encoding: gzip
Strict-Transport-Security: max-age=31536000
Accept-Ranges: bytes

I will ask the web team to rebuild the uncompressed pages. Looks like we have a build pipeline failure. @NotSlow - thank you for flagging this!

[liam]

BTW, here are simpler and more reliable ways of checking what the latest release is

$ curl -s https://nginx.org/en/CHANGES | head -2
$ curl -s https://api.github.com/repos/nginx/nginx/releases/latest | jq -r '.tag_name'

[liam]

I will ask the web team to rebuild the uncompressed pages

Done. And the build pipeline has been tweaked to prevent this happening again.

[NotSlow]

Alright, thanks.

[oxpa]

@NotSlow If you’re interested in packages, you can use version.nginx.com for scripts. Since it’s an XSLT that looks into the repository, it doesn’t make mistakes or return “wrong” data.

In general, it usually takes a couple of hours from publishing the source code to uploading the packages, so you can also just wait till packages publication to pull the source code.