Access to https://camel.apache.org/ responds 404

[gansheer]

https://camel.apache.org/index.html works but not https://camel.apache.org/.

It appears to be a more specific issue than our usual 404 errors.

[gansheer]

Could be linked to infra issue (see https://issues.apache.org/jira/browse/INFRA-27679) but I'll check anyway.

[davsclaus]

yeah the root page should IMHO always be working - I have seen this a few times during PTO where my mobile phone has a link to the front page and it returned 404 once in a while and sometimes the working page.

[gansheer]

Since it is down again I ran some tests with Claude.

Potential Bug detected

The Apache Camel website (https://camel.apache.org/) returns HTTP 404 when the request includes gzip in the Accept-Encoding header. This affects modern browsers (Chrome, Firefox) and wget, which send this header by default.

Environment

• URL: https://camel.apache.org/
• CDN: Varnish/Fastly (151.101.2.132)
• Affected clients: Chrome 147, Firefox 149, wget2 2.2.1
• Working clients: curl 8.15.0 (without --compressed flag)

Steps to Reproduce

Test 1: Request WITH gzip encoding (FAILS)

  curl -I -H "Accept-Encoding: gzip" https://camel.apache.org/
  Expected: HTTP 200
  Actual: HTTP 404

Test 2: Request WITHOUT gzip encoding (WORKS)

  curl -I https://camel.apache.org/
  Expected: HTTP 200
  Actual: HTTP 200 ✓

Test 3: Request with other encodings (WORKS)

  curl -I -H "Accept-Encoding: br" https://camel.apache.org/
  curl -I -H "Accept-Encoding: deflate" https://camel.apache.org/
  curl -I -H "Accept-Encoding: zstd" https://camel.apache.org/
  Expected: HTTP 200
  Actual: HTTP 200 ✓

Test 4: wget2 behavior

# Fails (sends Accept-Encoding: gzip, deflate, br, zstd by default)
  wget --spider https://camel.apache.org/

# Works (disables compression)
wget --no-compression --spider https://camel.apache.org/

Detailed Test Results

┌─────────────────────────┬─────────────────┐
│ Accept-Encoding Header │ HTTP Response │
├─────────────────────────┼─────────────────┤
│ (none) │ 200 OK ✓ │
├─────────────────────────┼─────────────────┤
│ gzip │ 404 NOT FOUND ✗ │
├─────────────────────────┼─────────────────┤
│ deflate │ 200 OK ✓ │
├─────────────────────────┼─────────────────┤
│ br │ 200 OK ✓ │
├─────────────────────────┼─────────────────┤
│ zstd │ 200 OK ✓ │
├─────────────────────────┼─────────────────┤
│ gzip, deflate, br │ 404 NOT FOUND ✗ │
├─────────────────────────┼─────────────────┤
│ gzip, deflate, br, zstd │ 404 NOT FOUND ✗ │
└─────────────────────────┴─────────────────┘

Impact

• All modern browsers fail to load the website (they all send Accept-Encoding with gzip)
• wget/wget2 fails by default
• Users must use workarounds to access the site

Workarounds

1. For wget: wget --no-compression https://camel.apache.org/
2. For curl: Use default curl (don't use --compressed flag)
3. For browsers: No easy workaround available

Quick test commands for verification:

# Should return 404:
curl -I -H "Accept-Encoding: gzip" https://camel.apache.org/

# Should return 200:
curl -I https://camel.apache.org/

[sebbASF]

It might be useful to include the cache details for these requests, e.g.

curl -sSI -H "Accept-Encoding: gzip" https://camel.apache.org/ | grep "X-Cache|^HTTP|X-Served"

I just got:

HTTP/1.1 200 OK
X-Served-By: cache-hel1410023-HEL, cache-lcy-egml8630086-LCY
X-Cache: MISS, MISS
X-Cache-Hits: 0, 0

[gansheer]

@sebbASF good idea, I will try the next time it is down. Since it's up again I can't do tests for now.

[gansheer]

@sebbASF We are currently failing on https://camel.apache.org/components/4.18.x/:

With gzip header:

curl -sSI -H "Accept-Encoding: gzip" https://camel.apache.org/components/4.18.x/
HTTP/2 404 
server: Apache
content-type: text/html; charset=iso-8859-1
content-encoding: gzip
via: 1.1 varnish, 1.1 varnish
accept-ranges: bytes
age: 161
date: Wed, 29 Apr 2026 11:22:49 GMT
x-served-by: cache-hel1410030-HEL, cache-par-lfpg1960056-PAR
x-cache: MISS, HIT
x-cache-hits: 0, 0
x-timer: S1777461769.303714,VS0,VE1
vary: Accept-Encoding
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-length: 238

Without gzip header:

curl -sSI https://camel.apache.org/components/4.18.x/
HTTP/2 200 
server: Apache
last-modified: Tue, 14 Apr 2026 13:19:59 GMT
cache-control: max-age=0, no-transform
expires: Wed, 29 Apr 2026 11:23:09 GMT
access-control-allow-origin: *
content-security-policy: default-src 'self'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests; connect-src https://*.algolia.net https://*.algolianet.com; img-src 'self' https://*.githubusercontent.com; child-src https://www.youtube-nocookie.com
x-frame-options: DENY
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
referrer-policy: no-referrer-when-downgrade
content-type: text/html; charset=utf-8
via: 1.1 varnish, 1.1 varnish
accept-ranges: bytes
age: 0
date: Wed, 29 Apr 2026 11:23:09 GMT
x-served-by: cache-hel1410030-HEL, cache-par-lfpg1960097-PAR
x-cache: MISS, MISS
x-cache-hits: 0, 0
x-timer: S1777461789.354281,VS0,VE45
vary: Accept-Encoding
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-length: 315004

[sebbASF]

A couple of questions arise:

• should the CDN be caching 404s?
• why is the CDN seeing the 404 in the first place?

[tram98]

My workaround is to append index.html to all URLs returning a 404.

This issue has been open for quite some time. Is there anything that the OSS-community can do to accelerate its resolution?

[sebbASF]

That may work because the CDN does not have the URL cached.
Any URL that is different but returns the same data will do, for example appending a dummy query.

[zregvart]

According to the documentation, Fastly will cache requests that respond with status 404 from the origin server. Perhaps a way forward could be to disable caching for those?

For example add this to vcl_fetch:

if (beresp.status == 404) {
  set beresp.cacheable = false;
}

[gansheer]

@zregvart could we maybe comment this: https://github.com/apache/camel-website-pub/blob/edd1d9501c4cd9f182c44e4b66b2d0ce83b8d5e2/.htaccess#L2145-L2182 ?

[zregvart]

@zregvart could we maybe comment this: apache/camel-website-pub@edd1d95/.htaccess#L2145-L2182 ?

Not seeing how that could be an issue, but it might be an edge case I'm not aware of, so it might be worth to do an experiment with that bit removed.

[zregvart]

Right now, I'm seeing this to be an issue with the front page:

$ curl -I -H "Accept-Encoding: gzip" https://camel.apache.org
HTTP/2 404
server: Apache
content-type: text/html; charset=iso-8859-1
content-encoding: gzip
via: 1.1 varnish, 1.1 varnish
accept-ranges: bytes
age: 5822
date: Thu, 07 May 2026 14:52:46 GMT
x-served-by: cache-hel1410023-HEL, cache-sof1510036-SOF
x-cache: HIT, HIT
x-cache-hits: 35, 0
x-timer: S1778165567.767260,VS0,VE1
vary: Accept-Encoding
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-length: 238

Not seeing this to be an issue with the origin server:

$ curl -I -H "Accept-Encoding: gzip" -H "Host: camel.apache.org" https://tlpserver3-he-fi.apache.org/
HTTP/1.1 200 OK
Date: Thu, 07 May 2026 14:53:48 GMT
Server: Apache
Strict-Transport-Security: max-age=16070400; includeSubDomains
Last-Modified: Thu, 07 May 2026 09:48:56 GMT
Accept-Ranges: bytes
Cache-Control: max-age=0, no-transform
Expires: Thu, 07 May 2026 14:53:48 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Access-Control-Allow-Origin: *
Content-Security-Policy: default-src 'self'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests; connect-src https://*.algolia.net https://*.algolianet.com; img-src 'self' https://*.githubusercontent.com; child-src https://www.youtube-nocookie.com
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: no-referrer-when-downgrade
Content-Length: 4689
Content-Type: text/html; charset=utf-8

I don't think there is anything that we can do to address this. For me, this solely resides within the realms of the CDN (Fastly).