Closed
Bug 1134309
Opened 9 years ago
Closed 9 years ago
[e10s] Bad (omitted?) request headers uploading to vid.me
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla39
People
(Reporter: raysatiro, Assigned: bent.mozilla)
References
Details
Attachments
(2 files)
110.05 KB,
application/zip
|
Details | |
2.57 KB,
patch
|
khuey
:
review+
|
Details | Diff | Splinter Review |
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 vid.me 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 vid.me. 11 1MB chunks are uploaded to the vid.me server. The final chunk gives an error of "Input size does not match content-range header". ------------------------------------------------------------------- POST https://vid.me/api/upload/chunk?code=dnCN&upload=542185 HTTP/1.1 Host: vid.me 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 Referer: https://vid.me/ 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 (POST DATA) 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 https://vid.me/qLCE 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 vid.me.
Reporter | ||
Updated•9 years ago
|
Blocks: e10s
tracking-e10s:
--- → ?
Updated•9 years ago
|
Flags: needinfo?(jduell.mcbugs)
Comment 1•9 years ago
|
||
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
Updated•9 years ago
|
Flags: needinfo?(dd.mozilla)
Updated•9 years ago
|
Assignee: nobody → dd.mozilla
Flags: needinfo?(dd.mozilla)
Updated•9 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 2•9 years ago
|
||
Something is wrong with the slice handling in the case above. In http://hg.mozilla.org/mozilla-central/annotate/b74938ef94bc/netwerk/protocol/http/HttpChannelParent.cpp#l315 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 http://hg.mozilla.org/mozilla-central/annotate/760131490c81/netwerk/protocol/http/nsHttpChannel.cpp#l786 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)
Assignee | ||
Comment 3•9 years ago
|
||
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 | ||
Updated•9 years ago
|
Assignee: dd.mozilla → bent.mozilla
Assignee | ||
Comment 4•9 years ago
|
||
Still have to figure out how to test this...
Attachment #8578433 -
Flags: review?(khuey)
Updated•9 years ago
|
Comment on attachment 8578433 [details] [diff] [review] Patch, v1 Review of attachment 8578433 [details] [diff] [review]: ----------------------------------------------------------------- oops
Attachment #8578433 -
Flags: review?(khuey) → review+
Assignee | ||
Comment 6•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b3fee83f129b
Comment 7•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b3fee83f129b
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Assignee | ||
Comment 8•9 years ago
|
||
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.
Reporter | ||
Comment 9•9 years ago
|
||
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.
Description
•