W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: See Other vs Contents of Related, was: 2NN Contents Of Related (303 Shortcut)

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 05 Sep 2014 07:33:08 -0400
Message-ID: <54099F74.9070608@w3.org>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC