Re: Question: Do APT support streaming download for metadata/deb?

David Kalnischkies <[email protected]> Sun, 21 Sep 2025 21:59:07 +0200

Newsgroups	gmane.linux.debian.apt.devel
Message-ID	<il23dci5fxnkmxgzvghmq5tr644vfqpk7vojinoe6xgmfqubky@haskvblxyqra>

Am Sat, Sep 20, 2025 at 03:17:45PM +0000, schrieb 陈 溢飞:
> To investigate, I deployed a simple HTTP server that forwards requests to/from <https://deb.debian.org>, while removing the `Content-Length` header.

"Streaming" as you call it is not specified in the HTTP spec.
You can't just drop Content-Length and have it working.

That wget works is easily explained: It does HTTP1.0 requests,
which are "Connection: close" by default, so the end of the
message body is indicated by the server closing the connection
in the absence of Content-Length. apt does http1.1 requests that
are "Connection: keep-alive" by default.

I don't know off hand why curl might deal with your broken server.
Perhaps it falls back to http1.0 automatically, but we have no
intention of replication such behaviour.

See RFC 7230 and especially § '3.3.3 Message Body Length' as well
as the other RFCs nowadays specifying HTTP.


> It seems that APT may not support streaming downloads.

The HTTP spec defines a chunked transfer encoding in case you don't
know the Content-Length a priori and don't want to constantly close
the connection – and apt supports that.


That your Release file devoid of hashes is not a good idea should
be obvious from the warnings apt gives to you as you need a rather
big hammer to even have apt consider this a valid source even if you
fix your server.


Best regards

David Kalnischkies

signature.asc (application/pgp-signature, 833 B)