Closed Bug 3413 Opened 26 years ago Closed 25 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 → 25 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.