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

On 09/28/2014 07:13 PM, Matthew Kerwin wrote:
> On 29 September 2014 07:04, Sandro Hawke <sandro@w3.org 
> <mailto: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.

It sounds like you don't trust the Vary: Prefer to do its job. Are you 
just being cautious, or is there reason to think Vary doesn't actually 
work (or perhaps that I'm misunderstanding what it does).

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

Except if intermediate system wont even pass any body through with a 3xx 
response code.   That's what I was told, but I haven't done any kind of 
survey.


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

Yes, there's a lot to be said for this design (sending 303 and a body), 
if it would work.    I only have it second hand that it doesn't work, so 
I don't even know the original source of my claim that it doesn't.

>     ​
>     ​
>     ​
>
>     ​ ​
>     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.)

Understood, thanks.

        -- Sandro

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