Comment #3 on issue 20507 by [email protected]: non-ASCII encoding in  
URLs is incorrect
http://code.google.com/p/chromium/issues/detail?id=20507

[Sorry for the drive-by-debugging. I was looking for LTTF bugs, and since  
this seems to be somewhat dormant at the moment, I
thought I'll have a look.]

The problem with this layout test is the handling of the query and fragment  
parts of a URL: relative URLs should be handled the
same way as in Firefox. Also note, that the 'expected' file contains 'FAIL'  
lines (!), so we'll have to re-baseline the test in
any case if we want to fix the underlying issues.

.) The query part: This part is supposed to be encoded NOT in UTF-8, but  
with the underlying encoding. Chrome seems to handle
this ok, except if the query of the relative path is stand-alone (i.e.,  
without preceding path part), as with item 1. within the
layout test. In that case the encoding converter was omitted, which seems  
to be a bug - I uploaded a patch at:

     http://codereview.chromium.org/243028

.) The fragment part: The test requires this part to be percent-encoded for  
all non-ASCII and reserved characters, but Chromium
only does so for control characters. As this seems to be done quite  
deliberately, I haven't touched this part yet. It may be ok
to just re-baseline the test for this part, but OTOH changing it in order  
to increase compatibility with FF (and Safari) may be
worthwhile.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---

Reply via email to