Closed Bug 723805 Opened 12 years ago Closed 7 years ago

XMLHttpRequest sends "OST", instead of "POST", when send() is a File.

Categories

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

10 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: tim, Unassigned)

References

()

Details

Summary: When a XmlHttpRequest is open()'ed using the method POST, and the xhr.send() method is sending a DOM "File" object, the server receives "OST" as a method, causing a Status 501.

Steps to reproduce:
1. visit my website (www.wipnation.com) and sign up(or log in if already signed up)
2. back on the main page (/ or /index.jsp), click on +Post Art, which is near the top middle of the webpage
3. on the resulting page, press 'Browse..."
4. pick a JPEG or PNG file from your disk.
5. press "Open"

Results: my Tomcat 6 server reports Status 501 error code (visible in logs/firebug output)

I'll try to make a file upload test page that won't require a login within 48 hours.

Log attached, see lines 73812(POST)  and 74042 (Status 501)

Does not happen on other browsers, or FF9. 
Cannot confirm other OSes.
My site has not had code changed on it for about 3 weeks. This bit of code  has been working since FF 3.6/4 (July 2011)
Apparently, attachments won't work in ff10 on bugzilla. :/ Trying chrome.
Component: General → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: general → general
Hmm.  This is an https URI, right?  This may be an instance of bug 702111.  Can you check whether setting NSS_SSL_CBC_RANDOM_IV=0 in your environment fixes the problem for you?
Though if that were the case then recent enough Chrome builds would have the same problem...
I verified it is caused by the 1/(n-1) record splitting.

I remember that Adam Langley said that Chrome would soon switch to doing record splitting more like Firefox, but the problem doesn't occur in Chrome release or Chrome Canary.
So we certainly do record splitting since Chrome 16, but there are some differences with POSTS.

In 16 we'll send a split record (so, 2 records) for the headers and another packet with a split record for the body.

In 17+ we'll merge the body into the headers if the sum is < 1400 bytes and so there'll be only a single packet with two records. I believe that's Firefox's behaviour today.
(And, to be clear, the splits are 1 byte and the rest of the bytes, same as FF10.)
Component: DOM: Mozilla Extensions → DOM
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.