Acquire::http::proxy breaks things with apt proxies like apt-cacher

Bug #55813 reported by Andres Salomon
2
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
New
Undecided
Unassigned

Bug Description

Dapper's apt-setup puts the following line in /etc/apt/apt.conf:

Acquire::http::Proxy "false";

When using official Ubuntu mirrors, this works just fine. However, when using a local cache (via apt-cacher or approx), this line causes 'apt update' to fail in the following manner:

[...]
Err http://zanzibar.ne.in.athenacr.com dapper/main Packages
  403 Forbidden
Err http://zanzibar.ne.in.athenacr.com dapper/restricted Packages
  403 Forbidden
[...]
Failed to fetch http://zanzibar.ne.in.athenacr.com:9999/ubuntu/dists/dapper/main/binary-i386/Packages.gz 403 Forbidden
Failed to fetch http://zanzibar.ne.in.athenacr.com:9999/ubuntu/dists/dapper/restricted/binary-i386/Packages.gz 403 Forbidden
[...]

Wget'ing that file works just fine (no 403 - forbidden), and if I comment out the Acquire::http::proxy line in /etc/apt/apt.conf or set it to "" instead of "false", then 'apt-get update' works.

Revision history for this message
Andres Salomon (dilinger-deactivatedaccount) wrote :

Actually, it looks like this is the same as http://bugs.debian.org/378868. Tcpdumping shows apt in dapper using the full server name in its GET string, which confuses approx (which is not an HTTP proxy, it is a normal web server which just happens to fetch and cache debian packages).

Apt shouldn't be doing this when Acquire::http::proxy == "false", and dapper's apt-setup probably shouldn't be setting Acquire::http::proxy at all in apt.conf when there is no proxy.

Revision history for this message
Andres Salomon (dilinger-deactivatedaccount) wrote :

Here's a fix for apt. Basically, the URI class tests whether or not it's epmty by checking whether the Access string (ie, "http") is empty. The only URI methods where that's actually the case are "file" and "copy"; the rest require both the Access string and the Host string.

So, the attached patch changes URI::empty() to check if the Access and Host strings are empty; if either of them are, then consider the URI to be empty. Special case "file" and "copy", allowing them to have an empty Host string.

A better fix might be to drop URI::empty altogether, and have the individual methods check whether or not they've been fed a valid string. That would be a much larger fix though.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.