rfc2616 uncompliance (content-location)

RESOLVED DUPLICATE of bug 109553

Status

()

Firefox
General
RESOLVED DUPLICATE of bug 109553
13 years ago
13 years ago

People

(Reporter: David Delbecq, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050610 Firefox/1.0.4 (Debian package 1.0.4-3)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050610 Firefox/1.0.4 (Debian package 1.0.4-3)

According to rfc 2616 section 14.14   Content-Location,
"The value of Content-Location also defines the base URI for the entity."
However, in the above page, this Content-Location in response is not taken into
account. If it were to be taken into account, the example url would simply not
work (The content location provided in http header points to an inexistant domain)


Reproducible: Always

Steps to Reproduce:
See details

Actual Results:  
Relative ressources (like pictures) were loaded as relative to typed url in
address bar, not relative to Content-Location information in headers

Expected Results:  
Attemps of browser to load ressources relative to Content-Location (aka consider
Content-Location as Base URL)

The provided example URL has been tested with konqueror and amaya, they both
have the excpected RFC conformance result (aka provided badly configured example
website does not work)
The spec also says "The Content-Location value is not a replacement for the
original requested URI"

*** This bug has been marked as a duplicate of 109553 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.