1069 2005-01-31 20:11:33 +0000 validator redirected to http://localhost 2015-02-16 00:16:22 +0000 1 1 1 Unclassified Validator Parser 0.7.0 PC Windows XP RESOLVED FIXED http://actionhour.net/test2.html P2 normal --- 1 catblack ot customerservice plam www-validator-cvs oldest_to_newest 2930 0 catblack 2005-01-31 20:11:33 +0000 Hey there, noticed this on an implemention of a validator, and went to w3c to check there. Seems that when you have in an img tag, src="http://domain.com///path_to_file/file.jpg" the validator returns a 302 localhost error. Try this test page http://actionhour.net/test2.html 2931 1 ot 2005-02-01 03:29:53 +0000 (In reply to comment #0) > Seems that when you have in an img tag, > src="http://domain.com///path_to_file/file.jpg" the validator returns a 302 > localhost error. Do you have any conclusive sign that this behaviour only happens when the page contains an image? Here is the transcript of an HTTP session: % telnet actionhour.net 80 Trying 66.235.203.171... Connected to host219.ipowerweb.com. Escape character is '^]'. HEAD /test2.html HTTP/1.1 Host: actionhour.net User-Agent: W3C_Validator/1.305.2.148 libwww-perl/5.803 HTTP/1.1 302 Found Date: Tue, 01 Feb 2005 03:08:50 GMT Server: Apache/1.3.31 (Unix) mod_log_bytes/0.3 FrontPage/5.0.2.2635 PHP/4.3.10 mod_ssl/2.8.19 OpenSSL/0.9.7d Location: http://localhost/ Content-Type: text/html; charset=iso-8859-1 As you can see, it's the server that redirects, in a strangely broken manner, the page requested to http:/ /localhost. This is not the first time we get this "redirection to localhost" problem: http://lists.w3.org/Archives/Public/www-validator/2005Jan/0100.html http://lists.w3.org/Archives/Public/www-validator/2005Jan/0098.html % host actionhour.net actionhour.net has address 66.235.203.171 % host www.ezyworkathome.com www.ezyworkathome.com has address 66.235.203.80 These two are using the same ISP (iPowerWeb) % host www.falconberry.com www.falconberry.com has address 66.235.193.159 The third one was using a different ISP (Startlogic.com), contacted their tech support and apparently the issue is gone. All three are using the same server software: Server: Apache/1.3.31 (Unix) mod_log_bytes/0.3 FrontPage/5.0.2.2635 PHP/4.3.10 mod_ssl/2.8.19 OpenSSL/0.9.7d Either there is a version of apache with frontpage extensions being distributed that is broken (or comes with broken configuration defaults), or this is a new trend among Web Hosting companies. We'll have to contact these WebHosts to figure it out... 2933 2 ot 2005-02-02 05:06:00 +0000 Yet another report received from www.stuff4beauty.com (same network class as the others - 66.235.221.42). Cf. http://www.w3.org/Bugs/Public/show_bug.cgi?id=1070 2935 3 ot 2005-02-02 05:06:15 +0000 *** Bug 1070 has been marked as a duplicate of this bug. *** 2936 4 ot 2005-02-02 05:09:14 +0000 Assigning bug to myself. Goal is to figure out what the origin of this broken redirect is: - zealous web hosting admin trying to fend off robots? - broken apache bundle? broken apache module? 2937 5 customerservice 2005-02-02 05:20:52 +0000 I did contact my web hosting company, but the issue is not resolved. I still get a redirect on the validator 2939 6 customerservice 2005-02-02 05:32:51 +0000 (In reply to comment #5) > I did contact my web hosting company, startlogic.com - but the issue is not resolved. The report ticket I filed was disregarded as nothing wrong. I still get > a redirect on the validator 2940 7 customerservice 2005-02-02 17:41:40 +0000 Here is what I received from my hosting Co. Thank you for contacting StartLogic technical support. It looks like when you validate your URL the validator is redirecting it to localhost and checking the html validators page, which is why it reports XHTML. I can't imagine why it would be doing this but I can say with a fair amount of certainty that it is on the validators part as we dont redirect your website at all. 2941 8 customerservice 2005-02-02 17:42:37 +0000 Here is the response I received from my web hosting company: Thank you for contacting StartLogic technical support. It looks like when you validate your URL the validator is redirecting it to localhost and checking the html validators page, which is why it reports XHTML. I can't imagine why it would be doing this but I can say with a fair amount of certainty that it is on the validators part as we dont redirect your website at all. 2943 9 ot 2005-02-02 21:30:53 +0000 Your web host's tech support is, unfortunately, wrong. Compare the following two HTTP sessions. First session, with no particular user agent declaration... % telnet www.stuff4beauty.com 80 Trying 66.235.221.42... Connected to st01.startlogic.com. Escape character is '^]'. HEAD / HTTP/1.1 Host: www.stuff4beauty.com HTTP/1.1 200 OK Date: Wed, 02 Feb 2005 21:24:28 GMT Server: Apache/1.3.31 (Unix) mod_log_bytes/0.3 FrontPage/5.0.2.2635 PHP/4.3.10 mod_ssl/2.8.19 OpenSSL/0.9.7c Last-Modified: Wed, 02 Feb 2005 00:39:37 GMT Content-Type: text/html Second session with the validator's user agent string declared: % telnet www.stuff4beauty.com 80 Trying 66.235.221.42... Connected to st01.startlogic.com. Escape character is '^]'. HEAD / HTTP/1.1 Host: www.stuff4beauty.com User-Agent: W3C_Validator/1.305.2.148 libwww-perl/5.803 HTTP/1.1 302 Found Date: Wed, 02 Feb 2005 21:26:31 GMT Server: Apache/1.3.31 (Unix) mod_log_bytes/0.3 FrontPage/5.0.2.2635 PHP/4.3.10 mod_ssl/2.8.19 OpenSSL/0.9.7c Location: http://localhost/ Content-Type: text/html; charset=iso-8859-1 302 Found status code and a Location: header. That's a redirect. You should probably explain to your tech support that their server *does* a redirect, only based on some user agent string. And point them to http://www.w3.org/Bugs/Public/show_bug.cgi?id=1069#c9 (this comment) for more details. 4274 10 customerservice 2005-02-03 16:21:17 +0000 Yes, now they state they are at fault and here is the comment: Dear Client Thank you for contacting StartLogic technical support. Apparently the user agent for the w3 validator matches libwww-perl which is currently blocked as an emergency fix for the internet worms that were attacking websites which also reported as libwww-perl. Once out admins develop a more elegant solution to the problem the user-agent block will be removed but for now it will have to remain. 4206 11 link 2005-02-03 23:03:35 +0000 We've changed the code in the development version so it no longer identifies itself with the "libwww-perl" identifer (it now says only "W3C_Validator"). Could you all retest the pages you were having trouble with using the development version at <http://qa-dev.w3.org/wmvs/HEAD/>, and let us know whether this change fixes the problem? 4208 12 customerservice 2005-02-04 00:00:17 +0000 Yes, it works fine now. Thank-you 3903 13 ot 2005-03-18 06:35:11 +0000 Closing this bug, assuming that the issue has been fixed by the Web hosting services, and knowing that the issue is not present in dev version...