Closed Bug 150680 Opened 22 years ago Closed 22 years ago

Blank Window for Login

Categories

(Tech Evangelism Graveyard :: English US, defect, P1)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: charles.vorndran, Assigned: doronr)

References

(
URL
)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    2002052306

Window is completely blank.  Page source is <html><body></body></html>

Reproducible: Always
Steps to Reproduce:
1. https://www.gkls.xerox.com/gkls/
2. Select Login from the Login | Accounts | Contents ... bar


Actual Results:    Target window at
https://www.gkls.xerox.com/gkls/dscgi/ds.py/Login is blank.  Page source is
<html><body></body></html>.  


Expected Results:  Doing the same in Netscape 4.77 results in a richly populated
Login window with plenty of content in the <body> element.
I can confirm this with 2002053012 on Win2k - and IE 5 on the other hand.
I also changed the mozilla user agent to IE5 and N4.7 with uabar(.mozdev.org),
but that did not make the site send more data...
-> PSM for triage

i see this with Mozilla1.0 (win2k)
Assignee: Matti → ssaux
Status: UNCONFIRMED → NEW
Component: Browser-General → Client Library
Ever confirmed: true
Product: Browser → PSM
QA Contact: imajes-qa → junruh
Version: other → unspecified
*** Bug 151647 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Priority: -- → P3
Version: unspecified → 2.3
That's a crazy bug.
It's not a regression, even Mozilla 0.9.4 based builds do not work.
Assignee: ssaux → kaie
Severity: normal → major
OS: Windows NT → All
Priority: P3 → P1
Hardware: PC → All
Keywords: nsbeta1 → nsbeta1+
I was very curious what problem this is.

I can confirm that other browsers can fetch this page just fine. I was also able
to use a command line client to obtain the page successfully, upload it to my
own server, and view the page successfully from that server.

Here is what happens:


At the HTTP protocol level, Mozilla sends the following request to the server:

  GET /gkls/dscgi/ds.py/Login HTTP/1.1
  Host: www.gkls.xerox.com
  User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020629
  Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
  Accept-Language: en-us, en;q=0.50
  Accept-Encoding: gzip, deflate, compress;q=0.9
  Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
  Keep-Alive: 300
  Connection: keep-alive


The server does not like that request. Instead of giving out the page, it
responds with a error code:

  HTTP/1.1 400 'None' object has no attribute 'value'
  Server: Netscape-Enterprise/4.1
  Date: Thu, 18 Jul 2002 01:52:21 GMT
  Docushare-version: 2.2
  Docushare-user: Guest (User-1)
  Content-Type: text/xml
  Docushare-error: DSErrorException 'None' object has no attribute 'value'
  Content-Length: 0


Because simpler HTTP requests cause the server to actually give out the login
page, I tested which line triggers the problem. It is:
  Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1

If you submit the above request to the server without the Accept: line, the
server does not give the page.


What's next?

We need to ask other Mozilla developers, who can judge, whether the Accept: line
we are sending out is valid.

If the request we are sending is just fine, somebody should contact Xerox and
let them know their server has a problem.


And last but not least, we should file a separate bug, and make Mozilla give out
better error messages instead of just showing a blank page...

Note that in the previous comment, the header line starting with
  Accept:
seems to be wrapping. This happened as a result of adding the comment to this bug.

Of course, the request sent to the server sends the Accept: request header in a
single line.

Reassigning to
  Browser / Networking: HTTP

Please read my previous analysis and check whether the header Mozilla is sending
out is a valid request.

If it is, this bug should be given to Evangelism.
Assignee: kaie → darin
Component: Client Library → Networking: HTTP
Product: PSM → Browser
QA Contact: junruh → tever
Version: 2.3 → other
yes, our Accept header is completely valid under HTTP/1.1, and the Xerox server
(NES 4.1) claims to speak HTTP/1.1, so this must be a server bug.

kai: thx for investigating this one :-)

-> tech evang
Assignee: darin → doron
Component: Networking: HTTP → US General
Product: Browser → Tech Evangelism
QA Contact: tever → zach
Version: other → unspecified
Xerox installed a Service Pack on this DocuShare server the fixed this bug.  
Thank you, Darin, Kai, et al, for putting in the time to investigate this.  
Apparently, the problem was already identified but it was probably not hot 
enough to roll out the fix.  Hopefully, this will help speed the rollout of this 
service pack to the Xerox internal installations of this product, as well.  

I think we can consider this bug as FIXED and this matter closed, unless someone 
has a more formal process in  mind.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.