WP eStore, Corrupted Zip, Internet Explorer, Crashing Browser

Tips and Tricks HQ Forum » WP eStore Forum » WP eStore Troubleshooting

WP eStore, Corrupted Zip, Internet Explorer, Crashing Browser

(5 posts) (2 voices)

Started 4 months ago by Zain
Latest reply from wzp
Possible Solutions (Related Topics):

Tags:

Zain
Member

Hi,

I've been experiencing some very strange problems with corrupted Zip file downloads and Internet Explorer 9. The strange thing is, the 64bit version of IE9 works okay but the normal 32bit crashes.

The set up:

- WP eStore v 6.3.2
- Amazon S3
- PHP 5.2.x

Initially, I had a couple of people saying they had problems downloading - zip files were being corrupted so I thought I'd look into it. I've just set up Amazon S3, and only just managed to get it working. Anyway, here are my findings from testing various parts.

Through testing, I think the issue may be to do with the "Digital Content Details" / Downloadable checkbox option. Doing some tests, with the checkbox ticked, Internet Exploder 9 (32bit) will try to open the link in a new tab, then a prompt window comes up saying "Internet Exploder has stopped working", with an option to either check online for a solution or close the program!

Upon cancelling the prompt - the program remains open and the option to download the file appears at the bottom of IE. It won't download first time, but clicking on "View Downloads" then "Retry" does download the file! Very strange.

I've found that "unchecking" the Downloadable box AND making files in the Amazon S3 bucket object "Public", does work. IE9 32bit will download the file (and even recognise the file size properly)... and it then dies *after* the download (sometimes! Not always.).

Testing IE9 64bit - the file downloads happily. Normal IE9 32bit is having an issue and major meltdown.

Note: I do have WP Super Cache installed on my site. The "wp-cache-phase1.php" has been amended to comply with the eStore (and Affiliate) plugin instructions. I realise that gzip can cause zip file corruption issues (http://kb.winzip.com/kb/entry/150/), but I don't think this is the cause of problem.

Any idea what might be going on? Could it be how IE handles the mime-type specification as the WinZip site mentions?

For the moment, I have my files in my Amazon bucket as "Public" AND the Downloadable checkbox unticked. Ideally, I don't want to do this! However, if it means fewer people are having issues, then that's better than having complaints!

Please can someone look into this and test? It's very bizarre.

Cheers,

Zain
PS: YES, I know the solution is to use FireFox, Chrome or any browser that actually *works*. I hate IE and do suggest to people to get another browser *all* the time...! Still, people carry on using it (even though it doesn't work properly!). *sigh*

Posted 4 months ago #
wzp
Moderator

Here is a brief description of how Amazon S3 is handled by eStore:

1. Buyer clicks download link, which kicks off the download.php script.

2. Encrypted link is decoded.

3. Script realizes the product URI is the AS3TP or AS3TPS scheme.

4. An expiring URL request is created.

5. Buyer is redirected to s3.amazonaws.com for the actual download.

6. When the IE "Save As" prompt comes up, it means that control was sucessfully handed off from eStore to Amazon, because S3 has begun feeding data to the browser.

At no time during this process, except for step 5, is there any interaction between eStore and the buyer's browser. All the other steps take place on the server.

Marking your bucket or object as "Public" has the same affect as giving buyers unencrypted links.

If diddling with settings on the S3 Console affects download behavior, the problem is an S3 to browser interaction issue. Diddling with the "Downloadable" checkbox won't affect anything, because eStore only looks at it if step 3 determines the product URI is not using the AS3TP or AS3TPS scheme.

Because S3 doesn't care about whether or not you are using 8, 16, 32 or 64 bits I suspect a client side configuration issue.

One thing you might try, as a further investigative measure, is to enable debug log files on eStore, and logging on your bucket. Doing so will confirm the buyer is being redirected to Amazon, and that Amazon is correctly delivering your files.

Posted 4 months ago #
wzp
Moderator

BTW, are you by any chance using SSL for the bucket download using the AS3TPS scheme?
https://forums.aws.amazon.com/thread.jspa?messageID=230962

Posted 4 months ago #
Zain
Member

Hi WZP,

Thanks for the reply. I don't think I'm using SSL for the bucket - to be honest, I don't even know how you enable that on S3! I'm just using whatever they have on there when the file uploads then using the Action to make the file "Public". I'm also using as3tp:// rather than as3tps:// when adding the product.

Thanks for your explanation, although the weird thing is, it's only the 32 bit version of Internut Exploder that has this particular issue. Testing 64bit and the download is fine. So there's something buggy about the way the 32bit version is handling the file request.

Anyway, I'll try using the debug and see what happens and report back findings.

Oh... while I'm here, can anyone explain the "AWS S3 Presigned URL Expiry" value? The default 300 didn't work for me (XML file returned with Access denied) but setting it to 3000 did.

Cheers,

Zain

Posted 4 months ago #
wzp
Moderator

That expiry controls the number of seconds in which control must be transferred from eStore to Amazon, before the S3 transfer request becomes invalid. If you have to increase that number, it means there is a significant difference between the system clock on your server and the one on the Amazon server.

Posted 4 months ago #

RSS feed for this topic

Reply

You must log in to post.