Closed
Bug 34239
Opened 24 years ago
Closed 23 years ago
cleanup - stop converting \ to / for win32 url parsing
Categories
(Core :: Networking, defect, P3)
Tracking
()
Future
People
(Reporter: nate, Assigned: andreas.otte)
References
()
Details
(Whiteboard: fix in hand)
Attachments
(2 files)
*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"> </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"> </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.
Comment 2•24 years ago
|
||
I can't see this on 20000512 Win 95. nate@cherokeewebsolutions.com - are you still seeing this? Gerv
Comment 3•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
pollmann - what happened when you tested this with your Linux build? WORKSFORYOU? Gerv
Comment 5•24 years ago
|
||
Tested with Build # 2000051808 on RH 6.2. Bug was reproduced everytime.
Comment 6•24 years ago
|
||
I am also able to reproduce this bug, taking a look.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Updated•24 years ago
|
Target Milestone: --- → M18
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
CC'ing people who might be able to review the very tiny patch I'm about to post.
Comment 11•24 years ago
|
||
Updated•24 years ago
|
Target Milestone: M18 → M17
Comment 12•24 years ago
|
||
Simplified testcase available internally at http://blueviper.mcom.com/bugs/backslash.html
Comment 13•24 years ago
|
||
andreas should review this. It's small, but url parsing ripple effects can be significant.
Assignee | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
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: 24 years ago
Resolution: --- → WONTFIX
Assignee | ||
Comment 16•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
> 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?
Assignee | ||
Comment 19•24 years ago
|
||
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
Comment 20•24 years ago
|
||
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 → ---
Updated•24 years ago
|
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
Comment 21•24 years ago
|
||
*** Bug 47380 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 57550 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
*** Bug 84347 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
Comment 26•23 years ago
|
||
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
Assignee | ||
Comment 27•23 years ago
|
||
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.
Assignee | ||
Comment 28•23 years ago
|
||
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: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
Comment 29•22 years ago
|
||
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.
Description
•