Open
Bug 1453060
Opened 6 years ago
Updated 2 years ago
xhr readyState is 4, but status remains 0 (when using xhr to send a multipart/form-data request)
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
UNCONFIRMED
People
(Reporter: aug828, Unassigned)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce: [Part 1] Client side: use xhr to send a multipart/form-data request // index.html <html lang="en"> <head> <meta charset="UTF-8"> <title>Demo XHR</title> </head> <body style="alignment: center"> <input type="file" id="input" onchange="handleFiles(this.files)"> <script type="text/javascript"> handleFiles = function (files) { console.log(files[0]); if ( window.FormData ) { var fd = new FormData(); fd.append("file", files[0]); var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { console.log(xhr); }; xhr.open("POST", "xhr"); // submitting the form xhr.send(fd); } } </script> </body> </html> [Part 2] server side handle the request @Controller public class XhrController { @RequestMapping(method = RequestMethod.POST, value = "/xhr") @ResponseBody String xhr(HttpServletRequest request, HttpServletResponse response) throws IOException { response.setStatus(HttpStatus.FORBIDDEN.value()); return "Firefox XHR!"; } } [Part 3] Use the debugger to check xhr objects: readyState, status, responseText, etc. Actual results: Correct situation: when xhr.readyState is set to 4, xhr.status is set to 403 (or whichever the server sends back). Incorrect situation: when xhr.readyState is set to 4, its status remains 0. Which situation happens depends on the file size and how fast the network is. Further investigation using WireShark: Correct situation: Firefox managed to transfer the whole file before the server can respond. In this case, Firefox can figure out the correct response code. Incorrect situations: Firefox can't transfer the whole file before the server respond with a 403 or 500 (or other http status code). We will see a "[TCP Window Full]" frame, followed by a "[TCP ZeroWindow] HTTP/1.1 ***" frame (*** could be 403 or 500 or other http status code). Eventually, we will see a "[RST]" frame from the server to the client. In this case, Firefox can't figure out the correct response code; we can see that it is right there, in the "[TCP ZeroWindow] HTTP/1.1 500" frame. The "[TCP ZeroWindow] HTTP/1.1 ***" frame is key to reproduce this bug. Expected results: I am expecting xhr.status to be set to a correct status code when readyState is 4 in all situations. I also tested on Chrome. Chrome doesn't have this problem.
Just a blind shot: maybe Firefox couldn't figure out how to parse "[TCP ZeroWindow] HTTP/1.1 ***" frame.
Updated•6 years ago
|
Component: Untriaged → Networking
Product: Firefox → Core
Updated•6 years ago
|
Component: Networking → DOM
Updated•6 years ago
|
Priority: -- → P3
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•