Testing Summary, Auckland - 26 May 2012

[Daniel Drake]

On Sun, Jun 3, 2012 at 5:53 AM, Tom Parker <tom at carrott.org> wrote:
> As reported last time and the time before, our yum problems persist. It seems the first invocation works but subsequent invocations do not. rpmdropbox.laptop.org is reporting what appears to be an incorrect content-type:
>
> $ echo "GET /f17/repodata/primary.xml.gz HTTP/1.1
> User-Agent: urlgrabber/3.9.1 yum/3.4.3
> Host: rpmdropbox.laptop.org
> Accept: */*
>
> " | nc rpmdropbox.laptop.org 80 |head -n 12
> HTTP/1.1 200 OK
> Date: Sat, 26 May 2012 00:58:23 GMT
> Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 proxy_html/3.0.0 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_wsgi/1.3 Python/2.5.2 mod_perl/2.0.2 Perl/v5.8.8
> Last-Modified: Thu, 24 May 2012 11:30:07 GMT
> ETag: "1ac806b-25d5-4c0c692df2dc0"
> Accept-Ranges: bytes
> Content-Length: 9685
> Content-Type: application/xml
> Content-Encoding: x-gzip
>
> ...
>
> Putting the same file on my own server yields an application/x-gzip content type and no content encoding.
>
> It’s not clear whether or how this is related to the problems we see with yum, perhaps there is a transparent proxy which is sometimes re-serving the decompressed content?


I haven't seen any yum problems, and I think you're the only ones who
have reported them, but I can reproduce the results of the nc run as
above.

Are you sure these http headers are wrong?

I filed a bug for this:
http://dev.laptop.org/ticket/11958

I agree with your suspicion that there's a confused transparent proxy
in the path somewhere. You're the only one to report yum issues, so I
think it is probably something localised to your part of the world.

Thanks
Daniel