This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7181 - A leading space in an image "src" attribute with an absolute URI makes the Checker crash
Summary: A leading space in an image "src" attribute with an absolute URI makes the Ch...
Status: RESOLVED FIXED
Alias: None
Product: mobileOK Basic checker
Classification: Unclassified
Component: Java Library (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: fd
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-31 14:35 UTC by fd
Modified: 2009-08-03 15:41 UTC (History)
0 users

See Also:


Attachments

Description fd 2009-07-31 14:35:42 UTC
The Checker crashes when an img element contains a src attribute that starts with a space:
 <img src=" http://example.org/img.gif" />

The problem occurs typically when checking:
 http://imdb.com/

The URI in the above example is invalid, AFAICT, i.e. there should not be any trimming involved when parsing a URI defined in an attribute.

The Checker should rather:
1. ignore the URI following the usual rules implemented in the Checker (" http" is not a supported scheme).
2. report a validation error somehow, but the XHTML validator does not seem to complain about that.

Note Resource.parseUri should already return "null" in that case, so the image must not be listed in the images section of the moki document.

The crash occurs when the ImagesSpecifySizeTest XSLT stylesheet is applied because we end up with a call to moki:resolve-uri with the value of the src attribute in the end. Such a call should not be triggered on invalid URIs!
Comment 1 fd 2009-08-03 15:41:59 UTC
The real issue was slightly more generic than the title of the bug: all pieces of XSLT code that need to resolve URIs directly by having a look at the received XHTML code are exposed to the problem.

There is no easy way to check whether a string is a valid URI in XSLT, and no way to catch the underlying error returned by the call to resolve-uri. The only thing to do is to implement a isValidUri extension function in Java that does the trick and subsequently call it from the XSLT. Sigh.

Resource.isValidUri function implemented and used in "moki:get-retrieved-resource".