This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Description ----------- When the checker encounters links whose supposedly-valid URI actually violates RFC 2396, and in particular links such as: <a href="javascript:foo()">Javascript link</a> ... a dummy URI is created of the form: http://example.org/#[encoded invalid URI] I suppose there is a good reason for that, be it only to maintain the list of invalid links. The problem is that this URI gets requested by the checker. Most of the time, this has no visible effect. It's just "dirty". But if you switch your Internet Connection down, and work with a local server, an HTTP_RESPONSE-1 FAIL will be returned: <result name="HTTP_RESPONSE-1" outcome="FAIL"> <info>FAIL: The request to the resource http://example.org/#javascript[...] does not result in a valid HTTP response (because of network-level error, DNS resolution error, or non-HTTP response)</info> </result> (a LINK_TARGET_FORMAT-1 WARN is also returned) How to reproduce ---------------- - remove the ethernet cable or switch off your Wifi connection - run the checker on a local server: http://localhost:[port]/[path to tests]/ObjectsOrScriptTest/1/index.xhtml Code ---- The resource is requested while building the moki document: PreprocessorResults.java buildMokiDocument loops through the links calls addRetrievalElement for each of them Possible solutions ------------------ 1. get rid of this dummy URI, but it may be unnecessarily complicated since HTTPResource.parseURI is to return a URI 2. make sure that the checker does not resolve dummy links.
Dummy URIS now are changed to null values and are filtered in Preprocessor.