588920 - CORS: simple POST request (application/x-www-form-urlencoded) is incorrectly getting preflighted

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Aseem Kishore]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.126 Safari/533.4
Build Identifier: Firefox 4.0b4pre (built Aug 19, 2010)

According to the spec, "simple" POST requests -- those that set no custom headers and use a standard Content-Type like "application/x-www-form-urlencoded" -- should not be preflighted. However, Firefox is preflighting such requests (with an additional OPTIONS request).

The URL I gave is a Stack Overflow post with detailed code. When I run this code in Chrome and Safari and even IE (using XDomainRequest), it works as expected, without a preflight request. When I run it in Firefox 3.6 as well as Firefox 4 beta 4, I can see a preflighted OPTIONS request in Fiddler.

Note that the URL I'm pinging in the code sends back Access-Control-Max-Age: 86400 which means that the preflight response is cached by Firefox for 24 hours. So make sure you have Fiddler open the first time you run this! Otherwise you need to wait a day to repro it again. (Clearing the Firefox cache didn't seem to clear this.)

Also note that you should run the code off an HTTP server, not the file system, because CORS explicitly disallows cross-scheme I believe.

Reproducible: Always

Steps to Reproduce:
1. Save the code in the Stack Overflow to a file.
2. Open Fiddler.
3. Run the saved file off an HTTP server.
Actual Results:  
When running in IE, Chrome or Safari, Fiddler shows only the POST request. When running in Firefox, Fiddler shows a preflighted OPTIONS request before the POST request.

Expected Results:  
Firefox shouldn't have preflighted the POST request with an OPTIONS request since the POST request is "simple" (no custom request headers, and a standard Content-Type.)

This seems like a major bug to me because a lot of us aren't able to go into our server-side code and add an entirely new OPTIONS path. POST requests should "just work" if they're simple and we're able to add the extra Access-Control-Allow-Origin response header.

Comment 1

[Aseem Kishore]

Attachment: The same code as the Stack Overflow post in an HTML file for convenience.

For convenience, I attached an HTML file with the same code as the Stack Overflow post. You can upload this to a server and run it with Fiddler open to see the preflighted request in Firefox.

Comment 2

[Aseem Kishore]

Attachment: Fiddler trace for Firefox

Attached Fiddler trace for Firefox. You can see the additional preflight OPTIONS request before the POST request.

Comment 3

[Aseem Kishore]

Attachment: Fiddler trace for Chrome/Safari

Attached the Fiddler trace for Chrome. No preflight request; just an OPTIONS request. This is the same behavior as Safari.

Comment 4

[Aseem Kishore]

Attachment: Fiddler trace for IE

Attached the Fiddler trace for IE, which requires XDomainRequest instead of XMLHttpRequest. XDR doesn't let you set the Content-Type in the request header, but the request still works, and isn't preflighted.

Comment 5

[Aseem Kishore]

It's been a while with no confirmation or acknowledgement, so I wasn't sure if maybe the component field was wrong. I also believe this occurs on all platforms; not sure why it said Windows XP. Thanks!

Comment 6

[Boris Zbarsky [:bzbarsky]]

I just tried that attached testcase; I don't see a preflight OPTIONS request happening, as expected....

Do you have Firebug installed, perchance?

Comment 7

[Aseem Kishore]

Hmm, I tried again (FF4b5) and I still see it.

Firebug 1.5.4 is indeed installed, but it's disabled because it claims it's incompatible with FF4b5.

My other enabled add-ons are AdBlock Plus 1.2.2, Feedback 1.0.3 (by Mozilla, presumably built-into FF4b5), FiddlerHook 2.2.9.8 and JSONView 0.5.

My other *disabled* add-ons are Download Statusbar 0.9.7.1, IE Tab 1.5.20090525, Linkification 1.3.8 and Xmarks 3.8.6.

I can try on a friend's machine or a fresh install sometime. Thanks!

Comment 8

[Boris Zbarsky [:bzbarsky]]

You can also just try in safe mode...  FiddlerHook is looking somewhat suspicious to me.

Comment 9

[Aseem Kishore]

Okay, will try tomorrow (after the 24 hour Access-Control-Max-Age expires). Just out of curiosity, what are you using to view the HTTP traffic? Without FiddlerHook enabled I'm not sure if Fiddler will work for Firefox.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Well... I personally just attached a debugger with a breakpoint where we send an HTTP request.  ;)  But the directions at https://developer.mozilla.org/en/HTTP_Logging should work for logging request/response headers, and in the past I've had good luck with Wireshark (http://www.wireshark.org/) for cases when I wanted to see the data too, not just the headers.

Comment 11

[Boris Zbarsky [:bzbarsky]]

In fact, I'd really appreciate either an HTTP log or a Wireshark trace of you reproducing the problem; that might just get us far enough.

Comment 12

[Aseem Kishore]

Will do! Thanks for your help so far.

Comment 13

[Aseem Kishore]

Attachment: HTTP log from Firefox

Cool, I followed the instructions in the HTTP Logging page and launched FF4b5 in safe mode to just the test page, and the generated log file is attached. I did a ctrl+F for "options" and indeed, there's an OPTIONS HTTP request! Thanks again for your help.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Ok, so that's telling us that the only reason we'd do a preflight here is if there are upload listeners (since no interesting request headers are set, and the type is correct).

Which brings me back to wondering about the fiddlerhook.  Did you ever get a chance to try without that?

Comment 15

[Aseem Kishore]

Hmm... I did this in safe mode, which disables all add-ons, so presumably FiddlerHook wasn't an issue?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Presumably, yes.  I assume that you quit Firefox before starting it in safe mode, etc?

In which case it's not clear what's going on....  Would you be willing to try a testing build with some additional logging added to it?

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Does this still happen with a recent nightly? Bug 597301 was checked in on October 4th and should have fixed this.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Ah, and I first looked at the code on Oct 6.  That would explain why I couldn't see a way for this to happen!

The old code was:

    if (!contentType.LowerCaseEqualsLiteral("text/plain")) {
      mState |= XML_HTTP_REQUEST_NEED_AC_PREFLIGHT;
    }

which would indeed lead to this bug.

Aseem, could you confirm with a recent nightly that this is fixed for you?

Comment 19

[Aseem Kishore]

Awesome! I tried with last night's build and indeed it works now. Thanks for looking into this!