Jesse Keating wrote:
On Fri, 2006-06-09 at 22:00 +1000, David Timms wrote:
> Note all the stuff in the actual header, especially:
> HTTP/1.1 404 Not Found
> Throwing away the header that has the correct info in it is what is
> going wrong. From what someone said urlgrabber is used in yum ->
> shouldn't urlgrabber then return fail if the server is stating html
> errors eg 404, no matter how pretty the 404 looks to a human using
> their
> web browser ?
Didn't Seth say that f.r.c was fixed and thus would not make a very good
test case?
Agreed. That would be why I included the problem {pacific internet} from
Sean's report. Also the mentioned ~"302 and redirect" is another html
response ie not 200. So could someone list the settings that would have
caused the 200+text404 response, so that it could be used as an
additional test case ?
Still, it would be great to solve the garbage in {=dodgy repodata} >
getting stuck problem. Looking for well formed xml in the data appears
to be a good place to start, should be seeing:
<?xml version="1.0" encoding="UTF-8"?>
<repomd
xmlns="http://linux.duke.edu/metadata/repo"> ...
DaveT.