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

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.

I imagine some people will still be uncomfortable with the idea of a 200 
OK response providing a representation of a different resource.   In a 
sense this violates various specs, or at least various people's ideas of 
how things should work.  But since this will only happen when the client 
and the server both agree to it, I'm not seeing what harm it would do.

So I'm happy with this if the TAG and HTTP WG don't think it breaks too 
much.    It's certainly easier than a new response code!

     -- Sandro

>> On use of Prefer, is there guidance somewhere?   I can't really tell
>> where one would use Prefer over a new header.   If Prefer existed, would
>> it have been better to make many of the existing request headers be done
>> with prefer?  It's easy to see how the Accept* headers and the If-*
>> headers could be thought of as client preferences.     Also Range.   And
>> Cache-Control.   Even Authorization and Cookie could kind of be seen as
>> client preferences on server behavior.
>
> That's a good question; my gut feeling is that it depends on how 
> frequently it is used.
>
>> I guess the difference is that Prefer can be dropped by intermediaries
>> and, essentially, can never cause any error condition.   So Accepts that
>> have a wildcard entry could be prefers.  And the If-*s could be.
>> Authorization could not be, since it can result in an error.
>>
>> Am I getting that right?   I really don't care -- I don't see any
>> advantage to Prefer, but I don't see any disadvantage, either.
>
> The disadvantage of defining a new header field is that you need to 
> define a syntax and write parsers, whereas with Prefer the definition 
> has been done already, and the parser needs to be written only once.
>
> Best regards, Julian
>

Received on Sunday, 28 September 2014 19:01:38 UTC