Re: Headers vs Response Code for 2NN Contents Of Related

On 29 September 2014 07:04, Sandro Hawke <sandro@w3.org> wrote:

> On 09/28/2014 03:14 PM, Julian Reschke wrote:
>
>> On 2014-09-28 21:01, Sandro Hawke wrote:
>>
>>> On 09/28/2014 03:20 AM, Julian Reschke wrote:
>>>
>>>> On 2014-09-28 01:57, Sandro Hawke wrote:
>>>>
>>>>> ...
>>>>>
>>>>>> Why don't you just make it:
>>>>>>
>>>>>>   Prefer: retrieve-contents-of-303-target
>>>>>>
>>>>>> (with a more suitable name...)
>>>>>>
>>>>>
>>>>> Hmmm.   What do you think about the rest of the proposal? Do you
>>>>> prefer this header-based design over the response-code based one? Are
>>>>> you okay with both or neither or just this one?
>>>>>
>>>>
>>>> My point being is that you don't need a new header field, just the
>>>> prefer parameter.
>>>>
>>>>
>>> Okay....   So the presence of "Preference-Applied:
>>> retrieve-content-of-303-target" (or whatever it ends up called, maybe
>>> just "follow-303") in the response headers would have the same semantics
>>> as the 2NN Contents Of Related response code would have! (And a Location
>>> header would be added saying where we ended up.) Yes, as far as I can
>>> see that would work technically.   Nice and simple.   I like it.
>>>
>>
>> It would be "retrieve", not "follow". So you'd still get a 303, but the
>> response body would be for the resource Location points to.
>>
>>
> I think the response code would need to be 200, not 303.   I've been told
> things wont work well with 3xx responses having bodies.
> ​
> ​
>
>
​If it's 200 you have to be careful to set the cache control headers etc.
so that intermediate caches don't screw things up. At least with a 303 the
default/naive behaviour is closer to what you want anyway. (I.e. in the
worst case, the right thing happens, albeit slower)​



> ​
> ​

​
> Really I'd suggest the response code should be whatever the target of the
> 303 provides.
> ​
> ​
>
>
​If it would have been anything other than 200, the server shouldn't send
it. Just send the original 303. Maybe add a warning or something ("If you
get that it might fail").



> ​
> ​
> ​
>
​​
> Also, all the headers should be what the target of the 303 provides,
> except the Preference-Applied and Vary: Prefer.
> ​
> ​
>
>
​That's why it's risky to send a 200. If you send a 303 it's clear (to both
endpoints, and to any intermediaries) that the metadata applies to the
*requested* resource. If you ask me, "follow redirect" is a dangerous
metaphor, and it might be better to instead use an encapsulation metaphor.
In the current world, the response to "GET /foo" is "You should see
/foo/bar instead" -- everyone understands that, things happen. I suggest
the response to "GET /foo, but also send me the eventual response if
there's a redirect" should be "You should see /foo/bar instead, which is:
{...}". Uninformed brainstorm thought: send a 303 with
"content-type:message/http"; might need a bit more machinery in the client,
not sure how much though.

A dumb cache that doesn't understand the "which is..." part either: 1)
passes everything through as-is, and everyone is happy; or 2) strips the
unknown bits and you're left with a 303, and everyone gets to the right
place eventually.



> ​
> ​
> ​
>
​​
> To my ear that sounds like the server "following" the 303, but I'm not
> attached to that terminology.  "retrieve" doesn't seem quite right since in
> many cases it'll actually be on the same server. Maybe
> "respond-as-if-from-target-of-303"?   How about "if-303-provide-content"?
>

If you want advice on colouring, I quite like the shade of "indirect".
However if you switch to an encapsulation metaphor, something along the
lines of "Prefer: include-other" isn't too bad. (I keep coming back to the
word "other" because 303 is "See Other", and that "other" is what we're
including.)

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/