[whatwg] IRIs and javascript: scheme

[Shadow2531]

On 10/18/06, Christian Schmidt <whatwg.org at chsc.dk> wrote:
> Most modern browsers support the following:
> <a href="javascript:alert(123)">foo</a>
>
> AFAICS "javascript:alert(123)" is not a valid IRI according to RFC 3987
> (it should be "javascript:alert%28123%29" instead) and is thus not
> allowed in an <input type="url"> field. This is somewhat surprising to
> me, and I think it will confuse users that they now have to manually
> escape their javascript: URLs when entering them in url input fields.

In Opera, if you do <input type="url" name="test"
value="javascript:alert(123)">, you won't be able to submit because
the parenthesis are not encoded. You have to make sure the "(" and ")"
are encoded so that the server gets javascript%3Aalert%2528123%2529,
so that when your server script decodes the data, it gets
javascript:alert%28123%29.

That makes sense to me. After your script decodes the data sent to it,
you should get a properly encoded IRI.  That won't happen if ( and )
are not represented as %28 and %29 before submitting.

If you want to allow the ( and ) to be raw before submitting, might as
well use type="text".

So, I think type="url" needs to be that strict and I think it should
require properly encoded IRIs as input.

That is a problem though as most bookmarklets ( for examlple)  are not
encoded properly, but still work, so people don't encode them or have
no clue how.

There are tools for that though.  I have
<http://shadow2531.com/opera/js/uris/jsuri.xhtml> for example that
I've been messing around with.  It uses encodeURIComponent though and
doesn't get the ( and ), but the point is, tools can be made.

Also, you could probably dynamically encode raw text  with JS as it's
entered in type="url", so it is submitted right.

So, that's just my take on why unescaped data should not be allowed.

-- 
burnout426