Closed Bug 3413 Opened 26 years ago Closed 26 years ago

Trailing slash

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Other
Type:
defect

Tracking

()

Status:
CLOSED FIXED

People

(Reporter: fornixon, Assigned: nisheeth_mozilla)

References

(
URL
)

Details

The JavaScript redirect is looking in the wrong folder for an html file, resulting in a 404 error. The code in the 204.40.42.155/~webteam/calendar/index.html file is this: <SCRIPT LANGUAGE="JavaScript"> <!-- Stamp = new Date(); var Month; var MonthName; Month = (Stamp.getMonth() + 1) if (Month == 1) { document.location.href = "january.html" } if (Month == 2) { document.location.href = "february.html" } if (Month == 3) { document.location.href = "march.html" } if (Month == 4) { document.location.href = "april.html" } if (Month == 5) { document.location.href = "may.html" } if (Month == 6) { document.location.href = "june.html" } if (Month == 7) { document.location.href = "june.html" } if (Month == 8) { document.location.href = "june.html" } if (Month == 9) { document.location.href = "september.html" } if (Month == 10) { document.location.href = "october.html" } if (Month == 11) { document.location.href = "november.html" } if (Month == 12) { document.location.href = "december.html" } //--> </SCRIPT> The script will recognize the current month, but it will look in the /~webteam directory for the file instead of the /~webteam/calendar directory. Brad Nixon, fornixon@globalserve.net Found with the 3 March Win32 binary of NGLayout
Assignee: norris → vidur
A DOM thing.
QA Contact: 4590 → 3849
DOM thang
Assignee: vidur → dp
URL: 204.40.42.155/~webteam/calendar → http://204.40.42.155/~webteam/calendar
QA Contact: 3849 → 4590
This is a problem with URL resolution in nsHTTPURL. If you add a trailing slash to the URL, it works correctly. If you leave it out, it interprets the last component of the URL as a file name and strips it out.
QA Contact: 4590 → 3849
vidur, dude! dom thing! not my prob! hugs, --cmb.
Assignee: dp → spence
Severity: normal → major
Priority: P2 → P1
Target Milestone: M3
Spence fix this please. I think this should be like a check for '/' somewhere...
Assignee: spence → spence
Changing to meer.net so spence sees this.
Status: NEW → ASSIGNED
QA Contact: 3849 → 4616
assigning Prashant as QA contact
Assignee: spence → gagan
Status: ASSIGNED → NEW
Gagan, This needs your attension. I debugged it and see exactly what is going wrong. ParseURL() in nsHTTPUrl.cpp is getting a relative url. It strips the last component in the original url since it didn't end with a slash. I dont know what the right fix is though.
I worked on this code. Actually href property of object location represents entire URL. So when we say document.location.href = "january.html" it takes january.html as entire URL. So somehow we need to provide entire path. And it would be better to use location.replace method insted of directly assigning something to href property. I'm attaching sample code which I tested and works on my machine. Try this and I think it should work. <html> <head> <title>dfhg</title> </head> <body > <script> <!-- Stamp = new Date(); var Month; var MonthName; Month = (Stamp.getMonth() + 1) var filename="http://204.40.42.155/~webteam/calendar/"; if (Month == 1) { filename=filename+ "january.html"; } if (Month == 2) { filename=filename+ "february.html" } if (Month == 3) { filename=filename+ "march.html"; } if (Month == 4) { filename=filename+ "april.html" } if (Month == 5) { filename=filename+ "may.html" } if (Month == 6) { filename=filename+ "june.html" } if (Month == 7) { filename=filename+ "june.html" } if (Month == 8) { filename=filename+ "june.html" } if (Month == 9) { filename=filename+ "september.html" } if (Month == 10) { filename=filename+ "october.html" } if (Month == 11) { filename=filename+ "november.html" } if (Month == 12) { filename=filename+ "december.html" } document.location.replace(filename) //--> </script> </body> </html> It should work now.
*** Bug 3760 has been marked as a duplicate of this bug. ***
*** Bug 3760 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Summary: JavaScript Redirect → Trailing slash
This isn't really a javascript bug at all. Any time a directory request is made we have to update the location (or the representation there of) with a trailing slash. All subsequent requests use this trailing slash to construct the right URL. It seems to me that this updating of the trailing slash is broken. I am trying to find out if its in Netlib that we don't report it back correctly or in the shell that made the initial request.
Assignee: gagan → chofmann
Status: ASSIGNED → NEW
The problem lies in the webshell area which doesn't update the history entry with the corrected url. We do modify the original url correctly (except for the small fix that I am checking in) So this should go to whoever owns webshell(not in the components list)... assigning back to chofmann for that.
Assignee: chofmann → nisheeth
Accepting ownership of this because I am the webshell owner...
*** Bug 3863 has been marked as a duplicate of this bug. ***
I have a fix that fixes this and all the other dups marked on this bug. Thanks to Gagan for doing the detective work on this. Need permission to check in. I'll be in my cube at 10:00 am tomorrow to do the checkin...
Status: NEW → ASSIGNED
Adding chofmann@netscape.com to CC list so as to receive checkin permission.
*** Bug 3813 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
The fix is checked into SeaMonkey_M3_BRANCH and the tip. Approved by chofmann. Reviewed by rpotts. We check nsIURL's address in nsWebshell::OnStartBinding() and if a trailing slash has been added to it, we replace the topmost history entry with the new address.
Status: RESOLVED → REOPENED
So I checked some old builds circa Mar13 to reproduce the error. The Mac came up 404 and Linux quit. I tried to verify with the new builds and lo and behold the mac worked perfectly (well it worked) and Linux again quit in the same manner. I don't have any tools to debug on Linux so at the moment I can't be more helpful than that. I'm REOPENING the bug and changing platform to Linux. note: the above url redirects the browser to http://204.40.42.155/~webteam/calendar/march.html that page loads and displays fine on Linux (albeit slowly) so it's not some new issue with that page. the last thing I get in the console window is "URL to load in nsBrowserAppCore is http://204.40.42.155/~webteam/calendar" and then it just quits.
Status: REOPENED → ASSIGNED
Setting milestone to M4 and accepting bug...
Target Milestone: M3 → M4
Resolution: FIXED → ---
Clearing fixed resolution...
*** Bug 4126 has been marked as a duplicate of this bug. ***
While checking this out on Linux, I saw that the earlier fix had not survived changes that were made to webshell during M4 for reducing redundancy in the document load observation APIs. I have a patch that essentially re-applies the earlier fix which I think we should definitely check into M4 to meet our goal of always improving the quality of our milestone releases. With the patch, the redirect to http://204.40.42.155/~webteam/calendar/april.html works fine but we crash in the parser trying while loading the file. I'll file a bug on that crash and assign it to rickg. Need permission to checkin...
Just checked in the fix. Now, I'll look at Linux and see whether it crashes in the same place as win32 is crashing. If so, we can close this bug...
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
The following two messages are shown on the console before the Linux build crashes: >> Added page http://204.40.42.155/~webteam/calendar/ to the rdf:history datasource Document http://204.40.42.155/~webteam/calendar/ loaded successfully << The crash is happening in netlib and happens when we try to go directly to "http://204.40.42.155/~webteam/calendar/" as well. I'll open a new bug for that and assign it to gagan. This bug should be closed because the trailing slash in the url does get preserved for the re-direct and the history entry (as proved by the messages on the console).
Status: RESOLVED → CLOSED
Changing component to "Javascript Engine". "Javascript" component is being retired.
You need to log in before you can comment on or make changes to this bug.