- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 05 Sep 2014 07:33:08 -0400
- To: Mark Nottingham <mnot@mnot.net>, "Julian F. Reschke" <julian.reschke@gmx.de>
- CC: Yves Lafon <ylafon@w3.org>, Roy Fielding <fielding@gbiv.com>, Martin Thomson <martin.thomson@gmail.com>, Eric Prud'hommeaux <eric@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 09/05/2014 06:35 AM, Mark Nottingham wrote: > Right. Am I reading this correctly, that you and Julian think it would be better to use 303 + "Preference-Applied: contents-of-related" + the actual representation of B being returned, instead of a new response code? Procedurally, is that any easier to standardize? In that case, would it make sense to generalize the preference to not just be for 303, but for all redirects? Maybe "Prefer: send-content-and-headers-for-redirection-location" or "Prefer: server-follow-redirection" which could also be used with 301 or 307. > Also — Content-Location is *not* a flag that conneg has happened; that’s only a use case for it. I don't think we're suggesting it is, just that it's nice to keep it available for telling the client a URI for the content. > One important point that I don’t see being addressed here is that resource A is *claiming* that it’s presenting a representation of resource B — it isn’t authoritative for that resource (even if they’re on the same server). That’s an important distinction, and it’s precisely the one made by Content-Location. I hesitate to say anything on this, since I'm aware I've missed some of the discussion this key point. I expect the thinking is that since the client is asking A, and trusting A to give it content, and A is providing content, it's not unreasonable to also trust A to say "I got this content from B". It's then up to the client to decide how seriously to take the claim that it came from B. The I-D is clear that folks are not to cache it as if it came from B (unless they have other justification). -- Sandro > Cheers, > > > On 5 Sep 2014, at 1:01 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > >> On 2014-09-05 11:51, Yves Lafon wrote: >>> On Fri, 5 Sep 2014, Julian Reschke wrote: >>> >>>>> In LDP applications, these calls are more like RPC than like displaying >>>>> a web-page, so milliseconds might possibly count more than they do in >>>>> more common existing applications. >>>>> ... >>>> It that's the problem, have you considered to tweak 303 to actually >>>> return the representation of the "other" resource (using a new Prefer >>>> option?)? >>>> >>>> GET / HTTP/1.1 >>>> Prefer: contents-of-related >>>> >>>> HTTP/1.1 303 SEE OTHER >>>> Location: /other >>>> Preference-Applied: contents-of-related >>>> ... >>>> >>>> (representation of /other) >>> From 7231: >>> << >>> Except for responses to a HEAD request, the representation of a 303 >>> response ought to contain a short hypertext note with a hyperlink to >>> the same URI reference provided in the Location header field. >>> So tweaking 303 to return the content of Location: would be weird, even >>> with the introduction of a new conneg header. >> I believe you're reading too much into the "ought to". >> >> If the client clearly says "give me the representation of the 'other' resource", then the server ought to be able to do that. (pun intended) >> >> Best regards, Julian >> > -- > Mark Nottingham http://www.mnot.net/ > > > >
Received on Friday, 5 September 2014 11:33:17 UTC