relative links resolved incorrectly ?
Max Andersen
Why is it that on
http://opensource.atlassian.com/projects/hibernate/secure/Dashboard.jspa
the link "ALL" has a relative link to "IssueNavigator.jspa" in the
source, but Opera 7 resolves it to:
http://opensource.atlassian.com/secure/views/IssueNavigator.jspa?reset=true&mode=hide&pid=10000
Which is of course wrong. Opera 6 doesn't do this.
It should be
Mozilla and IE resovles it correctly - so what's wrong here ?
The folks behind JIRA has been informed about this and are probably
going to change their JIRA impl. to handle this for Opera 7 clients, but
isn't this a bug in Opera that needs fixing preetty damn soon ?
/max
Yngve Nysaeter Pettersen
wrote:
They are sending a Content-Location header
HTTP/1.1 200 OK
Date: Tue, 06 May 2003 16:11:22 GMT
Server: Orion/1.6.0
Set-Cookie: JSESSIONID=**********; Path=/
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Location: /secure/views/dashboard.jsp
Transfer-Encoding: chunked
which imply that the Base URL is based on
http://opensource.atlassian.com/secure/views/dashboard.jsp
not
http://opensource.atlassian.com/projects/hibernate/secure/Dashboard.jspa
Which is the behaviour described in RFC 2616 sec 14.14 :
"The value of Content-Location also defines the base URI for the
entity."
Opera 7 uses this value if it is present and no Base URL declaration
is made in the document.
IOW: This is not a bug, it is a feature.
BTW: What is so sensitive about that page that they have to use a
"no-store" Cache directive to force the client to use RAM cache?
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yn...@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 51 Fax: +47 24 16 40 01
********************************************************************
Dario
Good analysis.
Opera 6.06 suffers the same problem of Mozilla and IE.
- Dario
Max Andersen
I can also see that java.sun.com bug parade has the same problem when
performing searches. They also resolve links incorrectly!
/max
Christoph Schneegans
> Which is the behaviour described in RFC 2616 sec 14.14 :
>
> "The value of Content-Location also defines the base URI for
> the entity."
>
> Opera 7 uses this value if it is present and no Base URL
> declaration is made in the document.
The implementation is so broken that I didn't realize until now
that Opera 7 supports the "Content-Location" header at all. If an
absolute URI such as
Content-Location: http://www.opera.com/
is specified, the header is completely ignored. This is a violation
of RFC 2616. Amaya 8.0 supports absolute URIs in the "Content-
Location" header. <http://schneegans.de/temp/content-location.aspx>
contains a simple test case.
Yngve Nysaeter Pettersen (Developer, Opera Software A/S)
wrote:
After we implemented "Content-Location" support we ran into a case where that
broke a site. The server on http://www.bookwire.com/ returned a Content-Location
of http://www.bookwire.com:3170/ (still does, probably a badly configured
server). Because there was no server on that port, the images (at least) broke.
We therefore decided to limit "Content-Location" handling so that protocol,
server and port have to match.
Christoph Schneegans
> After we implemented "Content-Location" support we ran into a
> case where that broke a site. (...)
>
> We therefore decided to limit "Content-Location" handling so
> that protocol, server and port have to match.
That's a joke, isn't it?