[webkit-dev] Passing null or undefined object as input url for XMLHttpRequest open()

[Glenn Adams]

On Wed, Sep 5, 2012 at 12:10 AM, Joshua Bell <jsbell at chromium.org> wrote:

>
> On Tue, Sep 4, 2012 at 8:32 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
>>
>> 04.09.2012, в 07:43, Pozdnyakov, Mikhail написал(а):
>>
>> req = new XMLHttpRequest();****
>> req.open(“GET”, null);  ****
>> ** **
>> the implementation of XMLHttpRequest  will try to open URL:****
>> “<base URL>/null“. The similar behaviour is with an undefined object given
>> ****
>> as input url (will try to open “<base URL>/undefined“).****
>> ** **
>> It does not seem to be correct behaviour and I would raise SYNTAX_ERR
>> exception****
>> in such cases, but I would like to hear other opinions on that before
>> creating bug and uploading patch.
>>
>>
>> This is an unlikely situation to occur in real web pages, so there is
>> neither much risk nor much benefit to this change. One way this could break
>> a page is if it calculates a URL and erroneously ends up with a null. In
>> this case, raising an exception would further break page logic - instead of
>> getting error and loaded events, it will likely be stuck waiting for these
>> forever.
>>
>> Could you elaborate on why this seems incorrect to you? Generally
>> speaking, special casing just null and undefined to bypass toString
>> conversion would be unusual and surprising.
>>
>
> Indeed - the WebIDL for the open method is in:
>
>
> http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#interface-xmlhttprequest
>
> The spec doesn't special case null, so coercing the |url| argument via
> ToString() to the DOMString "null" is correct.
>
> There are several places in the platform where there are special cases for
> null/undefined/etc for backwards compatibility with the Web, but it appears
> this isn't one of them.
>
> Has the original poster compared behavior in other browsers? If other
> browsers handle this differently than WebKit and the spec, then it should
> be raised on public-webapps as a spec issue.
>

A spec change could fix this easily by adding [TreatNullAs=EmptyString] to
the url parameter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120905/151c910a/attachment.html>