Closed Bug 34239 Opened 26 years ago Closed 24 years ago

cleanup - stop converting \ to / for win32 url parsing

Categories

(Core :: Networking, defect, P3)

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

Tracking

()

Status:
VERIFIED DUPLICATE of bug 32895
Milestone:
Future

People

(Reporter: nate, Assigned: andreas.otte)

References

(
URL
)

Details

(Whiteboard: fix in hand)

Attachments

(2 files)

URL Parsing fix for \ on non-win32 platforms (malformed testcase)
612 bytes, patch
Details | Diff | Splinter Review
patch: partial fix - stop converting \ to / for win32 url parsing
586 bytes, patch
Details | Diff | Splinter Review
*Reproducing the bug 1. click on a thumbnail on the left side frame (such as "Entry Point") *Results (what happens) 1. right frame will begin loading text 2. mozilla will stop when it tries to load the image 3. error message: "www.soulburn3d.com could not be found. Please check the name and try again." *Expected (what should have happened) 1. click the thumbnail 2. right frame loads text 3. right frame loads large image *HTML used to query the images (one small snippet of it anyhow) <a href="gallery.pl?image=devoured" TARGET="main"><img SRC="devoured_thumb.jpg" ALT="Devoured" HSPACE=2 VSPACE=2 BORDER=0 height=65 width=65></a><a href="gallery.pl?image=entrypoint" TARGET="main"><img SRC="entrypoint_thumb.jpg" ALT="Entry Point" HSPACE=2 VSPACE=2 BORDER=0 height=65 width=65></a> <br> *HTML for the resulting "large image" page (note this is the complete html) <head> <meta name="Author" content="Neil Blevins, Soulburn Studios, neil@soulburn3d.com"> <meta name="KeyWords" content="Neil, Blevins, Soulburn, Studio, Art, Computer, CG, Animations, MAX, 3DS, 3DStudio, Plugins, Robots, Mechs, Creatures, Monsters, SciFi, Fantasy, Images, Paintings, Sketches, Logos, Models"> <title>Soulburn Studios Art Gallery</title> </head> <body text="#CCCCCC" bgcolor="#000000" link="#999891" vlink="#676763" alink="#FF0000"> <table BORDER=0 CELLSPACING=9 CELLPADDING=3 WIDTH="200"> <tr> <td BGCOLOR="#333333"> <b><dt><center><font color="#FFFFFF">Entry Point</font></dt></center></b> <dt><center>No. 3D87, Feb 23rd 2000</dt></center> <dt><center>Programs: MAX 3.1, Grass-o-matic, Rayfx area Lights, Photoshop</dt></center> </td></tr> <tr><td> <img SRC="..\artgallery\entrypoint.jpg"> </td></tr> <tr> <td BGCOLOR="#333333">&nbsp;</td> </tr> <tr> <td> Another mood piece, the hairs were created using grass-o-matic, the nice soft shadows using Blur's new Area Lights. Textures in Photoshop, and post process blurring effects using max's built in render effects. It can be anything from an alien landscape to an extreme closeup of some one's green skin, you be the judge. </td> </tr> <tr> <td BGCOLOR="#333333">&nbsp;</td> </tr> </table> </BODY></HTML>
the error message is gone on linux 2000-050308 but the image doesn't load. Doesn't load if frame is opened in new window either. So a real testcase can be abstracted from for instance this URL: http://www.soulburn3d.com/artgallery/gallery.pl?image=devoured This gotta be a dup of something but i haven't found it yet.
I can't see this on 20000512 Win 95. nate@cherokeewebsolutions.com - are you still seeing this? Gerv
Image loads for me with tonight's build, NT. I'm waiting for my Linux build to complete, but will test that before closing this as worksforme.
pollmann - what happened when you tested this with your Linux build? WORKSFORYOU? Gerv
Tested with Build # 2000051808 on RH 6.2. Bug was reproduced everytime.
I am also able to reproduce this bug, taking a look.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → M18
This might have something to do with the fact that time image's URL is: <IMG SRC="..\artgallery\devoured.jpg"> Note the use of backslashes instead of forward slashes.
Apparently URL parsing is horked on Linux: <IMG SRC="..\artgallery\devoured.jpg"> This URL gets translated into a request for / on the host www.soulburn3d.com%5Cartgallery%5Cgallery_frames.htm As you might guess, DNS lookup for that hostname fails, so the resulting error message is displayed.
I have a fix for this in my tree.
Whiteboard: fix in hand
CC'ing people who might be able to review the very tiny patch I'm about to post.
Target Milestone: M18 → M17
Simplified testcase available internally at http://blueviper.mcom.com/bugs/backslash.html
andreas should review this. It's small, but url parsing ripple effects can be significant.
I don't like it at all. \ is a valid normal character inside URLs. It can always happen with charset conversion to get this. The character to show the URL hierarchy is /. I have strong requests to even remove the \ handling in CoalesceDirs completly not to enhance it. Putting this change in will reopen other bugs. I don't know how it was done with 4.x. I would mark this WONTFIX. Let the Homepage be changed.
Thanks Andreas, I will mark this one WONTFIX then. However, let me put in one more strong vote in to make \ work either on all platforms or none of them, this should definitely NOT be a platform specific thing - why would we display this page (in)correctly only for people running their browser on Windows?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
I'm currently running my build with a removed conversion of \ to / for XP_PC. Judson, as new owner of the DocShell: What about doing some fallback error handling when loading images or following relative links or even loading absolute URLs? If we fail for any reason in loading an image (or something similar) and the path contains a \, we could convert it to / and try again. This would keep urlparsing clean of the conversion stuff and we can do it only if something fails. This would allow loading of urls including \ which are perfectly valid on linux and also (after a load failure we could hide!) urls of the type described in this bug.
Marking verified wont fix.
Status: RESOLVED → VERIFIED
> I'm currently running my build with a removed conversion of \ to / for XP_PC. This apparently never got checked in because the test case still displays the image on Windows. Are there any plans to check it in?
There is a meta bug (bug 36736) on this uri fixup bugs. I still think it is better to solve the whole problem instead of fixing a symptom.
Blocks: 63736
So that this bug won't be crossed off the list of depends for Bug 63736 (the meta bug), I'm reopening it. I agree that we should fix the problem and not the symptom. :) I think this means that 1) do the fixups at the docshell level if loading fails, per your comment above and then 2) make our URL parsing platform neutral (check in your fix to remove conversion of \ to / from XP_PC)? That actually means that this bug depends on 63736 and not vice versa, because we can't fix this one until the docshell handles failed loads or there will be problems... ;)
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
No longer blocks: 63736
Status: REOPENED → ASSIGNED
OS: Linux → Windows 2000
Summary: mozilla unable to find domain for frame → cleanup - stop converting \ to / for win32 url parsing
Target Milestone: M17 → Future
Depends on: 63736
*** Bug 47380 has been marked as a duplicate of this bug. ***
*** Bug 57550 has been marked as a duplicate of this bug. ***
QA Contact update
QA Contact: petersen → amar
*** Bug 84347 has been marked as a duplicate of this bug. ***
Reassigning to you Andreas - this seems like more your area. Just attached a partial patch that probably breaks something or other on WIN32 (haven't tested). Maybe it doesn't help much - maybe it will save a few keystrokes. :)
Assignee: pollmann → andreas.otte
Status: ASSIGNED → NEW
If we go for this, it is exactly the patch we have to use. I have brought the topic to netscape.public.mozilla.netlib to get more opinions on it.
Marking as dup of bug 32895, the patch attached there is more complete. *** This bug has been marked as a duplicate of 32895 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
VERIFIED/dupe of networking bug
Status: RESOLVED → VERIFIED
Component: HTMLFrames → Networking
QA Contact: amar → benc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: