Bug#1053833: 503 errors [Server reports unexpected range] when cascading acngs

[Michael Tokarev]

Package: apt-cacher-ng
Version: 3.7.4-1+b2
Severity: normal

I've two acng proxies acting in a cascading manner (the other location
does not have direct access to network, so I forward local acng port to
the other location and have acng there to cache things for nearby machines).
And almost always it fails to provide simple `apt update', failing to
update InRelease files, reporting 530 [Server reports unexpected range]
errors:

$ wget http://apt-proxy:3142/www.corpit.ru/mjt/packages/samba/bookworm/samba-4.18/InRelease
Connecting to apt-proxy:3142 (10.221.1.37:3142)
wget: server returned error: HTTP/1.1 503 Server reports unexpected range

This issue will persist until I remove the cached InRelease file, - after
which download of the updated InRelease and all other files will succeed.

Here's what's going on the wire, the view from the intermediate acng:

GET http://www.corpit.ru/mjt/ackages/samba/bookworm/samba-4.18/InRelease HTTP/1.1
User-Agent: Apt-Cacher-NG/3.7.4
Host: www.corpit.ru
Proxy-Connection: keep-alive
If-Range: Tue, 10 Oct 2023 15:46:31 GMT
Range: bytes=2324-
Cache-Control: max-age=0
Accept: application/octet-stream
Accept-Encoding: identity
Connection: keep

HTTP/1.1 206 Partial Content
Content-Type: octet/stream
Last-Modified: Tue, 10 Oct 2023 17:41:09 GMT
Content-Range: bytes 2324-2324/2325
Content-Length: 1
X-Original-Source: http://www.corpit.ru/mjt/packages/samba/bookworm/samba-4.18/InRelease
Connection: Keep-Alive
Date: Thu, 12.Oct 2023 09:19:39.GMT
Server: Debian Apt-Cacher NG/3.7.4
(1-byte payload)

The cached file, on the intemediate host:
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 2325 Oct 12 01:15 /var/cache/apt-cacher-ng/www.corpit.ru/mjt/packages/samba/bookworm/samba-4.18/InRelease
On the end-user host:
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 2325 Oct 10 16:31 /var/cache/apt-cacher-ng/www.corpit.ru/mjt/packages/samba/bookworm/samba-4.18/InRelease

The file's different (from different archive rebuilds) but has
the same size (which is expected for an InRelease file).

What I see here are at least two issues:

1. Why the end-user acng rejects the reply? Seems like a valid
byte range.

2. Why the intermediate acng does not take into account the If-Range
header? Clearly the If-Range requested by client is *older* than
Last-Modified on the intermediate, shouldn't the intermediate
ignore Range: and send whole file which is modified later than
the requested range?

This affects mostly the InRelease files, - maybe it's because these files
always has the same size.

So far, acng in this configuration is almost unusable - one have to
remove all InRelease files on the caching host before doing any
apt-update.

/mjt

[Michael Tokarev]

After looking into the source, I found this brilliant comment in acng.conf.in:

# There some broken HTTP servers and proxy servers in the wild which don't
# support the If-Range header correctly and return incorrect data when the
# contents of a (volatile) file changed. This also applies to incomplete
# resumed downloads. Setting VfileUseRangeOps to 0 disables Range-based
# requests (using purely If-Modified-Since and requesting the complete file
# instead, if changed). Setting it to a negative value removes even this check
# and means fetching the whole file from the beginning.
#
# VfileUseRangeOps: 1

The thing is that acng is such a broken HTTP proxy server *itself*, it does
weird thing with If-Range header exactly as outlined in this comment.

After setting VfileUseRangeOps to 0 things started working.

This obviously needs to be fixed still.

/mjt