This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
(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...
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
*** Bug 1070 has been marked as a duplicate of this bug. ***
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?
I did contact my web hosting company, but the issue is not resolved. I still get a redirect on the validator
(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
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.
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.
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.
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.
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?
Yes, it works fine now. Thank-you
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...