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

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.

Really I'd suggest the response code should be whatever the target of 
the 303 provides.

Also, all the headers should be what the target of the 303 provides, 
except the Preference-Applied and Vary: Prefer.

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

        -- Sandro




> > ...
>
> Best regards, Julian
>

Received on Sunday, 28 September 2014 21:04:19 UTC