Request to download the package returns 10001 bytes in content-length header

[albertalexandrov]

Hi all!

poetry 1.8.2

We have a private pypi and an own python package. I specified a source in pyproject.toml. Then I'm trying to install the package.

When request to download the package is being done the next http headers are used (

poetry/src/poetry/inspection/lazy_wheel.py

Line 604 in c459f14

headers["Range"] = f"bytes=-{initial_chunk_size}"

):

{
    'Accept-Encoding': 'identity',
    'Cache-Control': 'no-cache',
    'Range': 'bytes=-10000'
}

The problem is that pypi returns something like this:

{
    'date': 'Tue, 28 Jul 2026 15:08:05 GMT',
    'content-type': 'application/octet-stream',
    'content-length': '10001'
}

I mean the content-length returns one byte more than requested. This causes error:

The following error occurred when trying to handle this error:

AssertionError

at /opt/homebrew/lib/python3.11/site-packages/poetry/inspection/lazy_wheel.py:526 in _fetch_content_length
522│ # If we could download some file contents, then write them to the end of
523│ # the file and set up our bisect boundaries by hand.
524│ with self._stay():
525│ response_length = int(tail.headers["Content-Length"])
→ 526│ assert response_length == min(initial_chunk_size, ret_length)
527│ self.seek(-response_length, io.SEEK_END)
528│ # Default initial chunk size is currently 1MB, but streaming content
529│ # here allows it to be set arbitrarily large.
530│ for chunk in tail.iter_content(CONTENT_CHUNK_SIZE):

Is the problem on our private pypi?

[Secrus]

1. Poetry v1 branch is no longer supported (just FYI - there will be no patches even if we have bugs here)
2. What implementation of package index do you use? The code regarding range requests should catch the lack of support for that.

[ECD5A]

For a file larger than 10,000 bytes, this request:

Range: bytes=-10000

means “return the final 10,000 bytes”. Byte ranges are inclusive, but a suffix length is still a length; a compliant partial response should be similar to:

HTTP/1.1 206 Partial Content
Content-Range: bytes 1-10000/10001
Content-Length: 10000
Accept-Ranges: bytes

So if your private index returns 206 Partial Content with Content-Length: 10001, its Range implementation (or a reverse proxy/cache in front of it) is off by one. That is exactly why Poetry's assertion fails.

The missing pieces in the pasted headers are the status and Content-Range. Test the same artifact directly:

curl -sv \
  -H 'Accept-Encoding: identity' \
  -H 'Cache-Control: no-cache' \
  -H 'Range: bytes=-10000' \
  'https://private-index.example/path/package.whl' \
  -o /dev/null

Interpret the result as follows:

• 206 + Content-Length: 10000 + a valid Content-Range: correct.
• 206 + Content-Length: 10001: broken server/proxy range response.
• 200 + the full file length: the server ignored Range; not an off-by-one partial response.
• 416: the server rejected the range; inspect the total object size and Content-Range: bytes */<size>.

Run it once against the index's origin and once through the public ingress/reverse proxy. If only the public path is wrong, check CDN/nginx/artifact-repository range handling and whether content encoding is being applied despite Accept-Encoding: identity.

There is also a separate maintenance issue: Poetry 1.8.2 is from the unsupported 1.x line, so first reproduce with a current Poetry 2.x release. Upgrading may improve fallback/error handling, but it cannot make a malformed 206 response valid—the private index/proxy should still be fixed.

If you share the response status, Content-Range, total wheel size, and private-index implementation/version, the faulty layer can be identified precisely.