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)

59 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: aug828, Unassigned)

Details

Attachments

(4 files)

Attached image 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.
Attached image TCP RST.png
Attached image incorrect.png
Attached image correct.png
Just a blind shot: maybe Firefox couldn't figure out how to parse "[TCP ZeroWindow] HTTP/1.1 ***" frame.
Component: Untriaged → Networking
Product: Firefox → Core
Component: Networking → DOM
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: