- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 4 Nov 2018 12:42:50 +0100
- To: Ori Finkelman <orif@qwilt.com>
- Cc: ietf-http-wg@w3.org, ggie@ietf.org, "Begen, Ali (Contractor)" <Ali_Begen@comcast.com>
On 2018-11-04 12:19, Ori Finkelman wrote: > Thanks Julian. > > In that case, for Example 2: > Would you say that the base URI for /vod/movie/master.m3u8 is resolved > by section 5.1.3 from the retrieval URI? > In that case the base URI for /vod/movie/master.m3u8 is > https://edge1.dcdn.example.net/vod/movie/master.m3u8. > Since the relative reference 1800K/1800_complete.m3u8 is encapsulated > within master.m3u8, it should be resolved according to section 5.1.2 and > should therefore be > https://edge1.dcdn.example.net/vod/movie/1800K/1800_complete.m3u8 > > So, example 2 behaves well, according to this interpretation. > > For example 3: > Following your input, master.m3u8 IS NOT encapsulated in the HTML (the > URI is), and therefore its base URI should be computed by section 5.1.3 > from the retrieval URI, as in Example 2. > That would lead to the same result that the > vod/movie/1800K/1800_complete.m3u8 base URI is at the edge cache. > https://edge1.dcdn.example.net/vod/movie/1800K/1800_complete.m3u8 > > Is this the correct interpretation ? > If so, then all these examples lead to the same conclusion that the > client should be 'sticky'. > > Thanks, > Ori > ... Absolutely. Best regards, Julian
Received on Sunday, 4 November 2018 11:43:29 UTC