Re: NEW ISSUE: Drop Content-Location

On Tue, 7 Apr 2009, Mark Nottingham wrote:

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

There is a difference between a browser and an editor there. Browsers 
already chose to not implement CL at all because of errors in some server 
configurations (mostly reverse proxies, but not only). For editors it is 
quite different, as finding the document really served is needed when you 
want to save it back.

So getting rid of CL is not an option, unless you are a pure browser. 
Removing the base setting property of CL is one option, it would be 
against rfc2257, but at least it will be consistent with most of the 
errors in server configurations that led with the behaviour of browser.

> 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/
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 7 April 2009 07:33:41 UTC