Description
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.