[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#705648: if-modfied-since undhandled case causes apt lists corruption



Package: apt-transport-https
Version: 0.8.16~exp12
Tags: patch

When using an https repository, apt will use libcurl to download
files, setting the If-Modified-Since herder in the http request.

If the server replies with a 200 OK but a Last-Modified header with a
date that is not newer that the requested If-Modified-Since, libcurl
drop the file, reporting an errorcode 200, but the actual downloaded
file will be empty.

Causing messages like
W: Size of file
/var/lib/apt/lists/partial/repo.server.com_dists_precise_main_binary-amd64_Packages
is not what the server reported 0 25118

See the attached patch that fixes the issue.

Apt needs to check the CURLINFO_CONDITION_UNMET to know if libcurl
discarded the payload.
Also TotalSize will get updated to the actual size of the file as
progress_callback will be called with the download size even in the
case libcurl decides to discard the payload. This will cause the check
for the size to fail. In my patch I just disable the check if the
actual size of the file is 0. Probably a better way would be adding a
new header is the message from the worker stating that the file was
discarded.

The cases why the http server would give this kind of response are, e.g.
1) if-modified-since used like a etag header
http://trac.nginx.org/nginx/ticket/93

(under this light, it might makes sense to avoid using the
CURLOPT_TIMECONDITION feature and handle If-Modified-SInce as an Etag)

2) a bug in apt-cacher-ng which sometimes returns 200 OK with a
Last-Modified equal to Last-Modified (about to be reported)

This bug is present at least as far back as version 0.8.16~exp12 and
still affects the latest in experimental (0.9.7.9~exp3). The attached
patch is for 0.9.7.9~exp3.

Cheers,
Ludovico

Attachment: check-time-condition.patch
Description: Binary data


Reply to: