W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: NEW ISSUE: Drop Content-Location

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 6 May 2009 11:26:09 +1000
Cc: David Morris <dwm@xpasc.com>, ietf-http-wg@w3.org
Message-Id: <E9D0F1E9-FD45-48BE-AE79-0DECB06C1918@mnot.net>
To: Yves Lafon <ylafon@w3.org>
s/rfc2257/rfc2557/

Would it be workable to specify that the base setting semantics of  
content-location are only enabled when done so explicitly by the  
format? That would allow 2557 to still function as specified (assuming  
that's desirable).


On 07/04/2009, at 5:33 PM, Yves Lafon wrote:

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


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 6 May 2009 01:26:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:02 GMT