Content-Location base-setting problems

[mnot@…]

Browser implementers don't generally implement Content-Location's base-setting semantics, because of a number of cited problems;

1) Servers often set the wrong C-L, so that a non-existent location is given, and/or internal implementation details are exposed. E.g., if a gateway rewrites URLs but doesn't rewrite Content-Location.

2) HTTP's advice to set Content-Location when doing server-driven content negotiation results in links that are relative to a negotiated resource, rather than the desired (non-negotiated) URI.

See also:

​https://bugzilla.mozilla.org/show_bug.cgi?id=241981 ​https://bugzilla.mozilla.org/show_bug.cgi?id=238654

Tangental relation to #80 and #136.

[mnot@…]

Two proposals, both by Roy:

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.

[mnot@…]

Proposal:

Remove base-setting semantics for HTTP content-location header. Note that this differs from the MIME header of same name.

[julian.reschke@…]

From [712]:

Mention TRACE and OPTIONS as safe in prose (see #154)

[julian.reschke@…]

From [714]:

dropping base-setting semantics for C-L - expand the bit in the Changes section (see #154)