226373 - "/" is not automatically confirmed or appended at end of URL string to open location

Status: VERIFIED DUPLICATE of bug 212208

(SeaMonkey :: General, defect)

Description

[Gary Davidson]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20031007

I have discovered that if you are using Mozilla 1.5 or NetScape 7.1, and you try
to go to a 4D Webstar [www.starnine.com] web server and the open web location
URL includes a subdirectory [e.g. folder] at the end of the string, the load
will timeout and never happen.  This is not a problem with Internet Explorer. 
The problem is avoided by Internet Explorer because it checks to see that a "/"
is always at the end of the open location URL string, and adds it if it is
missing.  Mozilla 1.5 and Netscape 7.1 does not add the missing "/".

Reproducible: Always

Steps to Reproduce:
1. http://216.142.65.242/WebStarWeb/demo
2. Request to open will timeout and fail to go to the destination
3. Instead now do : http://216.142.65.242/WebStarWeb/demo/
4. Request to open works fine.

Actual Results:  
If step 1. is done, the request to open will timeout and fail to go to the
destination.
If step 3. is done, the request to open works fine.
If step 1. is done with Internet Explorer, the request to open works fine. 

Expected Results:  
Mozilla 1.5 needs to check for a "/" at the end of the open web location URL
string and if it is missing, then it must append a "/" to the end of the string.

Comment 1

[Bill Mason]

Leaving the trailing slash off works for me on other sites with 20031114
PC/WinXP, but not on this particular URL.  Perhaps something specific to this
server.

Comment 2

[Robert Mohr]

Confirming, but Mozilla should not add a trailing '/' just because the location
after the previous '/' didn't have a '.'--there are plenty of valid addresses
without '.' in their filenames.

Comment 3

[Jason Barnabe (np)]

WFM Moz 2003111808.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Mozilla 1.5 needs to check for a "/" at the end of the open web location URL
> string and if it is missing, then it must append a "/" to the end of the
> string.

No, it must do nothing of the sort....

Comment 5

[Gary Davidson]

Can anyone who has experience accessing web servers using 4D Webstar V server
software offer some advise on this unusual problem?  Please note that in the
provided example, I have purposely avoided going through a DNS forwarding
service that could mask the cause of the problem.  I also remind you that
Internet Explorer does NOT fail, but Mozilla V1.5 does.

Comment 6

[Jo Hermans]

Mozilla shouldn't add the "/" at all, because those 2 urls are *not* the same.
When you ask for <http://216.142.65.242/WebStarWeb/demo> , and the webserver
discovers that it's really a directory, then the browser should receive a
redirect to the real url <http://216.142.65.242/WebStarWeb/demo/>. That's why
it's a good advice to use only the "/" url, because it avoids the extra roundtrip.

I tried to find Webstar documentation, and I found the following text at
<http://charlotte.acns.nwu.edu/home/manual/manual.2f.html#pgfId=86179> :
"8 If no file is found, the URL matches a path to a folder, and it does not have
the trailing slash, WebSTAR will return a redirect URL for that folder with the
trailing slash, so the browser can resubmit the entry automatically. For
example, this URL: http://www.domain.com/widgets
will be converted to: http://www.domain.com/widgets/".

Reporter, it would be helpful if you could provide a HTTP log per the
instructions found here:
http://www.mozilla.org/projects/netlib/http/http-debugging.html

Comment 7

[Gary Davidson]

I found out that the WebStar version being used at the server is V4.5.

I have been advised that there are no settings in WebStar to make this function
for some browsers but not others.

I was also told that it possible that WebStar is doing it right (WebStar will
return a redirect URL for that folder with the trailing slash, so the browser
can resubmit the entry automatically) but maybe Netscape/Mozilla aren't
RECEIVING it properly for processing.

I had someone with access to a bunch of browsers conduct tests as shown below.

Here are the browsers that don't work:
Netscape 7.1 (PC/Win2000Pro)   [I presume this is the same as Mozilla V1.4]
Netscape 7.1 (Mac/OS 10.3.1)

Here are the browsers that work:
Netscape v6.2 (Mac/OS 10.3.1)
Netscape v6.2 (Mac/OS 9.0.4)
Netscape v4.7 (Mac/OS 9.0.4)
Explorer v6 (PC/Win2000Pro)
Explorer v5.2.3 (Mac/OS 10.3.1)
Explorer v5.1.7 (Mac/OS 9.1)
Explorer v4.51 (Mac/OS 9.1)
Safari  1.1 (Mac/OS 10.3.1)

I don't know anything more that what I have documented.

Comment 8

[Jon Henry]

Attachment: Log of HTTP traffic

Here is the requested log file, I launched Mozilla with the site's URL as the
command line argument so data from that site should be the only thing in here.
There is definitely a response from the server to redirect to the /demo/ url
from the /demo one, but other than that I don't know how to interpret this.

Comment 9

[Gary Davidson]

I had the site manager who is responsible for running the server using WebStar
contact tech support at 4D WebStar.  Frank, tech support for 4D WebStar read
what was here for this bug report, and he believes this is a bug from
Mozilla/Netscape side, saying, "Maybe Mozilla and Netscape are not setup to
interpret WebStar's command coming back in." If you reference the CASE #
(below), you are welcome to contact Frank directly for more technical assistance
- and Frank can forward heavy-tech-stuff to other 4D WebStar support staff, if
needed.

Frank (4D WebStar, Case# 30411) 408-557-4669 or 408-557-4600 (and select the
option to type in his name) or [e-mail] 

Comment 10

[Jo Hermans]

It seems to be a duplicate of bug 212208. According to bug 212208 comment 4, it
is caused by the hard TCP reset after the redirect, which confuses the
keep-alive mechanism. But Inter Exploder and Safri were able to work around bit,
although slowly (it took a few seconds, possilby because of some
connection-timeout).

Workaround is to disable keep-alives (see Preferences -> Advanced -> HTTP
Networking)

*** This bug has been marked as a duplicate of 212208 ***

Comment 11

[Darin Fisher]

verifying duplicate

Comment 12

[Gary Davidson]

We have been informed that this bug report is a duplicate of bug report # 212208
submitted in June 2003.  We now concur.

With this bug report being a fresh and independently discovered duplicate bug
that also is fixed by using the bug report # 212208 posted work-around by
disabling Keep-Alives, isn't it time for this 5 month old reported bug to be
fixed in Mozilla V1.6 and the corresponding Netscape?  

This might be a more serious bug then originally reported in this duplicate bug
report and the original bug report.  If a visitor goes to a website such as this
other test site http://www2.edserv.musc.edu/mozilla_test and the site responses
with an error, that visitor would likely not know that their browser failed and
it wasn't the site that failed, and that visitor may never attempt to visit that
site again. That is unacceptable when Internet Explorer, Mozilla 1.31 [and
earlier versions] and Netscape 6.0 [and earlier versions] all work.