W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: XDomainRequest Integration with AC

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 20 Jul 2008 15:31:33 -0700
Cc: Ian Hickson <ian@hixie.ch>, Sunava Dutta <sunavad@windows.microsoft.com>, "annevk@opera.com" <annevk@opera.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Zhenbin Xu <Zhenbin.Xu@microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Message-Id: <54746FBC-3574-4F78-ABD3-7E11FE237E12@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On Jul 20, 2008, at 12:09 PM, Jonas Sicking wrote:

> Ian Hickson wrote:
>> On Sat, 19 Jul 2008, Jonas Sicking wrote:
>>> According to the HTML5 spec space is a valid characted inside URLs.
>> That wasn't intentional -- can you point to where it says that? The  
>> HTML5 spec relies on spaces not being allowed in URLs in various  
>> places.
> In section 2.3.2 (Parsing URLs):
> # Add all characters with codepoints less than or equal to U+0020 or
> # greater than or equal to U+007F to the <unreserved> production.
> And RFC 3986 says:
> # Characters that are allowed in a URI but do not have a reserved
> # purpose are called unreserved.  These include uppercase and  
> lowercase
> # letters, decimal digits, hyphen, period, underscore, and tilde.
> #
> #     unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

That rule is about what conforming HTML5 UAs must do when processing a  
URL with error handling, it does not change what is a valid URI. In  
any case, even if we use the HTML5 parsing algorithm, splitting on  
whitespace before applying it should work. And finally, since we are  
not allowing a path, the main convenience reason for the error  
handling accepting spaces is gone.

Received on Sunday, 20 July 2008 22:32:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC