HTTP redirect for HTTP Adaptive Streaming (HAS) in CDN use cases

[Ori Finkelman]

[Resending as I have sent to the wrong list]


Hello ,

HTTP redirect, usually using 302 Found, is widely used in video CDN for
HTTP Adaptive Streaming (HAS) protocols, specifically for HLS and DASH.
Using HTTP redirect instead of the more commonly used delegation by CNAME
is a much more powerful and flexible solution.

At a high level, the required behavior is that after getting an HTTP
redirect to a playlist address that takes the client to a CDN cache, if the
playlist contains
relative references to the media segments, the client should be "sticky"
and request the subsequent media segments directly from the cache without
the need
for repeated redirects that would add undesired latency and harm QoE.
However, due to misinterpretations of the RFC in some cases, and
contradiction between this requirement and the existing RFC in other cases,
we face many
issues with clients that behave differently in the case of HTTP redirect,
when relative references are being used.
A discussion of this use case can also be found in section 2.2.1 of RFC6983
<https://tools.ietf.org/html/rfc6983#section-2.2.1>.

The Streaming Video Alliance (SVA) and DASH Industry Forum (DASH-IF) are
attempting to resolve these issues and create clear guidelines describing
how video players,
browsers and streaming applications should behave in such HTTP redirect
cases.

The attached I-D includes a detailed description of this issue, examples
with our understanding of the current behavior and proposals for
alternative approaches for solution.
We were hoping that the members of HTTPBIS working group could share their
views regarding the preferred approach in order to resolve this issue.

If there is interest and some available time I can prepare a quick slide
deck for the httpbis meetings next week.


Best regards,
Ori
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
***@qwilt.com

[Lucas Pardue]

Ori,

Thanks for sharing this, and the authors for writing this up. What's
captured in the document broadly matches my experiences in this space.

The problems can be real. A broker server, dimensioned to handle a low rate
of playlist requests, may end up getting overwhelmed with client media
requests. This is hard to predict because client implementations are
diverse; new things come along, and existing ones may regress. I am aware
of non-IETF efforts that attempt to characterise client behaviour like
this, and it wouldn't surprise me if the effort is duplicated across
different content or service providers.

I support discussion that can address this issue but have no strong opinion
on the final solution at this time.

Lucas

Post by Ori Finkelman
[Resending as I have sent to the wrong list]
Hello ,
HTTP redirect, usually using 302 Found, is widely used in video CDN for
HTTP Adaptive Streaming (HAS) protocols, specifically for HLS and DASH.
Using HTTP redirect instead of the more commonly used delegation by CNAME
is a much more powerful and flexible solution.
At a high level, the required behavior is that after getting an HTTP
redirect to a playlist address that takes the client to a CDN cache, if the
playlist contains
relative references to the media segments, the client should be "sticky"
and request the subsequent media segments directly from the cache without
the need
for repeated redirects that would add undesired latency and harm QoE.
However, due to misinterpretations of the RFC in some cases, and
contradiction between this requirement and the existing RFC in other cases,
we face many
issues with clients that behave differently in the case of HTTP redirect,
when relative references are being used.
A discussion of this use case can also be found in section 2.2.1 of
RFC6983 <https://tools.ietf.org/html/rfc6983#section-2.2.1>.
The Streaming Video Alliance (SVA) and DASH Industry Forum (DASH-IF) are
attempting to resolve these issues and create clear guidelines describing
how video players,
browsers and streaming applications should behave in such HTTP redirect
cases.
The attached I-D includes a detailed description of this issue, examples
with our understanding of the current behavior and proposals for
alternative approaches for solution.
We were hoping that the members of HTTPBIS working group could share their
views regarding the preferred approach in order to resolve this issue.
If there is interest and some available time I can prepare a quick slide
deck for the httpbis meetings next week.
Best regards,
Ori
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |

[Ori Finkelman]

Thanks Lucas and Thomas for your inputs.
Thomas, it's a good point, we will have to address the case of multiple
endpoints, we will address it in the next version once we get some inputs
from HTTPbis on the preferred direction.

All, my apologies for distributing by mail, we will submit on Monday
morning as soon as the submission tool is open.
Attached is a newer revision with minor typo fixes.

Thanks,
Ori

Post by Lucas Pardue
Ori,
Thanks for sharing this, and the authors for writing this up. What's
captured in the document broadly matches my experiences in this space.
The problems can be real. A broker server, dimensioned to handle a low
rate of playlist requests, may end up getting overwhelmed with client media
requests. This is hard to predict because client implementations are
diverse; new things come along, and existing ones may regress. I am aware
of non-IETF efforts that attempt to characterise client behaviour like
this, and it wouldn't surprise me if the effort is duplicated across
different content or service providers.
I support discussion that can address this issue but have no strong
opinion on the final solution at this time.
Lucas

Post by Ori Finkelman
[Resending as I have sent to the wrong list]
Hello ,
HTTP redirect, usually using 302 Found, is widely used in video CDN for
HTTP Adaptive Streaming (HAS) protocols, specifically for HLS and DASH.
Using HTTP redirect instead of the more commonly used delegation by CNAME
is a much more powerful and flexible solution.
At a high level, the required behavior is that after getting an HTTP
redirect to a playlist address that takes the client to a CDN cache, if the
playlist contains
relative references to the media segments, the client should be "sticky"
and request the subsequent media segments directly from the cache without
the need
for repeated redirects that would add undesired latency and harm QoE.
However, due to misinterpretations of the RFC in some cases, and
contradiction between this requirement and the existing RFC in other cases,
we face many
issues with clients that behave differently in the case of HTTP redirect,
when relative references are being used.
A discussion of this use case can also be found in section 2.2.1 of
RFC6983 <https://tools.ietf.org/html/rfc6983#section-2.2.1>.
The Streaming Video Alliance (SVA) and DASH Industry Forum (DASH-IF) are
attempting to resolve these issues and create clear guidelines describing
how video players,
browsers and streaming applications should behave in such HTTP redirect
cases.
The attached I-D includes a detailed description of this issue, examples
with our understanding of the current behavior and proposals for
alternative approaches for solution.
We were hoping that the members of HTTPBIS working group could share
their views regarding the preferred approach in order to resolve this
issue.
If there is interest and some available time I can prepare a quick slide
deck for the httpbis meetings next week.
Best regards,
Ori
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |

[Patrick McManus]

Hi Ori,

As Chair:
Thanks for the draft and the note.. please submit any/all drafts to the
datatracker as soon as it reopens (which I believe is Monday morning).

As far as I understand your topic, your primary concern is that you are
looking for a clarification on what the base URI used to resolve a relative
URI is when there has been a redirect involved.. specifically in your case
the relative URI is in a manifest file and the manifest was obtained via
302 - is the base URI from the original manifest URI or the one that was
given in the 302 location?

Given that a major focus of our meeting will be on http-core, and this
seems like a clarification of core semantics let's just discuss it there.
Mark and I have huddled and we think
https://github.com/httpwg/http-core/issues/38 seems like the right place.
We'll have discussion time at the meeting and of course, the list is always
a fine place for that kind of discussion too.

As Individual:

* its against the terminal (i.e. redirected) uri - though I had trouble
finding language to quote on it.. so some guidance seems like a good idea
at first glance

* alternative services might also fit your use case - rfc 7838 .. in
particular they have better fallback behavior if you want to revert to the
original URI in case of reachability.

-Patrick

Post by Ori Finkelman
[Resending as I have sent to the wrong list]
Hello ,
HTTP redirect, usually using 302 Found, is widely used in video CDN for
HTTP Adaptive Streaming (HAS) protocols, specifically for HLS and DASH.
Using HTTP redirect instead of the more commonly used delegation by CNAME
is a much more powerful and flexible solution.
At a high level, the required behavior is that after getting an HTTP
redirect to a playlist address that takes the client to a CDN cache, if the
playlist contains
relative references to the media segments, the client should be "sticky"
and request the subsequent media segments directly from the cache without
the need
for repeated redirects that would add undesired latency and harm QoE.
However, due to misinterpretations of the RFC in some cases, and
contradiction between this requirement and the existing RFC in other cases,
we face many
issues with clients that behave differently in the case of HTTP redirect,
when relative references are being used.
A discussion of this use case can also be found in section 2.2.1 of
RFC6983 <https://tools.ietf.org/html/rfc6983#section-2.2.1>.
The Streaming Video Alliance (SVA) and DASH Industry Forum (DASH-IF) are
attempting to resolve these issues and create clear guidelines describing
how video players,
browsers and streaming applications should behave in such HTTP redirect
cases.
The attached I-D includes a detailed description of this issue, examples
with our understanding of the current behavior and proposals for
alternative approaches for solution.
We were hoping that the members of HTTPBIS working group could share their
views regarding the preferred approach in order to resolve this issue.
If there is interest and some available time I can prepare a quick slide
deck for the httpbis meetings next week.
Best regards,
Ori
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |

[Lucas Pardue]

Hey Patrick,

Post by Patrick McManus
* alternative services might also fit your use case - rfc 7838 .. in
particular they have better fallback behavior if you want to revert to the
original URI in case of reachability.

The sad reality is that, in my experience, client support for using Alt-Svc
like this is pretty bad. The last time I checked, even Chrome can't handle
host redirection for HTTP/1.1 or HTTP/2 connections (I can dig out the bug
if you like).

For non-browser clients, which Ori's document is likely targeting, I'd be
shocked if they had any support for Alt-Svc in a fully compliant way. Given
that there is trouble implementing redirects ;-).

Firefox is the only one that seems to do Alt-Svc to its full extent
(protocol support aside).

Lucas

[Patrick McManus]

Post by Lucas Pardue
Hey Patrick,

Post by Patrick McManus
* alternative services might also fit your use case - rfc 7838 .. in
particular they have better fallback behavior if you want to revert to the
original URI in case of reachability.

The sad reality is that, in my experience, client support for using
Alt-Svc like this is pretty bad. The last time I checked, even Chrome can't
handle host redirection for HTTP/1.1 or HTTP/2 connections (I can dig out
the bug if you like).

chrome should speak for themselves if they like, but my understanding from
previous comments is that they intend to fix this as part of the work for
supporting HQ at least for h2. (h1 has always been a little concerning
there as it uses the host and port implicitly)

Post by Lucas Pardue
For non-browser clients, which Ori's document is likely targeting, I'd be
shocked if they had any support for Alt-Svc in a fully compliant way. Given
that there is trouble implementing redirects ;-).

I bring this up because its the only thing that I know of that satisfies
both relative references against the derived location _and_ fallback to the
original location in the case of reachability failure (which relative
references to the redirected url do not) - which is a nice pattern.

Post by Lucas Pardue
Firefox is the only one that seems to do Alt-Svc to its full extent
(protocol support aside).
Lucas

[Lucas Pardue]

Hey Patrick,

Some replies inline.

Post by Patrick McManus
chrome should speak for themselves if they like, but my understanding from
previous comments is that they intend to fix this as part of the work for
supporting HQ at least for h2. (h1 has always been a little concerning
there as it uses the host and port implicitly)

My understanding is that Chrome host-based Alt-Svc is supported in gQUIC
but not for H2 ( from a Google Groups thread "layering of socket pools
makes implementing this for HTTP/2 significantly more complex"). If that
complexity has been overcome it would be good news, it would be nice to
have a public statement to that effect.
I bring this up because its the only thing that I know of that satisfies

Post by Patrick McManus
both relative references against the derived location _and_ fallback to the
original location in the case of reachability failure (which relative
references to the redirected url do not) - which is a nice pattern.

Totally agree, I think there is untapped potential. Especially when
combined with ORIGIN and Secondary certs.

I could imagine some deployment that offers several alternatives, to avoid
falling back to the broker. Although I don't think implementations would
presently work that way.

DASH also offers a feature to specify multiple origins in the manifest
itself, with the client choosing them in an ordered way. There's
potentially some interesting interplay with Alt-Svc here.

Lucas

[Ryan Hamilton]

Post by Lucas Pardue
Hey Patrick,
Some replies inline.

Post by Patrick McManus
chrome should speak for themselves if they like, but my understanding
from previous comments is that they intend to fix this as part of the work
for supporting HQ at least for h2. (h1 has always been a little concerning
there as it uses the host and port implicitly)

My understanding is that Chrome host-based Alt-Svc is supported in gQUIC
but not for H2 ( from a Google Groups thread "layering of socket pools
makes implementing this for HTTP/2 significantly more complex"). If that
complexity has been overcome it would be good news, it would be nice to
have a public statement to that effect.

Alas, this is still the case.

Post by Lucas Pardue
I bring this up because its the only thing that I know of that satisfies

Post by Patrick McManus
both relative references against the derived location _and_ fallback to the
original location in the case of reachability failure (which relative
references to the redirected url do not) - which is a nice pattern.

Totally agree, I think there is untapped potential. Especially when
combined with ORIGIN and Secondary certs.
I could imagine some deployment that offers several alternatives, to avoid
falling back to the broker. Although I don't think implementations would
presently work that way.
DASH also offers a feature to specify multiple origins in the manifest
itself, with the client choosing them in an ordered way. There's
potentially some interesting interplay with Alt-Svc here.
Lucas

[Ori Finkelman]

While I agree that Alt-Svc may be the to better solution looking forward,
we still need to resolve the issue for existing HTTP redirect
architectures, mainly for HLS as it is still the dominating video streaming
protocol, but for DASH also.
HTTP redirect is widely in use and clients that don't conform with the
relative resolution, as it seems to be the case, degrades qoe and cause a
significant performance hit on CDN load balancers.

If there is agreement that in case the playlist is requested separately,
and it is not embedded within another encapsulating entity, then the
playlist base URI is the final retrieval URI, after redirect, it would be
great if there could be some clarifications that establish this
understanding.

We could then work with player software developers to adjust their code
accordingly.
If there are gaps in browser XMLHttpRequest or fetch, we can also
articulate how this should be bridged.

Thanks,
Ori

Post by Ryan Hamilton

Post by Lucas Pardue
Hey Patrick,
Some replies inline.

Post by Patrick McManus
chrome should speak for themselves if they like, but my understanding
from previous comments is that they intend to fix this as part of the work
for supporting HQ at least for h2. (h1 has always been a little concerning
there as it uses the host and port implicitly)

My understanding is that Chrome host-based Alt-Svc is supported in gQUIC
but not for H2 ( from a Google Groups thread "layering of socket pools
makes implementing this for HTTP/2 significantly more complex"). If that
complexity has been overcome it would be good news, it would be nice to
have a public statement to that effect.

Alas, this is still the case.

Post by Lucas Pardue
I bring this up because its the only thing that I know of that satisfies

Post by Patrick McManus
both relative references against the derived location _and_ fallback to the
original location in the case of reachability failure (which relative
references to the redirected url do not) - which is a nice pattern.

Totally agree, I think there is untapped potential. Especially when
combined with ORIGIN and Secondary certs.
I could imagine some deployment that offers several alternatives, to
avoid falling back to the broker. Although I don't think implementations
would presently work that way.
DASH also offers a feature to specify multiple origins in the manifest
itself, with the client choosing them in an ordered way. There's
potentially some interesting interplay with Alt-Svc here.
Lucas

[Julian Reschke]

Post by Ori Finkelman
While I agree that Alt-Svc may be the to better solution looking
forward, we still need to resolve the issue for existing HTTP redirect
architectures, mainly for HLS as it is still the dominating video
streaming protocol, but for DASH also.
HTTP redirect is widely in use and clients that don't conform with the
relative resolution, as it seems to be the case, degrades qoe and cause
a significant performance hit on CDN load balancers.
If there is agreement that in case the playlist is requested separately,
and it is not embedded within another encapsulating entity, then the
playlist base URI is the final retrieval URI, after redirect, it would
be great if there could be some clarifications that establish this
understanding.
...

Where exactly do you think a clarification is needed?

Best regards, Julian

[Ori Finkelman]

Hi Julian,
I think clarifications would help relating section 5.1.2 of rfc3986.


... For a document that is enclosed
within another entity, such as a message or archive, the retrieval
context is that entity. Thus, the default base URI of a
representation is the base URI of the entity in which the
representation is encapsulated.


Now that I know that encapsulating the URI is not encapsulating the the
document itself, it is clear, however since this was under discussion of
quite a few people, before bringing it to HTTPbis, and we all missed it, it
might be good to help the reader by emphasizing this difference.
I think one confusing point was the use of HTML5 embedding tags such as
<embed> or <video> may lead you to the wrong conclusion that your document
is "embedded" within the encapsulation, while it is only logically embedded.

I am not sure what would be a good phrasing for that, but maybe something
along the line of:
"Note that a URI enclosed within another entity is not an encapsulation of
a document.
Therefore the base URI of such a document that is retrieved by such a URI,
must be established according to section 5.1.3"

If it doesn't make sense to add such a clarification, we can do it on an
external document we (the SVA) will be publishing for the video players
development community.

Best regards,
Ori

Post by Julian Reschke

Post by Ori Finkelman
While I agree that Alt-Svc may be the to better solution looking
forward, we still need to resolve the issue for existing HTTP redirect
architectures, mainly for HLS as it is still the dominating video
streaming protocol, but for DASH also.
HTTP redirect is widely in use and clients that don't conform with the
relative resolution, as it seems to be the case, degrades qoe and cause
a significant performance hit on CDN load balancers.
If there is agreement that in case the playlist is requested separately,
and it is not embedded within another encapsulating entity, then the
playlist base URI is the final retrieval URI, after redirect, it would
be great if there could be some clarifications that establish this
understanding.
...

Where exactly do you think a clarification is needed?
Best regards, Julian

[Ori Finkelman]

Hi Patrick,
Thanks for the feedback.
Alt-Svc can serve as a good solution instead of redirect.
Nevertheless, for those applications that do use HTTP redirect, I tend to
think that a clear guidance on the relative reference resolution would be
in place, and the more advanced behavior like failover can be specified as
best practices instead of a standard.

Thanks,
Ori

Post by Patrick McManus
Hi Ori,
Thanks for the draft and the note.. please submit any/all drafts to the
datatracker as soon as it reopens (which I believe is Monday morning).
As far as I understand your topic, your primary concern is that you are
looking for a clarification on what the base URI used to resolve a relative
URI is when there has been a redirect involved.. specifically in your case
the relative URI is in a manifest file and the manifest was obtained via
302 - is the base URI from the original manifest URI or the one that was
given in the 302 location?
Given that a major focus of our meeting will be on http-core, and this
seems like a clarification of core semantics let's just discuss it there.
Mark and I have huddled and we think
https://github.com/httpwg/http-core/issues/38 seems like the right place.
We'll have discussion time at the meeting and of course, the list is always
a fine place for that kind of discussion too.
* its against the terminal (i.e. redirected) uri - though I had trouble
finding language to quote on it.. so some guidance seems like a good idea
at first glance
* alternative services might also fit your use case - rfc 7838 .. in
particular they have better fallback behavior if you want to revert to the
original URI in case of reachability.
-Patrick

Post by Ori Finkelman
[Resending as I have sent to the wrong list]
Hello ,
HTTP redirect, usually using 302 Found, is widely used in video CDN for
HTTP Adaptive Streaming (HAS) protocols, specifically for HLS and DASH.
Using HTTP redirect instead of the more commonly used delegation by CNAME
is a much more powerful and flexible solution.
At a high level, the required behavior is that after getting an HTTP
redirect to a playlist address that takes the client to a CDN cache, if the
playlist contains
relative references to the media segments, the client should be "sticky"
and request the subsequent media segments directly from the cache without
the need
for repeated redirects that would add undesired latency and harm QoE.
However, due to misinterpretations of the RFC in some cases, and
contradiction between this requirement and the existing RFC in other cases,
we face many
issues with clients that behave differently in the case of HTTP redirect,
when relative references are being used.
A discussion of this use case can also be found in section 2.2.1 of
RFC6983 <https://tools.ietf.org/html/rfc6983#section-2.2.1>.
The Streaming Video Alliance (SVA) and DASH Industry Forum (DASH-IF) are
attempting to resolve these issues and create clear guidelines describing
how video players,
browsers and streaming applications should behave in such HTTP redirect
cases.
The attached I-D includes a detailed description of this issue, examples
with our understanding of the current behavior and proposals for
alternative approaches for solution.
We were hoping that the members of HTTPBIS working group could share
their views regarding the preferred approach in order to resolve this
issue.
If there is interest and some available time I can prepare a quick slide
deck for the httpbis meetings next week.
Best regards,
Ori
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
--
*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |

[Julian Reschke]

Post by Ori Finkelman
[Resending as I have sent to the wrong list]
Hello ,
...
6.2. Example 2: Relative reference in an Encapsulating Entity
Let us take the same example but instead of the player being passed
an absolute URI, let us assume the URI is relative and embedded
within another entity (e.g., within a top-level HTML page
https://video.cdn.example.com/index.html) In that case /vod/movie/
master.m3u8 (the encapsulating entity of 1800K/1800_complete.m3u8) is
itself encapsulated (in /index.html) and Section 5.1.2 does apply
this time, and the base URI of /vod/movie/master.m3u8 depends on the
base URI of /index.html

No.

The entity for </vod/movie/master.m3u8> is *not* embedded in the HTML.
It's *URI* is. This is very different.

Unless I'm missing something, this is simply a misinterpretation of the
terminology.

Best regards, Julian

[Julian Reschke]

Thanks Julian.
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.
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

[Julian Reschke]

If that is the case, then we should seek a way to communicate that to
the industry as we see many cases of misinterpretations.
...

Assuming the WG agrees with my interpretation, I would recommend to
simply update the internet draft with these conclusions and to point
anybody who disagrees to that document.

Best regards, Julian

[Ori Finkelman]

Draft was submitted.

https://datatracker.ietf.org/doc/draft-finkelman-httpbis-has-redirecting/

Thanks Ali.

Regards,
Ori

Post by Julian Reschke

If that is the case, then we should seek a way to communicate that to
the industry as we see many cases of misinterpretations.
...

Assuming the WG agrees with my interpretation, I would recommend to
simply update the internet draft with these conclusions and to point
anybody who disagrees to that document.
Best regards, Julian

[Mark Nottingham]

My .02 -

I was thinking that at most, we'd look at adding a bit of text to 3xx to make it clear that a redirected request is a genuinely new request, and therefore has its own base URL, etc. The fact that some clients follow them automatically is immaterial.

Cheers,

If that is the case, then we should seek a way to communicate that to the industry as we see many cases of misinterpretations.
...

Assuming the WG agrees with my interpretation, I would recommend to simply update the internet draft with these conclusions and to point anybody who disagrees to that document.
Best regards, Julian

--
Mark Nottingham https://www.mnot.net/

[Julian Reschke]

Post by Mark Nottingham
My .02 -
I was thinking that at most, we'd look at adding a bit of text to 3xx to make it clear that a redirected request is a genuinely new request, and therefore has its own base URL, etc. The fact that some clients follow them automatically is immaterial.
...

...I agree with that fact, but I believe browser might have to do some
homework to get the final URI exposed in XMLHttpRequest...

Best regards, Julian

[Thomas Peterson]

Not all implementations are using XMLHttpRequest, dash.js has migrated over to using fetch whereas hls.js does not appear to. This only stands to further complicate considerations for implementations and perhaps adding text to the 3xx is not suitable.

Regards

Post by Mark Nottingham
My .02 -
I was thinking that at most, we'd look at adding a bit of text to 3xx to make it clear that a redirected request is a genuinely new request, and therefore has its own base URL, etc. The fact that some clients follow them automatically is immaterial.
...

....I agree with that fact, but I believe browser might have to do some
homework to get the final URI exposed in XMLHttpRequest...

Best regards, Julian

_______________________________________________
GGIE mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/ggie