Closed Bug 18134 Opened 25 years ago Closed 25 years ago

DOGFOOD: relative URLs do not resolve correctly from web-based pages (FILE: access o.k.)

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rxsherm, Assigned: jud)

References

(
URL
)

Details

(Whiteboard: [PDT+])

Attachments

(2 files)

This should solve the problem, Judson is just testing it.
3.36 KB, patch
Details | Diff | Splinter Review
Another try without memory alloc
1.40 KB, patch
Details | Diff | Splinter Review 
Given the following HTML :

<html>
<a href="../../helloworld.html">hello world that doesnt resolve URL
properly</a><br>
</html>

The relative link above will not resolve properly if this page is retrieved from
a web server (HTTP:-prefixed) URL. (If this page is retrieved from a FILE: path,
it works o.k.)

In Mozilla, the URL not only displays incorrectly when highlighted (it appears
as http://helloworld.html) but when clicked, the browser attempts to connect to
the bad URL.
*** Bug 18202 has been marked as a duplicate of this bug. ***
*** Bug 18202 has been marked as a duplicate of this bug. ***
Assignee: leger → gagan
Component: Browser-General → Necko
QA Contact: leger → tever
tever, can you try with latest build and give your results.  Thanks!
Hmm... this looks like a regression.
Oooppss ... ok this is very much likely the new resolve stuff. We no longer
handle the path independly before exposing it to RelpaceMess. So the ../..
leakes into the host, when there are more .. than directory depth.
URL: http://www.idrive.com/valeski/web/one...
Status: NEW → ASSIGNED
andreas' latest patch fixes this (I verified it). Test case (internal) at URL in
URL field. You should be able to click on the link and goto a page two dirs deep
with the text "Got it!"
Summary: relative URLs do not resolve correctly from web-based pages (FILE: access o.k.) → DOGFOOD: relative URLs do not resolve correctly from web-based pages (FILE: access o.k.)
This breaks links inside of tinderbox if you're accessing it through
<http://tinderbox.mozilla.org/> rather than
<http://cvs-mirror.mozilla.org/tinderbox/>.  This probably has the potential to
break a non-trivial number of web pages... seems like good M11 fodder, given
that it's a regression and Andreas has already been kind enough to submit a
patch.
Target Milestone: M11
agreed. m11 approval?
added new test case url (old http server wasn't working properly). same steps to
verify
Assignee: gagan → valeski
Status: ASSIGNED → NEW
Blocks: 13449
Whiteboard: [PDT+]
Putting on PDT+ radar.  chofmann believes the fix was checked in.  Is this
fixed?
The tinderbox case, at least, now works correctly.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fix checked in a few hours ago. sorry about that.
Status: RESOLVED → VERIFIED
Verified on 11/23 build. Various levels of relative URLs tested.
Status: VERIFIED → REOPENED
Shows correctly, but when cliking on some link in the page the image dissapers.

Load http://www.avp.ee

Look at the banner on the top of the screen, click a link on the page, the
banner dissapers, when all other is still shown.

I do not know may I or not to make chainges in status, but I do it. If not write
to me, please.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
What you describe is an entirely different problem, it is covered in bug 18790.
The problem described in this bug is still fixed. So I'm closing this one again.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Status: RESOLVED → VERIFIED
works fine on all platforms (14th's build). marking verified.
works fine on all platforms (14th's build). marking verified.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: