W3C home > Mailing lists > Public > public-html@w3.org > June 2008

Re: URIs in HTML5 and issues arising

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 29 Jun 2008 13:11:19 -0700
Cc: Philip Taylor <pjt47@cam.ac.uk>, Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
Message-Id: <FECA1DFF-F998-412A-B1B8-90DDDD591383@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>


On Jun 29, 2008, at 5:11 AM, Julian Reschke wrote:

>
> Philip Taylor wrote:
>> Ian Hickson wrote:
>>>> According to <http://lists.w3.org/Archives/Public/public-html/2008Jun/0358.html 
>>>> >, Safari 3 uses question marks.
>>>
>>> According to:
>>>
>>>   http://hixie.ch/tests/adhoc/uri/encoding/017.html
>>>
>>> Safari trunk uses &-escaping.
>> That says "Query component: raw question mark" in Safari 3.1.2.
>> It says "Query component: %-escaped ASCII &#9786;" in nightly  
>> WebKit r34603.
>> Looks like it changed in https://bugs.webkit.org/show_bug.cgi? 
>> id=15119
>
> Interesting.
>
> I'm not sure why the Webkit guys think this is any better then what  
> FF does... Which, quoting <https://bugs.webkit.org/show_bug.cgi?id=15119#c1 
> >: "amusingly gives the "correct" answer for Google".

I didn't follow this issue when it was originally raised, and it does  
seem strange at first not to match other browsers.

However, as the bug report states, the motivation for the WebKit  
behavior was to match what happens when the query part of the URL is  
generated by a form submission. In that case all browsers use entity  
escaping. It was seen as desirable to make a URL with invalid  
characters already in the query get encoded the same as a URL where a  
query that calls for those characters was escaped by the form  
submission code. I believe all browsers do this kind of escaping as  
part of form submission.

The bug has an illustrative test case: <https://bugs.webkit.org/attachment.cgi?id=16166# 
 >

Regards,
Maciej
Received on Sunday, 29 June 2008 20:12:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC