Re: prohibited code points and error handling in Chrome and MSIE

I forgot to include results for the authority processing test case 
<http://&#xfdd0;zyx.com> related to my IDNA comment.  The comparison 
with the path processing may be interesting as well, considering 3987bis 
does not allow U+FDD0 in IRIs.

<a href='http://&#xfdd0;zyx.com' id='69'>69</a><img 
src='http://&#xfdd0;zyx' />

Scheme  Host    Path    Query     RawUrl                   Browser
http:                   ?zyx.com  http:///?zyx.com         MSIE 8.0
:                                 http://%EF%BF%BDzyx.com/ Chrome/12
http:   ﷐zyx.com /               http://﷐zyx.com/        Firefox/4.0.1
http:            /                                        Safari/5.0.5
opera:          illegal-url-41    http://﷐zyx.com         Opera/9.80


Best regards,
-Chris


On 7/3/2011 5:47 PM, Chris Weber wrote:
> I'm curious about a test case that caught my attention:
>
> (<a href='http://example.com/&#xfdd0;foo' id='302'>302</a><img
> src='http://example.com/&#xfdd0;foo' />)
>
> For Chrome - do you know if this result is the way an IRI parsing should
> get represented in the DOM? This seems to be the same result in other
> test cases such as <http://&#xD87E;&#xDC68;.com> as well. But it also
> happens with URI cases as well <http://[::eeee:192.168.0.1]/>
>
> For IE - is the transformation of U+FDD0 to a "?" an expected handling
> of prohibited characters or another fallback path? Transformations like
> these seem dangerous for security reasons, e.g. bypassing filters.
>
> U+FDD0 is prohibited under IDNA2003's nameprep step, and disallowed by
> IDNA2008. The results below are from the DOM parsing.
>
> Scheme Hostname Path Query Browser
> : Chrome/12.0
> http: example.com /%EF%B7%90foo Opera/9.80
> http: example.com ?zyx MSIE 7.0
> http: example.com ?zyx MSIE 8.0
> http: example.com /%EF%B7%90foo Firefox/4.0.1
> http: example.com /﷐foo Safari/5.0.5
>
>
> The raw HTTP request results for the <img> are as follows. The only
> exception was that Chrome did not make the request for the <img>.
>
> Path Browser
> /%EF%B7%90foo Opera/9.80
> /?foo MSIE 7.0
> /?foo MSIE 8.0
> /%EF%B7%90foo Firefox/4.0.1
> /%EF%B7%90foo Safari/5.0.5
>
> Although Chrome did not make a request for the <img>, the <a> link is
> still clickable and resolves to the percent-encoded Unicode replacement
> character U+FFFD in the path "/%EF%BF%BDfoo".
>
>
> Best regards,
> Chris
>

Received on Monday, 4 July 2011 06:42:59 UTC