Invalid Content-Range header for HTTP range requests when downloading files from asset directories

[joris.guex]

Hello,

We are seeing an issue where we are trying to download files from a ProGet asset directory using wget's --continue flag but wget is returning with exit code 4.

We think we have tracked it down to the following issue:

ProGet appears to be returning an invalid Content-Range header for HTTP range requests.

For example, for a file with a total length of 1000 bytes, where 500 bytes have already been downloaded, ProGet returns:

$ wget --server-response --continue --tries 1 https://<PROGET_URL>/endpoints/assets/content/example_file
HTTP/1.1 206 Partial Content
Content-Range: bytes 500-1000/1000

While other HTTP servers (tested with uv run --with rangehttpserver -m RangeHTTPServer) returns the following:

$ wget --server-response --continue --tries 1 http://0.0.0.0:8000/example_file
HTTP/1.0 206 Partial Content
Content-Range: bytes 500-999/1000

Similarly, for a file with a total length of 1000 bytes, which has already been fully downloaded, ProGet returns:

$ wget --server-response --continue --tries 1 https://<PROGET_URL>/endpoints/assets/content/example_file
HTTP/1.1 206 Partial Content
Content-Range: bytes: 1000-1000/1000

While other HTTP servers returns the following:

$ wget --server-response --continue --tries 1 http://0.0.0.0:8000/example_file
HTTP/1.0 416 Requested Range Not Satisfiable

Looking at https://datatracker.ietf.org/doc/html/rfc9110#name-content-range, I think the current behaviour is incorrect as byte positions are zero-based. In this case the last valid byte should be 999, not 1000.

Curl seems to ignore this issue, but we are using bitbake which does not allow easily swapping out wget for curl so this is not a solution for us.

Has anyone else seen this, or is there a known fix/workaround?

Thanks,
Joris

[gdivis]

Hi @joris.guex

You're right! It looks like ProGet is reporting the second value of the range as if it was an exclusive bound rather than inclusive. Somehow it has been like this for years.

Anyway, it looks to be a trivial fix, so we should be able to get this in this Friday's release of 2026.9. I've created PG-3350 as the tracking issue for it.

Thanks for reporting the problem!
-Greg