Re: Is wise to use HTTP::Proxy to enforce correct Content-Range responses?

I think it would be better to persuade yum to interpret a 200 response to mean that the server could not complete the range request (in this case because it did not receive it), and has returned the complete content. It is common for content filtering proxies to strip range headers from requests, otherwise they could be effectively bypassed by a series of sufficiently small range requests.

Section 14.16 of RFC 2616 does not allow for proxies behaving in this way - if they are to function (and I think they are here to stay), the behaviour you are reporting is arguably the best available to them.

I'm sure there are enough people behind similar (possibly transparent) proxies to make accommodating this in yum worthwhile.

Comment on Re: Is wise to use HTTP::Proxy to enforce correct Content-Range responses?

Replies are listed 'Best First'.
Re^2: Is wise to use HTTP::Proxy to enforce correct Content-Range responses? by motobói (Beadle) on Apr 16, 2008 at 00:49 UTC
Yeah, it would be nice if one could persuade yum to do that. But, as wrote at http://wiki.linux.duke.edu/YumFaq , question 5: Q. 5: I get an "Errno -1 Header is not complete." error from yum - what the heck is going on? A. It's probably a proxy somewhere between you and the repository. You may not think that a proxy is in the way even though it really is. (...) The solutions to this problem are: - Get your proxy software/firmware updated so that it properly implements HTTP 1.1 - Use an FTP repository, where byte ranges are more commonly supported by the proxy - Create a local mirror with rsync and then point your yum.conf to that local mirror - Don't use yum	[reply]
Re^3: Is wise to use HTTP::Proxy to enforce correct Content-Range responses? by flipper (Beadle) on Apr 16, 2008 at 21:36 UTC
I think this is similar to the fuss about ECN in the Linux kernel - in an ideal world, everyone would follow the spec; in the real world, the yum developers are making life difficult for people behind these proxies, over which they may well have no control. See also Postel's prescription, TCP window scaling and standards mode - in this case I think that these proxies are not going to go away, and it's churlish not to work with them.	[reply]