Closed Bug 786601 Opened 12 years ago Closed 12 years ago

XMLHttpRequest.open with certain characters in request URL throws 0x805e0006

Categories

(Core :: JavaScript Engine, defect)

15 Branch
All
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: korbinian.abenthum, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

During ajax development I encountered an Exception in XMLHttpRequest.open when a certain Arabic word is passed as part of the request URL. According to Google Translate it is 'Freedom' in Arabic, i.e. a normal word that occurs in the wild and will cause AJAX calls to fail. Opening the URL in the Browser directly works without problems. I noticed the problem in Firefox 14.0.1 and 15, it works without issues in IE8 and Chrome 20

Exception text in the console:
[Exception... ""  nsresult: "0x805e0006 (<unknown>)"  location: "JS frame :: Web Console :: <TOP_LEVEL> :: line 1"  data: no]

To reproduce, execute the following call in your javascript console:
new XMLHttpRequest().open("GET","حرية");

Exact request URL doesn't matter, when I encountered the issue the above word was a URL-encoded query parameter value. Shorter, but still valid UTF8:
new XMLHttpRequest().open("GET","%D8%AD%D8%B1");

In fact, the shortest problem url I found (which however is no longer valid UTF8) is
new XMLHttpRequest().open("GET","%AD%00");
Second byte doesn't seem to matter, AD ** seems to cause the exception. I could understand some kind of exception with invalid UTF8 of course, just adding this in case it helps.
[Exception... "The URI is malformed"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: Web Console :: <TOP_LEVEL> :: line 1"  data: no]
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: Untriaged → JavaScript Engine
Ever confirmed: true
Product: Firefox → Core
(In reply to Ioana Budnar [QA] from comment #1)
> [Exception... "The URI is malformed"  nsresult: "0x804b000a
> (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: Web Console :: <TOP_LEVEL>
> :: line 1"  data: no]

I get the above exception when evaluating "new XMLHttpRequest().open("GET","حرية");" in the Web Console on the 08/29 Firefox 18 build.

Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/18.0 Firefox/18.0 (20120829030520)
Hardware: x86_64 → All
Would you be willing to attach a web page that shows the problem for you?  I'm trying to reproduce using the steps from comment 0, but I don't get any exceptions.
WOW ... I did not expect that. Apparently, the "%AD" in the encoded URL triggers some Adblock Plus rule which in turn causes the exception.

Since you couldn't reproduce it, I did a lot more testing. In the end, after installing the nightly, creating a new profile, installing adblock, I couldn't reproduce the problem. When I copied the filter files from my original profile over, I got the exception again. Apparently, I created or imported an oversensitive filter at some point in the past, and adblock stops the request with a quite meaningless exception. It sounds likely that it's the encode %AD.

So sorry to have wasted your time with this, I'll make sure next time to test any presumed errors in a clean installation. :(
Korbinian, thank you for retesting that!

Ioana, do you also have Adblock Plus involved here?
(In reply to Boris Zbarsky (:bz) from comment #5)
> Ioana, do you also have Adblock Plus involved here?

I get the same Output as in Comment 2 on a Nightly Build without any Extensions in Safemode.
On which OS?  With which exact steps to reproduce?
(In reply to Boris Zbarsky (:bz) from comment #7)
> On which OS?  With which exact steps to reproduce?

de-DE Windows 7 x64 running a x86 en-US Nightly (tried also a de-DE 15 Release Build)

STR are as stated in Comment 0:
* Firefox + new Profile (Safemode optional)
* open built-in Webconsole
* enter String "new XMLHttpRequest().open("GET","حرية");" + Enter
What page is in the tab when you do that?
Ummpf, about:home.

Now, that you asked I tested also other about: Pages what give the same Output.

=> on a non about: Pages (also locally opened) it returns "undefined".
Aha.  On about:home, I can reproduce.

But that's because you're trying to create a relative URI with about:home as a base URI, and that's not possible, obviously!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.