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

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 <mailto:ruben.verborgh@ugent.be>> wrote:
>
>
>     > On 11 Feb 2016, at 23:41, Maik Riechert <maik.riechert@arcor.de
>     <mailto: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.


>
>     Ruben
>
>     > Apart from that, is Content-Location supposed to change
>     interpretation for GET requests? It seems like it is merely a way
>     to get a non-negotiated URL from which the exact same response
>     body can be retrieved at a later time. But it doesn't
>     automatically assign that URL to the request URL. I would regard
>     Content-Location always as optional for GET requests, and in that
>     case (leaving out Content-Location), if you serve out the first
>     page at /collection then a client would not know that this is
>     actually the first page. Sure, it would see that the collection
>     has a view but it can't create the connection that this view is
>     actually what the resource is.
>
>
> There was a debate in the LD community a few years back, where Ian 
> Davis proposed to use Content-Location as a cheaper alternative to 303 
> redirect.
>
> https://web.archive.org/web/20110510131329/http://iand.posterous.com/is-303-really-necessary
>
> There was some reactions there :
> https://groups.google.com/forum/#!topic/thosch/zLk-QZd3Ec0[1-25] 
> <https://groups.google.com/forum/#%21topic/thosch/zLk-QZd3Ec0[1-25]>
>
> 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)"

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
>
>