Libysn enclosure requests 302 you to an S3 signed url? So weird.
-
Libysn enclosure requests 302 you to an S3 signed url? So weird.
-
@dave why? seems smart to me
-
@js What benefit does that offer?
-
@dave many hosts use an url in their feed that is basically an internal redirector, it's only meant to track the download, then shunt the request off to either an external or internal cdn
using an expiring signed url as the target means no requests go directly to the cdn (bypassing the host counter) - and they don't need to make the target bucket/distribution public
-
@dave my guess is that having this stable url in the feed also gives them the option to change their cdn scheme whenever they want without having the apps notice a url change (and redownload everything)
-
@js "using an expiring signed url as the target means no requests go directly to the cdn"
That's my confusion. What does the fact that it's expiring have to do with the 302? You get the same effect just 302'ing to a normal CDN url right? The expiring final destination url would seem to cause some possible issue if an app chose to hold on to that url and you try to resume a stream later after the expiry period.
-
@dave nah 302 is single request only. some have more than one redirect "below" the url in the feed. cool thing about signing is that they dont need to make the target bucket/destination public and have a strong chain from their log to the cdn log
i store the entire chain for all new episodes (a bunch of hosts do this), maybe worth a blog post or something next week
-
@js Sorry, I still just don't understand. I'm sure you're smarter than me. Just can't grasp it.
-
@dave sounds like a great question to add to the ask rob list when he's on the show!