- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Apr 2009 12:37:45 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>, Anne van Kesteren <annevk@opera.com>, Ian Hickson <ian@hixie.ch>, Roy Fielding <fielding@gbiv.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>
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? Furthermore, would it be useful if we gave advice about generating relative Content-Locations, to avoid at least some of the errors described in this thread? On 31/03/2009, at 12:24 AM, Julian Reschke wrote: > The mail below (<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0254.html > >) seems to be the last in this thread, and seems to reflect the > consensus we reached. > > Should we record this as an issue then (it wasn't before), and > implement this change? > > BR, Julian > > Roy T. Fielding wrote: >> On Dec 4, 2006, at 11:09 AM, Mark Nottingham wrote: >>> HTTP headers have a separate name space in the message header >>> registry, so it can be done; >>> http://www.iana.org/assignments/message-headers/perm-headers.html >> That's a nice theory, but HTTP carries MIME messages and they are >> actually >> the same fields in one namespace. Conflicts are noticed by the >> folks who >> are responsible for maintaining MIME and they do, historically, >> object to >> the IESG when HTTP attempts to reuse them in a way that might lead to >> confusion if a message passes across protocol boundaries. >> At most, what we could do is say that a recipient may ignore the >> base-setting semantics of Content-Location when present in the >> outermost fields of an HTTP message received during HTTP >> communication. >> Personally, I think that would be a mistake. 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 > > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 7 April 2009 02:38:25 UTC