- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 6 May 2009 11:26:09 +1000
- To: Yves Lafon <ylafon@w3.org>
- Cc: David Morris <dwm@xpasc.com>, ietf-http-wg@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 UTC