relative paths in playlist are broken by 302 redirect

Nobody has claimed this yet.

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.

Start by tracing URLLoader handling and the HTTPStatusEvent mentioned in the issue, then reproduce a redirect to an externally hosted m3u8 containing relative URIs. Done means playlist URIs resolve against the final redirect target URL, matching Safari and iOS behavior rather than the pre-redirect URL.

Written by the indexing model from the issue text.