Comment 4 for bug 198138

This test is with the apt-cacher server still running on port 9999
--------------------------------
~ # wget http://apt-proxy.company.com:9999/ubuntu//dists/hardy/Release -O -
wget: no response from server
~ # wget http://apt-proxy.company.com:8738/ubuntu//dists/hardy/Release -O -
wget: Unable to connect to remote host (192.168.1.20): Connection refused

This is with the apt-cacher server running on 8738
--------------------------------
~ # wget http://apt-proxy.company.com:8738/ubuntu//dists/hardy/Release -O -
wget: no response from server

This is via Apache (apt-cacher install sets up "Alias /apt-cacher /usr/share/apt-cacher/apt-cacher.pl")
--------------------------------
~ # wget http://apt-proxy.company.com:80/apt-cacher/ubuntu//dists/hardy/Release -O - | grep ^Suite: | cut -d' ' -f 2
hardy

It appears to me that the problem isn't an endianness problem, but rather that the busybox implementation of wget had a regression between Gutsy and Hardy such that it no longer works with apt-cacher or apt-proxy since it doesn't believe it's getting a response from the server.

I ran tcpdump on the server. I ran "wget http://apt-proxy.company.com:8738/ubuntu//dists/hardy/Release -O -" from the installer's busybox. The request from the client:
GET /ubuntu//dists/hardy/Release HTTP/1.1

Host: apt-proxy.company.com

User-Agent: Wget

Connection: close

Then there's an ack back to the client, and then a FIN/ACK back to the client.

From an installed client, the request looks like this:
GET /ubuntu//dists/hardy/Release HTTP/1.0

User-Agent: Wget/1.10.2

Accept: */*

Host: apt-proxy.company.com:8738

Connection: Keep-Alive

HTTP/1.1 200 OK
Connection: Keep-Alive

Accept-Ranges: bytes
Content-Length: 65852
Content-Type: text/plain; charset=UTF-8
Last-Modified: Fri, 18 Apr 2008 16:46:10 GMT
...