relative paths in playlist are broken by 302 redirect

[gkindel]

What:
Relative paths in m3u8s are wrong if manifest result of redirect.

Steps:
Create a rewrite rule which redirects any path to an externally hosted m3u8 which contains relative paths (anything not in the same directory).

Expect:
URIs in the playlist are resolve relative to the redirect target url.

Actual:
URIs are being resolved relative to the pre-redirect base, which 404.

Specs are a bit hard to read on this. The HLS spec calls out:

3.1:
A URI in a Playlist, whether it is a URI line or part of a tag, MAY
be relative. Relative URIs MUST be resolved against the URI of the
Playlist file that contains it.

While the URI spec:

5.1.3. Base URI from the Retrieval URI
...if the retrieval was the result of a redirected request, the last URI
used (i.e., the URI that resulted in the actual retrieval of the
representation) is the base URI.

More importantly, I've tested against Safari and iOS and they both use the redirect results as base.

This is a bit of a corner case and probably one I can patch for you, but wanted to record it here. URLLoader should return the redirect target in the HTTPStatusEvent, if that's available for our runtime. I'll look around.

Reproduced on v0.4.0.5 and v0.3.1.

[mangui]

@gkindel any update ?

[mangui]

@gkindel any update ?

[gkindel]

Haven't looked into it for a bit. We were able to workaround by using absolute paths on our dynamically generated manifests, and then other priorities kicked in.

We are actually still on a patched 0.3 version of the player, as last time i pulled trunk we had stability problems that i could not easily diagnose. I believe they were related to the bug i fixed in 0.3 related to the video never officially ending due to the buffer never being fully drained. With the rewrite of that class along with adding back buffering, I did not get to re-apply the logic to our 0.4 branch.

I interested fixing the issue, but I am traveling currently without a computer until mid July.

[jlacivita]

@mangui & @gkindel:

Flash is ignorant 302 redirects, so even though 302 will successfully redirect for Flash clients, there's no way for ActionScript code to be aware of the redirected URL to resolve subsequent relative URLs with.

The only way to fix this would be to rewrite flashls in JavaScript, and only use Flash to play video fragments (which is an interesting idea, but is a pretty radical change, that might shift the uses cases flashls solves)

I think it makes more sense to close this issue, as there's no easy fix.

[gkindel]

What about http://stackoverflow.com/questions/3871243/flex-urlloader-get-location-header ?

[jlacivita]

Yup, Flex/ActionScript support it in-theory, but only when you're building a flex app for desktop.

When you're in a browser plug-in, it's not available.