Bug 90967 – WebKit doesn't compute relative URLs based on Content-Location

• Component: Page Loading
• Status: UNCONFIRMED

[Brent Royal-Gordon]

RFC 2616 specifies that relative URLs should be computed with the Content-Location, if provided, as the base:

----

14.14 Content-Location

The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.

       Content-Location = "Content-Location" ":"
                         ( absoluteURI | relativeURI )

The value of Content-Location also defines the base URI for the entity.

----

However, WebKit does not appear to do this, at least on the W3C's test case (http://jigsaw.w3.org/HTTP/CL/).

Reproducible with WebKit nightly r122160 on OS X 10.7.3, Safari 7536.6.1 on OS X 10.7.3, and Safari 8536.25 on OS X 10.8 GM seed (12A269).

[Alexey Proskuryakov]

This is not implemented in Firefox or IE, so we probably shouldn't do this either.

For Apple engineers looking at this: <rdar://problem/8687961>.

[Brady Eidson]

(In reply to comment #1)
> This is not implemented in Firefox or IE, so we probably shouldn't do this either.
> 
> For Apple engineers looking at this: <rdar://problem/8687961>.

Agreed.  Since no browser does this there's no incompatibility.

Another reason we would consider it would be if a compelling real world use case came along.

We already meet the spec here, as the spec is a "MAY" directive.

[Greg Dennis]

You are right that there is no incompatibility, but I believe this is a violation of the spec as stated. The "may" is a constraint on the server, not on the client. The server may provide a Content-Location header, but if it is provided, the client "must" resolve relative URLs with respect to it.

[Brady Eidson]

(In reply to comment #3)
> You are right that there is no incompatibility, but I believe this is a violation of the spec as stated.

Specs are fantastic advisories for the future.  But the web as it exists today is more relevant than specs of the past.

The W3C test case URL you provide is dated 2002 and even mentions that no modern browser supports this.  Opera *used* to and then stopped.

Compatibility certainly trumps the spec in this case.  Unless you can provide a case of an actual broken application because of this then there's really nothing to do here.

[Greg Dennis]

Just to clarify, I didn't provide the test case URL, nor do I recommend it be prioritized for fixing. I only wanted to clarify that it is a violation of the W3C spec, because there was a statement to the contrary. I agree that there's nothing to do here, but not because WebKit already adheres to the spec (it doesn't), because there's is no incompatibility with other browsers.

[Brady Eidson]

(In reply to comment #5)
> Just to clarify, I didn't provide the test case URL, nor do I recommend it be prioritized for fixing. I only wanted to clarify that it is a violation of the W3C spec, because there was a statement to the contrary. I agree that there's nothing to do here, but not because WebKit already adheres to the spec (it doesn't), because there's is no incompatibility with other browsers.

I actually didn't even respond to that point because it's irrelevant in this case, but since you wanted to re-iterate it...

(In reply to comment #3)
> You are right that there is no incompatibility, but I believe this is a violation of the spec as stated. The "may" is a constraint on the server, not on the client. The server may provide a Content-Location header, but if it is provided, the client "must" resolve relative URLs with respect to it.

Can you point me to precisely what passage from what spec specifies the "must" behavior you're claiming?

Because what you quoted in comment #1 doesn't.