- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 30 Mar 2009 15:24:10 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: Mark Nottingham <mnot@yahoo-inc.com>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Monday, 30 March 2009 13:24:57 UTC