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

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.

> 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 07:20:46 UTC