Re: Redirection vs. Content-location (was Re: Filters as views (ISSUE-45))

On Fri, Feb 12, 2016 at 10:14 AM, Maik Riechert <maik.riechert@arcor.de>
wrote:

>
> Am 12.02.2016 um 09:28 schrieb Pierre-Antoine Champin:
>
> (I propose to change the thread subject, as this interesting topic is
> sidetracking from the original one)
>
> On Fri, Feb 12, 2016 at 9:58 AM, Ruben Verborgh <ruben.verborgh@ugent.be>
> wrote:
>
>>
>> > On 11 Feb 2016, at 23:41, Maik Riechert <maik.riechert@arcor.de> wrote:
>> >
>> >
>> >
>> >> Am 11.02.2016 um 18:48 schrieb Ruben Verborgh:
>> >> Hi Maik,
>> >>
>> >>> This should only be used if you want to point to a concrete
>> representation when directly returning an entity response following some
>> kind of content negotiation.
>> >> The spec seems to agree with you:
>> >>
>> >>>> For a response to a GET or HEAD request, [Content-Location] is an
>> indication
>> >>>>       that the effective request URI refers to a resource that is
>> >>>>       subject to content negotiation and the Content-Location
>> >>>>       field-value is a more specific identifier for the selected
>> >>>>       representation.
>> >> —https://tools.ietf.org/html/rfc7231#section-3.1.4.2
>> >>
>> >> That said, why can a page not be a content-negotiated version,
>> >> if the server has determined the client would not like long pages?
>> >> A representation can only present part of a resource;
>> >> in this case, the part just gets an identifier.
>> > I guess you could see it that way, even if it's a little bit stretched
>> maybe. But then you would explicitly say that a page is a representation
>> and not a resource, which would mean that you couldn't do content
>> negotiation on that page, and I think this is not what we want.
>>
>> That's why I insist that the notion of representation/resource is
>> relative. The resource "today's weather” has currently as representation
>> “the weather of 12 February 2016”, which in turn is a resource in its own
>> right that can be represented in HTML, JSON, etc. Depending on the
>> viewpoint, the 12 Feb weather is either a representation or a resource.
>>
>> So: no problem to do conneg on a page URI.
>>
>
> +1
>
> Hmm. Is this idea generally accepted? I'd rather say the resource "today's
> weather” has currently after conneg as representation “the weather of 12
> February 2016” in HTML format.
>
And it is the dump of bytes that Content-Location seems to refer to.
>
I can't read much else into the RFC words.
>

I tend to disagree with you. RFC 7231 says

> if one
> were to perform a GET request on [the Content-Location] URI at the time
of this
> message's generation, then a 200 (OK) response would contain the same
> representation.

and

> For a response to a GET or HEAD request, (...)
> the Content-Location field-value is a more specific
> identifier for the selected representation.

The first excerpt implies that the representation of the Content-Location
URI may change over time, so it does not necessarily identify "the dump of
bytes" but something that might be more abstract than that.

The second excerpt confirms that by saying that it identifies a "more
specific" resource, but does not says "the most specific". So to come back
to Ruben's example, I think that it would be valid if

  GET /today
  Host: weather.example.org

replied

  200 Ok
  Content-Location: /2016/02/15
  Content-Type: text/html
  Vary: *

and that in turn

  GET /2016/02/15
  Host: weather.example.org

replied

  200 Ok
  Content-Location: /2016/02/15.html
  Content-Type: text/html
  Vary: accept

(...)
>
> Overall, people seemed reluctant to this solution, in part because the
> interpretation of Content-Location does not make consensus among browser
> vendors:
>
> http://jigsaw.w3.org/HTTP/CL/
>
> This specific browser problem is solved by RFC7231 (which Ruben linked to)
> which obsoletes RFC2616:
>
> " The definition of Content-Location has been changed to no longer
>    affect the base URI for resolving relative URI references, due to
>    poor implementation support and the undesirable effect of potentially
>    breaking relative links in content-negotiated resources.
>    (Section 3.1.4.2)"
>

Good catch, and good news :)

  pa



> But still, I have a feeling that Content-Location is not yet meant to do
> the thing that we would like here, and that is to essentially override the
> request URI with the Content-Location URI and use that for processing.
> Right?
>
> Cheers
> Maik
>
>
> Personally, I think this is an elegant alternative to redirection,
> although I don't think that Hydra should mandate one or the other.
>
> pa
>
>
>
>> >
>> > Let me know what you think, maybe I'm wrong here.
>> >
>> > Cheers
>> > Maik
>>
>>
>
>