iPad video from S3 "Request has expired"

Bob Easton here, as “tech support” for Mary May.

We serve mp4 video files via http from Amazon S3 file storage (not Cloudfront and not RTMP).

We use JWPlayer at version 5.10.something, with s2Member at version 121213, and WordPress at 3.4.2.

Video serving works from S3 works very well for all environments EXCEPT iPads. While things were once working correctly for iPads, we are now hearing reports of stalls. Most people reports stalls “after a few minutes” with time that varies from 2 – 6 minutes.

Someone with more iPad skills than mine, placed his iPad in developer mode and discovered the following error message after the video stalled:

AccessDeniedRequest has expired7A6DF3A2F97DE9022013-01-08T20:13:47Zwuewiah8kbDg+P85QReTH/11z/q12syY0AeP9vIu4r1cTG1T/gy2Nyduotb97PER2013-01-08T20:14:24Z

I’ve reviewed our download options and restrictions settings and don’t see anything amiss.

Where should I look next?

Thanks,
Bob Easton (for Mary May)

It looks like you are using custom expiration signed urls for with your videos?
We have paid alot of money to have the same thing developed, because we had the same issue with some iOS devices, and our developed code now works flawlessly with eveything from ipads to playstations, iphones to nokias, and with any wordpress-player!

a little more information for Support Reps

Looking at s3 server logs, I find numerous instances of iPads retrieving blocks within video files … indicated by 206 return codes.

Yet a few result in “403 AccessDenied 321….” return codes … ending a series of requests as a stall.

It seems that videos are working for some but failing for others, and I can’t understand why “Request has expired.”

Where should I look next?

Before you ask … s2member-server-check-120703.php runs clean: No Issues.

Maybe I need to ask questions about this problem a different way…

Assumptions:
– iPad’s consume videos in multiple segments, via byte-range requests.
– Amazon S3 file service (remember, no CloudFront) expects a signed URL, which s2Member provides.
– s2Member affords another level of protection by time limiting the request using the Expires= header.

Now, how do signatures and expire values get generated after the first request from an iPad?

??? Does JWPlayer generate these subsequent requests? If so, what clock does it use? … the iPad’s clock?

??? Or, are these requests generated by s2Member? (I don’t see them in the server logs.)

Raam, Cristián, Jason,

Any ideas on this??????

Hi Bob.

Now, how do signatures and expire values get generated after the first request from an iPad?

I really don’t know, but I’ll ask Jason, who coded the integration. Thanks for your patience. :)

By the way, have you tried Philly’s plugin for video shortcodes? He’s put a lot of work into it and maybe it helps have the player perform better with iPads? http://phillymax.com/web/s2member-video-shortcode/

Thanks for the heads up on this thread.

~ I’m reviewing it now and I’ll post a reply shortly for you :-)

Thanks Cristián,
Some additional observations to pass along….

Many of our videos run 20 to 30 minutes long, and amount to 100-150MB file sizes. The 30 second expires= value is certainly OK for establishing a connection with S3, but is not at all useful for iPads which will want to do many, many byte-range requests during the duration of a long playing video. Apparently, each is treated as a new connection … and the (unknown as yet) software component that generates the requests appears to simply copy the existing signature and expires= values … until time runs out.

Thanks for the tip about Philly’s plugin. So far, we’re using only S3 and his plugin also wants CloudFront. Yet, it’s good to know about it.

Thanks for your patience.

OK. This expiration time is something s2Member implements in conjunction with Amazon S3. s2Member tells S3 to expire the link after 30 seconds automatically, for improved security. This has been optimized for web browsers and not for byte range requests where you have repeated calls against the S3 URL. In most cases, the download begins and ends after a single request. So 30 seconds is more than enough time for a customer to connect to the file and begin downloading the file. It won’t matter how long it takes them to download the file, as long as they connect within 30 seconds.

Now, in cases where you have devices that are attempting to perform byte-range requests, this can become problematic, obviously. 30 seconds after the initial connection, the underlying resource expires. So future attempts (i.e. additional byte-range requests) would require a new File Download Link.

There are two easy ways to avoid this issue.

1. s2Member exposes a plugin filter that allows you to modify the default expiration time of 30 seconds. So if you’d like to extend this out longer, in support of devices that make byte-range requests, you can certainly do that.

Please create this directory and file:
/wp-content/mu-plugins/s2-hacks.php

<?php
add_filter('ws_plugin__s2member_amazon_s3_file_expires_time', 'my_custom_expiration_time');
function my_custom_expiration_time(){ return '2 hours'; }
?>

(NOTE: these are MUST USE plugins, see: http://codex.wordpress.org/Must_Use_Plugins)
(See also: http://www.s2member.com/kb/hacking-s2member/)

You can specify any length of time you like. Please use a string that is compatible with PHP’s strtotime() function. Ex: 2 hours, 2 weeks, 10 days, are all valid periods of time.

---

2. OR (HIGHLY RECOMMENDED). When you’re attempting to reach a large audience and support multiple devices, we recommend integration with BOTH Amazon S3 and with CloudFront. This is a non-issue with CloudFront integration. I think you’ll find that s2Member works much more reliably with CloudFront, and your customers are going to get content delivered from edge locations as well, making everything more enjoyable for you and your customers. See: Dashboard -› s2Member® -› Download Options -› Amazon® S3/CloudFront CDN Storage

s2Member’s CloudFront integration is designed specifically to support byte-range requests through the RTMP protocol, which will support true media streams (i.e. you can SEEK through media files). The default expiration time on CloudFront integration is 24 hours. If you want to extend that out farther, there is a filter for that as well.

Please create this directory and file:
/wp-content/mu-plugins/s2-hacks.php

<?php
add_filter('ws_plugin__s2member_amazon_cf_file_expires_time', 'my_custom_expiration_time');
function my_custom_expiration_time(){ return '36 hours'; }
?>

(NOTE: these are MUST USE plugins, see: http://codex.wordpress.org/Must_Use_Plugins)
(See also: http://www.s2member.com/kb/hacking-s2member/)

You can specify any length of time you like. Please use a string that is compatible with PHP’s strtotime() function. Ex: 24 hours, 36 hours, 2 weeks, are all valid periods of time.

Please let us know if problems persist :-)

Thanks Jason.
You’ve just confirmed what it has taken 8 very frustrating months to deduce. We have a growing number of iPad customers, but most are not technical enough to give very good descriptions of the failures they see … and I am not an iPad owner myself so have not been able to dig very deeply.

It was only a couple of days ago that a random / accidental connection to a person in Cupertino (works in a big building at 1 Infinity Loop) revealed the “AccessDenied Request has Expired” error response that led me to hours of Amazon server log examination and to posting this thread.

Sometime late yesterday, I came across the my_custom_expiration_time filter suggestion elsewhere on your site and implemented it immediately. My new friend in Cupertino confirmed that it relieved the problem.

We’ve assessed the CloudFront possibility and are currently holding back due to stories we’ve heard from others about costs that ran much beyond their expectations, and our budget.

Thanks for the confirmation.

Thanks for the follow-up :-)

I’m glad to hear this is working for you now. I appreciate you writing back.

I’m sorry to hear that you’ve had so much trouble with this. The next time something like this comes up, please don’t hesitate to ask us for help. We’ll be happy to assist you with s2Member. Also, we’ll continue to work on improving s2Member in this respect. We have to put security first, but there is still room for improvement, we recognize that. Byte-range requests from mobile devices is something we can work to improve on.