On Wed, Aug 12, 2015 at 06:00:17PM +0200, Marco d'Itri wrote: > Package: apt-cacher > Version: 1.7.11 > Severity: normal > > Client: jessie, just installed. > > I *randomly* (i.e. from 2 to 5 files at every apt-get update run) get > errors caused by apt issuing a range request for a file that it has > already received fully. > I am not sure about who is at fault between apt and apt-cacher: if > I issue the same range request to a normal mirror running Apache I get > back the same error.
Thanks, as far as I can see on a first look, apt-cacher is doing the right thing here. > Date: Wed, 12 Aug 2015 15:49:13 GMT > Via: 1.1 pxe.mil.seeweb.it:80 (apt-cacher/1.7.11) > Accept-Ranges: bytes > Age: 360 > ETag: "11a597-e59-51d18daedee40" > Server: Apache > Content-Length: 3673 > Content-Type: application/x-bzip2 > Last-Modified: Wed, 12 Aug 2015 08:17:53 GMT > > > Debug output: > > GET /debian/dists/jessie-updates/main/binary-amd64/Packages.bz2 HTTP/1.1 > Host: debian.seeweb.it > Cache-Control: max-age=0 > Range: bytes=3673- > If-Range: Wed, 12 Aug 2015 08:17:53 GMT > User-Agent: Debian APT-HTTP/1.3 (1.0.9.8) Request says if not modified since 12 Aug send bytes from 3673 > Answer for: > http://debian.seeweb.it/debian/dists/jessie-updates/main/binary-amd64/Packages.bz2 > HTTP/1.1 416 Invalid range: 3673- > Connection: Keep-Alive > Date: Wed, 12 Aug 2015 15:23:01 GMT > Accept-Ranges: bytes > Server: apt-cacher/1.7.11 > Content-Length: 0 > Content-Range: bytes */3673 apt-cacher replies no bytes beyond 3673 Or am I missing something? Rereading RFC 7233 the relevant bit is this: The 416 (Range Not Satisfiable) status code indicates that none of the ranges in the request's Range header field (Section 3.1) overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges. For byte ranges, failing to overlap the current extent means that the first-byte-pos of all of the byte-range-spec values were greater than the current length of the selected representation. When this status code is generated in response to a byte-range request, the sender SHOULD generate a Content-Range header field specifying the current length of the selected representation (Section 4.2). For example: HTTP/1.1 416 Range Not Satisfiable Date: Fri, 20 Jan 2012 15:41:54 GMT Content-Range: bytes */47022 Note: Because servers are free to ignore Range, many implementations will simply respond with the entire selected representation in a 200 (OK) response. That is partly because most clients are prepared to receive a 200 (OK) to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request until they have received a complete representation. Thus, clients cannot depend on receiving a 416 (Range Not Satisfiable) response even when it is most appropriate. I wonder if apt-get is not correctly handling the 416 response and doesn't realise that it means the file it has is complete as it stands? Mark
