--- Comment #3 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-08-03 
04:07:46 PST ---
(In reply to comment #2)

Thanks for supplying the additional info.

<snip /> 
> Ooops, sometimes I forget this "other" operating system :-), now I understand
> the code. And I also think that my patch (see comment #0) will fix this issue,
> cause it only changes the behaviour of URLs with protocol != "file:".

Somewhat of a nit, I think the suggested fix is, strictly speaking, not
sufficient. The related portion of code is, as the preceding extensive comment
explains, more or less a forced construction to retain backward compatibility
with older parsers. The example URL 'file:c:\...' is not invalid according to
RFC1630, provided the base URL is 'file:/'.

Strictly speaking, I think the behavior should apply to other protocols as
well, so simply bypassing the entire check for non-file URLs would not be the
right choice. Even if the code-block does not contain any code yet for other
protocols, I'm not sure we may simply exclude that.

I suggest changing:

if (href.startsWith(scheme)) {
  href = href.substring(...


if (href.startsWith(scheme)) {
  String tmp = href.substring(...

Then use the tmp variable further down when prepending the missing slash.

That way, if the protocol is something else than 'file:', at least the original
href does not get corrupted.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to