Open
Bug 1453060
Opened 7 years ago
Updated 1 year ago
xhr readyState is 4, but status remains 0 (when using xhr to send a multipart/form-data request)
Categories
(Core :: DOM: Networking, defect, P3)
Tracking
()
UNCONFIRMED
People
(Reporter: aug828, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(4 files)
TCP ZeroWindow.png
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•7 years ago
|
Component: Untriaged → Networking
Product: Firefox → Core
|
||
Updated•7 years ago
|
Component: Networking → DOM
|
||
Updated•7 years ago
|
Priority: -- → P3
|
Assignee | |
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
|
||
Updated•3 years ago
|
Severity: normal → S3
|
||
Comment 5•1 year ago
|
||
Moving the component;I am not sure if it's still valid.
Severity: S3 → --
Component: DOM: Core & HTML → DOM: Networking
Priority: P3 → --
|
||
Updated•1 year ago
|
Severity: -- → S3
Priority: -- → P3
Whiteboard: [necko-triaged][necko-priority-new]
You need to log in
before you can comment on or make changes to this bug.
Description
•