Re: HTTP redirect section draft-ietf-httpbis-bcp56bis-08

Hi Chris,
I don't think 301 is the right solution for CDN as we don't want the
redirection to be permanent.
Also, the main problem is not what happens when client requests the same
playlist again (if it goes to the original link it's not that bad), but
what happens when it uses the URI of this playlist in order to resolve
relative references that are parsed from that playlist.

As Julian explain, section 5.1 of RFC 3986 states it should use the
playlist retrieval URI, after redirect, as the base URI for computing URIa
of the relative references found within the playlist.

The discussion here is whether this is clear enough for the reader if the
RFCs (7231 and 3986 together).

My feeling is that the opinion here is that it is clear enough and there is
no place for further clarifications ?
We can publish guidelines for video player developers according to that.

Thanks,
Ori



On Wed, Nov 14, 2018 at 2:37 AM Chris Lemmons <alficles@gmail.com> wrote:

> So, if I understand the question rightly, what is unclear is what a
> client ought to do when a given reference is to be used more than
> once.
>
> So, if a client is processing an entity and finds a reference, which
> it processes according to the rules for either absolute or relative
> references, it normally just requests it. If the request comes back
> with a 302, it follows the redirect once and obtains content from the
> new location. The question then is what URL should the client use if
> it needs to request the content again (as one might in an HLS or DASH
> scenario).
>
> I think RFC 7231 is relatively clear:
>     Since the redirection might be altered on occasion, the client
> ought to continue to use the effective request URI for future
> requests.
> "Effective request URI" is clearly the original URI, before
> redirection. This text is intended to contrast with the previous
> section, 301:
>     [...] the target resource has been assigned a new permanent URI
> and any future references to this resource ought to use one of the
> enclosed URIs. Clients with link-editing capabilities ought to
> automatically re-link references to the effective request URI to one
> or more of the new references sent by the server, where possible.
>
> If you wanted the client to always use the new address, it sounds like
> the answer should be 301, not 302. 301s are cacheable and
> Cache-Control headers can be used to suggest how clients ought to
> cache things. I don't think it's possible to tell the client they must
> use the new address from then on, though.
>
> On Tue, Nov 13, 2018 at 6:07 AM Ori Finkelman <orif@qwilt.com> wrote:
> >
> > Hi Julian,
> > Ideally I would seek clarifications for both the meaning of a redirect
> and for the base URI establishment (the confusion about embedding resource).
> > But, while the embedding issue I think we can explain well enough using
> the inputs we got from you and Patrick, the redirect IMHO is still
> confusing due to the
> > "the client ought to continue to use the effective request URI for
> future requests"
> >
> > Clarifying both issues would make it very clear that anything else is
> not conforming with the RFC and would help conclude the debates in the
> player development community.
> >
> > Thanks,
> > Ori
> >
> >
> > On Tue, Nov 13, 2018 at 2:51 PM Julian Reschke <julian.reschke@gmx.de>
> wrote:
> >>
> >> On 2018-11-13 12:32, Ori Finkelman wrote:
> >> > Hi Daniel,
> >> > Indeed the base URI is not mentioned,
> >> > https://tools.ietf.org/html/rfc7231#section-6.4.3 refers to the
> >> > effective request URI.
> >> > So, what is the effective request URI ? from this phrasing my
> >> > understanding is that it is the original URI before redirection (as
> the
> >> > context is that the the redirection might be altered).
> >> >
> >> > If it's the original URI, then this is, IMHO,  what is causing
> >> > confusion, as some reads it as "you should not use the redirected URL
> >> > for anything other than the local retrieval of that specific request".
> >> > This, is in contradiction with
> >> > https://tools.ietf.org/html/rfc3986#section-5.1.3, but the confusion
> is
> >> > still there.
> >> >
> >> > I am trying to have a clarification so I can go back with that to the
> >> > video players community and promote fixes to align with the correct
> >> > behavior.
> >> >
> >> > What I would suggest as phrasing (without taking a stand where to put
> it):
> >> > "Clients automatically following redirect must note that the
> redirected
> >> > request is a separate request and as such, the URI of the retrieved
> >> > object after redirection is the redirection URI"
> >> >
> >> > Thanks,
> >> > Ori
> >>
> >> ...once again: does this fix the issue that you reported? Wasn't that
> >> really about the confusion about "embedding a resource"?
> >>
> >> Best regards, Julian
> >
> >
> >
> > --
> > Ori Finkelman
> > Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com
>


-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
orif@qwilt.com