New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Aug 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 140468: Pepper Flash: in file uploads, treats HTTP status != 200 as failure, breaking (e.g.) uploads to Amazon S3

Reported by bag...@gmail.com, Aug 3 2012

Issue description

Chrome Version       : 21.0.1180.60
URLs (if applicable) : https://www.wetransfer.com
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
       IE 7/8/9: OK

What steps will reproduce the problem?
1. Install the latest version of Chrome for Windows.
2. Visit https://www.wetransfer.com or another website that uploads directly to Amazon S3
3. The upload will fail and it will attempt to retry.

What is the expected result?
The upload should succeed.

What happens instead?
The upload fails.

The latest version of Chrome for Windows uses the built-in Flash version 11.3.31.222. It appears that Chrome is POSTing on behalf of Flash, thus changing the post body. Flash doesn't know how to handle the response.

This only appears to happen in Windows, but we are very worried that this Flash version will also extend to other supported platforms. We don't know yet if it causes similar problems with 'normal' uploads (i.e. uploads that are sent to a PHP script rather than Amazon S3).

Below are POSTs from before and after upgrade. As you can see, in the upgraded version of Chrome, it is POSTing itself (look at the useragent).

These are the POST from before:

POST / HTTP/1.1
Accept: text/*
Content-Type: multipart/form-data; boundary=----------ae0ae0Ef1Ef1gL6Ij5GI3ae0KM7Ef1
User-Agent: Shockwave Flash
Host: wetransfer-eu.s3.amazonaws.com
Content-Length: 30759655
Connection: Keep-Alive
Cache-Control: no-cache

and this is the POST from after upgrading:

POST / HTTP/1.1
Host: wetransfer-eu.s3.amazonaws.com
Connection: keep-alive
Content-Length: 30759655
Origin: https://wetransfer.com
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.60 Safari/537.1
Content-Type: multipart/form-data; boundary=----------KM7GI3cH2GI3ae0Ef1KM7cH2cH2ae0
Accept: */*
Referer: https://wetransfer.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
 

Comment 1 Deleted

Comment 2 by bag...@gmail.com, Aug 3 2012

Also since this latest version, popular Flash debug output tool Arthopod (http://arthropod.stopp.se/) is no longer working. There is absolutely no output coming through it at all. It's almost like Chrome has heavily sandboxed Flash.

Comment 3 by kareng@google.com, Aug 6 2012

Cc: jsc...@chromium.org
Labels: Mstone-21
Owner: viettrungluu@chromium.org
Status: Assigned

Comment 4 by bulent.d...@gmail.com, Aug 6 2012

I don't believe the issue is described here accurately. It looks like the request that is made to the server (POST) is successfully executed and Amazon receives the request. However, the response is being invoked as an error in the Flash plugin. The status code is even correct (201) but for some reason Flash plugin interprets the response as an error case. The response body is an XML which includes the details of the upload such as the etag for the file and the file key.

Comment 5 by jsc...@chromium.org, Aug 7 2012

Comment 6 by bulent.d...@gmail.com, Aug 7 2012

After a little bit of debugging (which can't be really done anymore), it turns out that the issue is the new Pepper Flash. If Pepper Flash is disabled, it all works as expected. When Pepper Flash is enabled, a 201 response code from the server first triggers an IOError which is then followed by the onHttpStatus listener being invoked. Since the order of the call is also flipped, it is pretty hard to apply a workaround to this issue. 

I'm guessing that Pepper Flash is going to take over the standard Flash plugin. Can we get the httpStatus at least be handled properly?

Comment 7 by bag...@gmail.com, Aug 7 2012

Comment #6 is absolutely right. I have spent some time on this and came to the same conclusions. The problem is that a HTTP 201 status is not handled correctly any more. The fact that Chrome handles the POST is not the issue at all.

When uploading, if the server returns a 201, then the IOErrorEvent.NETWORK_ERROR is fired. You can still listen on IOErrorEvent.IO_ERROR. For now my workaround is to ignore this event when PepperFlash is running. Then, when the 201 is received, only HTTPStatusEvent.HTTP_STATUS is fired, and neither DataEvent.UPLOAD_COMPLETE_DATA or Event.COMPLETE is fired.

During downloading, the Event.COMPLETE event never fires either. I now listen to ProgressEvent.PROGRESS and when the number of bytes downloaded equals the number of bytes expected, then I fake the complete event.

You can implement these workarounds while making sure that it works in all other Flash versions by checking Capabilities.manufacturer for "PEPPER". You can then make sure that PepperFlash ignores the NETWORK_ERROR event and listens carefully for the HTTP_STATUS event instead.

Comment 8 by Deleted ...@, Aug 7 2012

In my case, I don't have problems with the 201 status. I receive a DataEvent.UPLOAD_COMPLETE_DATA as expected. My problem is the content received in  DataEvent.data. It is not the same with PepperFlash and Flash

In Flash, it returns an XML like this:
<?xml version="1.0" encoding="UTF-8"?>
<PostResponse><Location>https://xxxx.s3.amazonaws.com/FileName</Location><Bucket>xxxx</Bucket><Key>FileName</Key><ETag>"ABCD"</ETag></PostResponse>

There is no way in PepperFlash to retrieve the ETag information from DataEvent.data.

Comment 9 by jsc...@chromium.org, Aug 8 2012

Cc: raymes@chromium.org
Labels: -Area-Undefined Area-Internals Feature-Flash Feature-Plugins-Pepper

Comment 10 by vanvr...@adobe.com, Aug 9 2012

Tests OK on Win 7 x64 / 21.0.1180.75 Chrome Stable / 11,3,31,225 Pepper

Comment 11 by bulent.d...@gmail.com, Aug 9 2012

I just tested on Win XP Professional SP3 with Chrome 21.0.1180.75 m and 11.3.31.225 Pepper and it fails. Are you sure you tested with the correct flash plugin?

Comment 12 by bag...@gmail.com, Aug 9 2012

I also just tested on 21.0.1180.75 Chrome 11.3.31.225 Pepper in both XP and Win7 x64, and it does indeed still fail.

Comment 13 by viettrungluu@chromium.org, Aug 9 2012

Status: Started

Comment 14 by viettrungluu@chromium.org, Aug 9 2012

@bagus: Do I have to do anything special for it to fail?

I've tried uploading a small file (a couple KB), a big file (~70 MB), two small files ... and it's succeeded every time (Win7 x64).

If it only sometimes fails, what's the failure rate like?

Comment 15 by bulent.d...@gmail.com, Aug 9 2012

Are you using a filereference.upload call with a POST and the response code specified in the header as 201? If you do this, it fails every single time.

Comment 16 by viettrungluu@chromium.org, Aug 9 2012

I was trying https://wetransfer.com. Is there another reliable, publicly-available repro case that I should be using? (Of course, I could set up my own server, etc., but that would take a lot more time.)

Comment 17 by bag...@gmail.com, Aug 9 2012

Sorry, I should have been more clear. I have got around the problem in the SWF on wetransfer.com using the workarounds posted in comment #7 (I am detecting that you're using Pepper Flash).

I have now put at https://wetransfer.com/chrome.php a version based on the previous code. There it will fail in the latest Chrome (once the file is uploaded, it will retry because it receives the IOErrorEvent.NETWORK_ERROR event. After the retried upload, it fails entirely because Flash doesn't seem to fire that same event twice, but that is a separate Flash bug from long ago).

Comment 18 by viettrungluu@chromium.org, Aug 10 2012

Summary: Pepper Flash: in file uploads, treats HTTP status != 200 as failure, breaking (e.g.) uploads to Amazon S3
Changing summary, which was: Chrome POSTs on behalf of Flash, causing failures when uploading to Amazon S3

(Probably I should also set the "right" user agent in file uploads, though that's a separate issue, which I'll handle separately.)

Comment 19 by viettrungluu@chromium.org, Aug 10 2012

@bagpus: Thank you, that was very helpful.

Turns out we were treating HTTP status != 200 as failures (just like Linux NPAPI Flash -- there's a lesson here).

I have a fix, which will make it into a Chrome Canary soon (not tomorrow's, alas). I'll ping this bug once it's on Canary.

If all goes well, I'll try to get this into the next Chrome 21 update.

Comment 20 by viettrungluu@chromium.org, Aug 10 2012

 Issue 141262  has been merged into this issue.

Comment 21 by viettrungluu@chromium.org, Aug 11 2012

Should be in the next Canary; check that it has Pepper Flash 11.3.31.316+.

Comment 22 by bag...@gmail.com, Aug 14 2012

Would love to test, but the latest Canary version is dogged by  issue #138902  where the Flash Browse File dialog doesn't open at all. Until that is sorted out, I don't think we can test this issue.

Comment 23 by viettrungluu@chromium.org, Aug 16 2012

Try again? I hope  issue 138902  has been fixed now. Thanks.

Comment 24 by bag...@gmail.com, Aug 16 2012

The uploads bug (and the file browse bug) appears to be fixed now in Canary ^_^

The Event.COMPLETE bug for downloads that I mentioned in comment 7 is still there, though that is less important. I guess that is worthy of a new ticket?

Comment 25 by viettrungluu@chromium.org, Aug 16 2012

@24: Thanks for checking. Please file a new bug for the Event.COMPLETE bug. Thanks again.

Comment 26 by ligim...@chromium.org, Aug 17 2012

Able to upload files .. Build used 21.0.1180.81

Comment 27 by viettrungluu@chromium.org, Aug 17 2012

Status: Fixed

Comment 28 by etenderc...@gmail.com, Aug 19 2012

Still unable to upload document from file uploader to amazon cloud

 
etender - support
t 07 5641 4946 
 
 Please consider the environment before printing this email.
 
 
 
This email is intended to be read or used by the addressee only.  It may
contain confidential information.  If you are not the intended recipient any
use of information is strictly prohibited.

Comment 29 by viettrungluu@chromium.org, Aug 20 2012

@28: Without version information, your report is useless.

Comment 30 by etenderc...@gmail.com, Aug 20 2012

It's the same version I reported originally.

 
etender - support
t 07 5641 4946 
 
 Please consider the environment before printing this email.
 
 
 
This email is intended to be read or used by the addressee only.  It may
contain confidential information.  If you are not the intended recipient any
use of information is strictly prohibited.

Comment 31 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 32 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-Internals -Mstone-21 -Feature-Flash -Feature-Plugins-Pepper Cr-Content-Plugins-Flash M-21 Cr-Internals Cr-Content-Plugins-Pepper

Comment 33 by bugdroid1@chromium.org, Mar 14 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 34 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: Cr-Blink

Comment 35 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash

Comment 36 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: Cr-Internals-Plugins

Comment 37 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content-Plugins-Pepper Cr-Internals-Plugins-Pepper

Sign in to add a comment