[webkit-dev] Passing null or undefined object as input url for XMLHttpRequest open()
Joshua Bell
jsbell at chromium.org
Tue Sep 4 09:10:26 PDT 2012
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120904/9e97d4c1/attachment.html>
More information about the webkit-dev
mailing list