Closed Bug 532378 Opened 13 years ago Closed 11 years ago

A cross site URL-encoded XMLhttp POST request generates a preflighted (OPTIONS) request


(Core :: XML, defect)

Windows XP
Not set





(Reporter: frank.van.beek, Unassigned)



(1 file)

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.
Attached file Example HTML file
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.
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.
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.
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.
Done and done. This is indeed fixed.
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.