Last Comment Bug 532378 - A cross site URL-encoded XMLhttp POST request generates a preflighted (OPTIONS) request
: A cross site URL-encoded XMLhttp POST request generates a preflighted (OPTION...
Product: Core
Classification: Components
Component: XML (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2009-12-02 05:20 PST by Frank van Beek
Modified: 2011-08-18 01:17 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Example HTML file (1.85 KB, text/html)
2009-12-02 05:22 PST, Frank van Beek
no flags Details

Description Frank van Beek 2009-12-02 05:20:57 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20091102 Firefox/3.5.5

When sending an cross site domain POST request with an application/x-www-form-urlencoded Content-Type, the request becomes preflighted. This contradicts the documentation in .

Reproducible: Always

Steps to Reproduce:
1. Open the uploaded example file
2. Click on the 'URL encoded post' button

Actual Results:  
An OPTIONS (prefilghted) request is send.

Expected Results:  
A normal POST request should be send.
Comment 1 Frank van Beek 2009-12-02 05:22:29 PST
Created attachment 415618 [details]
Example HTML file
Comment 2 Jonas Sicking (:sicking) 2009-12-02 09:46:51 PST
Yeah, I decided to be a bit stricter than the spec here. My concern was that while you can send cross-site application/x-www-form-urlencoded requests right now, they can't be arbitrarily formatted. So possibly allowing arbitrary formatting could expose security issues in servers.

Though probably that is overly paranoid.
Comment 3 Frank van Beek 2009-12-03 03:58:02 PST
I understand your concerns now. A very funny XKCD strip comes to mind: . :)

As you have clearly put a lot more thought into this than I have, I leave it up to you to decide to mark this bug as a 'Won't fix' or not.
Comment 4 unordained_mozilla 2010-04-15 19:52:57 PDT
Nice to know that I'm not crazy, you're just not following the spec. I couldn't figure out why, when all I was changing was the content-type, requests suddenly got preflighted. I disagree with your paranoid decision on the following grounds:

a) Some server software is built to specifically use x-www-form-urlencoded. That happens to be our scenario.

b) Not everyone can deal with pre-flighting. In our case, the destination server has a security model (yay for IIS) that applies to all requests -- GET, POST, and OPTIONS alike. The browser refuses to follow-up on a preflight if the OPTIONS request comes back with a 401 Unauthorized, which was sent because the server is trying to initiate NTLM authentication. So we need a solution that avoids pre-flight, if we want to avoid writing a whole filter/module just to bypass security just on OPTIONS requests, just so we can get FF to finish what it started. Or you could make FF allow for 401-NEGOTIATE responses, negotiate all the way through the OPTIONS request, get permission, then make the actual request. I wouldn't mind, though it's not ideal either.

c) You're not protecting the server anyway. It's always been possible for someone to attack a server with spoofed, malicious requests, and if they couldn't handle x-www-form-urlencoded before, this isn't opening them up to anything new.

d) There's a spec. The spec says this should be allowed.

e) Your own documentation says it's allowed, which drove me absolutely batty trying to diagnose this:

f) I like XKCD as well as the next guy, but ... please? Pretty please fix this?

Side note: we discovered that .withCredentials doesn't just mean "if the server asks for them, send them" -- it means "the server should ask you, and if it doesn't, refuse to finish the request you preflighted". That's confusing. Luckily, everything we talk to should ask for credentials, otherwise we'd be having to turn this flag on/off all over the place.
Comment 5 Frank van Beek 2011-08-18 01:14:06 PDT
This seems to be fixed in Firefox 4. See:

Starting in Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1), the text/plain, application/x-www-form-urlencoded, and multipart/form-data data encodings can all be sent cross-site without preflighting. Previously, only text/plain could be sent without preflighting.

I just checked it with Firefox 5 and everything seems to be working as expected. Please close this bug.
Comment 6 Jonas Sicking (:sicking) 2011-08-18 01:17:10 PDT
Done and done. This is indeed fixed.

Note You need to log in before you can comment on or make changes to this bug.