Jesse Keating wrote:
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 ?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 FoundThrowing 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?
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.