249953 - Page do not open when Novell server needs login name and password

Status: RESOLVED INVALID

(Core :: Networking, defect, P2)

Description

[Pavol Svorc]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; cs-CZ; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Win98; cs-CZ; rv:1.7) Gecko/20040616

When I try use next URL, browser do not open the page where I may type login and
password.
https://192.168.1.252:8009/NWHealth
But if I use simle URL as https://192.168.1.252:8009 I may type login and
password and then I can go to NWHealth page.
When I was logged, then I can use in new window
https://192.168.1.252:8009/NWHealth too and it works OK. Only if I try it first
time I must use https://192.168.1.252:8009 because
https://192.168.1.252:8009/NWHealth doesn't work. 
In Internet Explorer when I use https://192.168.1.252:8009/NWHealth I may type
login and name and then browser go to /NWHealth automatically. 
The url https://192.168.1.252 is private Novell Netware server which has not
acces to public internet, but I think it doesn't matter.

Reproducible: Always
Steps to Reproduce:
1. You must use another URL that I described in 'details'
2. You must use URL as https://some.ip.address:some_port/Some_detail_page and
server need login name and password


Actual Results:  
The page can't display.

Expected Results:  
I think, page with login and name should be shown, then should be shown datail_page.

Comment 1

[Bill Mason]

*** Bug 249954 has been marked as a duplicate of this bug. ***

Comment 2

[R.K.Aa.]

can you create a http log :
http://www.mozilla.org/projects/netlib/http/http-debugging.html and attach the
log to this bug.

(When you've done trying to access the site: exit mozilla, to avoid collecting
too much irrelevant data in the log)

Comment 3

[Mike Connor [:mconnor]]

*** Bug 249954 has been marked as a duplicate of this bug. ***

Comment 4

[Pavol Svorc]

Attachment: Log file

Here is the log file when I try open https://192.168.1.252:8009/NWHealth.
Browser is waiting 'for server'... I must press cancel button.

Comment 5

[R.K.Aa.]

Just to have tried it: 

Set the preference for Advanced->HTTP Networking to HTTP 1.0 for both direct
connection and proxy connection and see if that changes anything.
(Delete cache before trying again)
Also make sure you don't use pipelining - it's experimental.

Any change?

Comment 6

[Pavol Svorc]

> Set the preference for Advanced->HTTP Networking to HTTP 1.0 for both direct

Yes, with  HTTP 1.0 it works OK. Is it problem in implementation HTTP 1.1 in
mozilla?

Comment 7

[R.K.Aa.]

Some proxies aren't 1.1 compatible even if they claim to be.
Can you try setting only the proxy traffic to 1.0 and see what happens then
(Again: Delete cache before testing)

Comment 8

[Pavol Svorc]

Attachment: log2

Here is next log. Proxy is set to http 1.0 and direct connect to 1.1. It
doesn't work again. It is maybe problem in mozilla. I don't use proxy at all.

Comment 9

[Jesiah S]

Can you add your novell version and the name of the NLM for this service to the
summary to aid in searching. Thanks.
Also, try a newer version to see if that soves anything

Comment 10

[Darin Fisher]

This looks like a familiar problem.  Here's the interesting part of the log:

-16002981[78a010]: nsHttpTransaction::HandleContent [this=27f31e0 count=0]
-16002981[78a010]: nsHttpTransaction::HandleContentStart [this=27f31e0]
-16002981[78a010]: http response [
-16002981[78a010]:   HTTP/1.1 302 Object Moved Temporarily
-16002981[78a010]:   Server: NetWare HTTP Stack
-16002981[78a010]:   Date: Fri, 9 Jul 2004 09:26:28 GMT
-16002981[78a010]:   Location: https://192.168.1.252:8009/_LOGIN_SERVER_
-16002981[78a010]:   Set-Cookie: loginReferralURL=/NWHealth; path=/
httpstkWMLlogin= ; path=/; expires=Friday, 01-Jan-1999 00:00:00 GMT
-16002981[78a010]:   Connection: Keep-Alive
-16002981[78a010]: ]
-16002981[78a010]: nsHttpConnection::OnHeadersAvailable [this=f814e0
trans=27f31e0 response-head=f86870]
-16002981[78a010]: Connection can be reused [this=f814e0 idle-timeout=300
-16002981[78a010]: waiting for the server to close the connection.

It would appear that the server never sends any message body along with the 302
like they are supposed to.  Moreover, it appears that the server never closes
the connection.  Based on the headers, we expect that the connection will stay
open until the server closes it.  Switching the client to HTTP/1.0 probably
works because it causes the server to generate a different response.  Can you
post a log file corresponding to the success case?  (i.e., when mozilla is
configured to speak only HTTP/1.0)  thx!

This does not look like a proxy server issue at all.

Looks like a server bug, but IIRC internet explorer manages to work around this
behavior by following the redirect straight away.  We should do the same.  I
think this is a duplicate bug report.  Confirming.

Comment 11

[Darin Fisher]

-> default owner

Comment 12

[Matthias Versen [:Matti]]

Is this still an issue ?