Closed Bug 1134309 Opened 9 years ago Closed 9 years ago

[e10s] Bad (omitted?) request headers uploading to


(Core :: Networking: HTTP, defect)

Windows 7
Not set



Tracking Status
e10s m7+ ---
firefox39 --- fixed


(Reporter: raysatiro, Assigned: bent.mozilla)




(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150212030231

Steps to reproduce:

Reproducible in x86 and x64 Nightly, e10s only. Create a file a few megabytes in size. For example in windows to fill 5 million bytes with zeroes:

fsutil file createnew test4.avi 5000000

Try to upload that file to

Actual results:

The counter does not appear properly and behind the scenes the file is not uploaded properly.

0% Complete
17,581,566,778,079.8MB of 4.8MB

I used the debugging proxy Fiddler to monitor the traffic. I get 10 protocol violations due to invalid header requests. Fiddler says request parsing failed and shows:

HTTP/1.1 400 Fiddler - Bad Request
Date: Wed, 18 Feb 2015 17:28:18 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Cache-Control: no-cache, must-revalidate
Timestamp: 12:28:18.273

[Fiddler] Request Header parsing failed. Request was:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ........................
(line repeated many times)

The avi file is all zeroes so I think for some reason the request header is omitted and it's just uploading the avi file. When I upload with an actual avi file I can see its contents in what's supposed to be the request header.

Too many chunks are actually uploaded to 11 1MB chunks are uploaded to the server. The final chunk gives an error of "Input size does not match content-range header".

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Vidme-Fp: 3692931114
X-Vidme-Device-Id: 55a550e03ef84f769b80cb8b0e57e02d
X-Vidme-Device-Platform: web
X-Vidme-Srid: rIQejxsJRgWwe3TGiooggA-IQh7Xg-KAly2udtajmKIYyG9ZPSnZti8Nc
Content-Range: bytes 0-999999/5000000
Content-Disposition: attachment; filename="test4.avi"
X-Requested-With: XMLHttpRequest
Content-Length: 1000598
Content-Type: multipart/form-data; boundary=---------------------------17254108579983
Cookie: rid=55a550e03ef84f769b80cb8b0e57e02d; srid=rIQejxsJRgWwe3TGiooggA-IQh7Xg-KAly2udtajmKIYyG9ZPSnZti8Nc; _ga=GA1.2.83876612.1424280446; _gat=1; mp_1f56950e9710dee864f0f7308fa5233c_mixpanel=%7B%22distinct_id%22%3A%20%2214b9dbae433925-06e1fea5beb8628-4b594136-144000-14b9dbae434780%22%2C%22%24initial_referrer%22%3A%20%22%24direct%22%2C%22%24initial_referring_domain%22%3A%20%22%24direct%22%7D
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache


HTTP/1.1 400 Bad Request
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: *
Content-Type: application/json
Date: Wed, 18 Feb 2015 17:28:41 GMT
Server: nginx
X-Request-Time: 57
X-Vidme-Server-Id: 92276d6aa07b07ba32cbb53dbec83989
Content-Length: 111
Connection: keep-alive

{"status":false,"error":"Input size does not match content-range header","code":"input_content_range_mismatch"}

You can view a video of the repro at

A Fiddler session capture is attached. Although my repro case is an invalid avi file (all zeroes) I did that because the zero data makes it easier to understand the capture. The result is the same with a valid avi file. Also, please note the first ten sessions in the capture are in incorrect order since Fiddler bumped those sessions to the top of the list on invalid protocol violations.

Expected results:

Video files should upload to
Blocks: e10s
tracking-e10s: --- → ?
Flags: needinfo?(jduell.mcbugs)
Dragana, can you take a look at this?  I think the first step would be to do a wireshark comparison of desktop-e10s vs single-process.  If we're sending more bytes than the file that we're trying to upload, perhaps there's a bug in how we serialize mUploadStream across processes?
Component: Untriaged → Networking: HTTP
Flags: needinfo?(jduell.mcbugs)
Product: Firefox → Core
Flags: needinfo?(dd.mozilla)
Assignee: nobody → dd.mozilla
Flags: needinfo?(dd.mozilla)
Ever confirmed: true
Something is wrong with the slice handling in the case above.

In upload stream is deserialized and given to the channel in line #317. 
On the child process that is a blobSlice not the whole file.

When the upload stream is used for the first time on parent process it is opening a new file not a partial file (I am not sure if it should open a file at all or a stream should be already there). The first use is in when we are asking for the size of the stream.

I am not familiar with blobParent-BlobChild architecture.
Ben can you take a look and help me with this. I am not sure if necko is doing something wrong and should wait for stream to be ready or in communication between blobclild and blobparent something is not cute right. Thanks.
Flags: needinfo?(bent.mozilla)
I looked at this today and have a fix. I need to write a test for it and then I'll get it uploaded.
Flags: needinfo?(bent.mozilla)
Assignee: dd.mozilla → bent.mozilla
Attached patch Patch, v1Splinter Review
Still have to figure out how to test this...
Attachment #8578433 - Flags: review?(khuey)
Comment on attachment 8578433 [details] [diff] [review]
Patch, v1

Review of attachment 8578433 [details] [diff] [review]:

Attachment #8578433 - Flags: review?(khuey) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
I think this only affects e10s and b2g... Not sure it's worth uplifting because b2g probably can't get to this code path since it doesn't have a file picker. I could be wrong there though.
Thanks everyone, I tested using Nightly build 4d2d97b3ba34 and it's working properly.
You need to log in before you can comment on or make changes to this bug.