Re: NEW ISSUE: Drop Content-Location

If I understand correctly, neither weighing the errors nor allowing in- 
content base to have precedence will help.

Consider the content negotiation case (which AIUI is the most evident  
problem, from the browser vendor standpoint); if response is  
negotiated, it may or may not have an embedded base; if it doesn't,  
the error will still be evident.

Likewise, if go the 'least errors' path (and I share your discomfort  
here), a browser will need to actually dereference URLs to figure out  
what base to use, which is hardly practical (and even then, it may not  
be able to judge what qualifies as an error; is it just a 404, or  
something more subtle?).

As such, personally I think Roy's first proposed solution -- getting  
rid of the base-setting semantics of Content-Location -- is the only  
viable path.



On 07/04/2009, at 1:15 PM, David Morris wrote:

>
>
> On Tue, 7 Apr 2009, Mark Nottingham wrote:
>
>> It's not helpful to formulate the issue as 'Drop Content-Location';  
>> ATM, my inclination is to create it as 'Content-Location base- 
>> setting problems'.
>>
>> Anne and Ian, does this adequately encompass your issue? If other  
>> aspects are important, it would be helpful if you provided a  
>> succinct summary.
>>
>> I'm not sure we yet have consensus, but I'm optimistic that we're  
>> close. Roy made two proposals:
>>
>>> The only thing that should be changed at this point is 14.14:
>>>
>>> The value of Content-Location also defines the base URI for the
>>> entity.
>>> s/also defines/does not define/;
>>
>>
>>
>>> I would prefer to say
>>> that a recipient may disregard the base-setting semantics if there  
>>> also
>>> exists a base URI from the retrieval context and use of that base  
>>> URI
>>> for parsing relative references within the entity results in fewer
>>> errors than use of the Content-Location URI.  A bad Content-Location
>>> value SHOULD be reported to the user as an error.
>>
>>
>> Roy, which do you prefer, and does anyone else have a preference?
>
> I prefer a third choice ...
> ... a recipient SHOULD disregard the base-setting semantics if there
>     also exists a base URI from the retrieval context.
>
> I don't like the 'fewer errors' rule as that suggests the recipient is
> expected to try both and make a judgement.
>
> Also, I see no point in reporting a bad Content-Location to the user.
> I still hold the belief that here should be an error report method  
> which
> clients may use to report errors to the origin server. The origin is
> the responsible party with the potential to care. But that concept
> was shot down years ago.
>
> Also, reporting a bad value anywhere implies that the recipient must
> evaluate the value...
>
> Dave Morris
>


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 7 April 2009 04:15:49 UTC