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

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

Received on Wednesday, 14 November 2018 11:04:30 UTC