Closed Bug 204103 Opened 22 years ago Closed 22 years ago

Logging on displays html source instead of webpage

Categories

(Tech Evangelism Graveyard :: English US, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: royrcjr, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030428 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030428 The URL is ALLTEL's online billing logon screen. After entering the userid and password, one clicks on the SUBMIT button and should be taken to a webpage displaying account information. Instead, one is taken to a display of what appears to be the HTML source of the webpage. Reproducible: Always Steps to Reproduce: 1. Go to above-mentioned URL. 2. Enter userid and password 3. Click on SUBMIT Actual Results: Display of HTML source Expected Results: Displayed a web page showing my account information. I was using the pinball theme (the one I normally use) when I first encountered the problem, so I switched to the modern theme thinking that might have something to do with it. No change in behavior. Next, I tried a brand new default profile, thinking that something in my profile might have caused the failure. The new profile used all defaults, including the classic theme. Still, Mozilla displayed HTML source instead of the page itself. To add insult to injury, IE6 displayed my account information, and I was able to pay my bill online. This page displayed properly using an earlier Mozilla nightly leading up to 1.4a. I don't remember which. I will go back a few builds and see whether I can find one that worked with this ALLTEL page.
I'm almost certain that this failure is related to an improper Content-type header field. IE will parse content--even text/plain!--as HTML if it "looks" like HTML according to some internal heuristic. There might be a config option to force-feed pages through the HTML parser, but I certainly hope that there is not. Content-type is there for a reason! Contact the webmaster and ask them to check the Content-type of the page that appears when you hit the log in button. --J
I went to my WIN98 box that is still running Mozilla 1.2 and displayed the page correctly. I'm not saying that the page, incidentally which is, https://ebill.alltel.com/AccountSummary has a proper Content-type header field, but the older release Mozilla is correctly displaying the page. Its build id is: Mozilla/5.0 (Windows, U, Win98; en-US, rv. 1.2) Gecko/20021121 .
Roy, it may be that you are seeing different servers due to DNS round robining. Please try again and right click the page, then choose page info and tell use what it says for the content type.
I went back and did a clean install of Mozilla 1.2.1 on my WINXP machine. The build id was: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv. 1.2.1) Gecko/20021130, and I used a new profile. The webpage showed correctly. I went back and did a clean install of Mozilla 1.3.1, build id: Mozilla/5.0 (Windows: U; Windows NT 5.1; en-US; rv. 1.3.1) Gecko/20030425. Again, with a new profile, the webpage displayed correctly. Now, I am on Mozilla 1.4b, build id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv. 1.4b) Gecko/20030502. With a new profile, the webpage displays as HTML source. As suggested, I right-clicked on the page with each release of Mozilla that I tested. In the case of 1.2.1 and 1.3.1, content type was "text/html". Page info, also, displayed META information, where Name="Content-Type" and Content="text/html;charset=iso-8859-1". In the case of 1.4b, content type was "text/plain". No META information was displayed. I did notice something strange with the page source, though. It began with <b><HTML>, instead of with <HTML>. I'm not extremely well-versed in HTML, but is the leading "<b>" a coding violation which 1.4b is paying closer attention to than the earlier releases of Mozilla?
That is really weird. Roy, do you know how to change your user agent preference? If not, there is uabar at mozdev.org or the sidebars at http://mozilla-evangelism.bclary.com/sidebars/. Try the page in your recent Mozilla 1.4b but with an older user agent string to see if we are looking at a server side sniffing issue.
Bob, I added: user_pref("general.useragent.override", "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv. 1.3.1) Gecko/20030425"); to my user.js file to mimic the last release of Mozilla that correctly displayed the page. Clicking on Help->About Mozilla showed that the override was indeed in effect. Mozilla 1.4b, however, continued to display the page's html source rather than the page itself. I even tried: user_pref("general.useragent.override", "Mozilla/5.0 (compatible; MSIE5.5; Windows 98;"); in my user.js file. Help->About Mozilla showed this override to be in effect. I even got a warning message when Mozilla started up saying something to the effect that the Netscape JAVA plug-in that I had was not compatible with IE, and it continued to open up. However, page's html source continued to be displayed rather than the page itself.
Roy, can you install LiveHTTPHeaders (http://livehttpheaders.mozdev.org/installation.html) and attach the headers you see when you load that page?
Sorry to take so long in responding. I believe that I have installed liveHTTPHeaders, but I am unable to get it to work. Is there some parameter that I must change? Going to the problem page continues to display the HTML source rather than the page itself. I am now running build 2003051108 for WIN32.
First, open your brower and click on the Tools->Web Developer->Live HTTP Headers option to open a window showing the requests and responses sent to and received from the server. Then visit the page in question. You will see an option to save the headers to a file. Do so and attach the file to this bug. Thanks!
The output is that of url: https://ebill.alltel.com/AccountSummary . This output was created using Mozilla build 2003051108.
please check if this problem still exists, because we want to get rid of unconfirmed bugs. Many bugs in here are strill unconfirmed, because eigher nobody sees the problem or nobody is able to get to the page because of a required login. (sorry for the spam)
*** Bug 203983 has been marked as a duplicate of this bug. ***
from bug 203983: this bug started happening between Mozilla 1.4a and 1.4b marking new based on existence of headers attachment and dupe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Roy, Neil: I have talked to Darin about this and whether it is really a browser bug or an evangelism issue. He needs to get a full network trace to see what is happening. He suggested something like: http://www.ethereal.com/. Can either of you help Darin diagnose this? He is willing to guide you on setting up ethereal.
Glad to help any way I can. I will download and try to install Ethereal.
I have now installed Windows Pcap and Ethereal. But I don't know what to do with them. Please advise, either by posting here or by private email.
tech evang june 2003 reorg
Assignee: aruner → english-us
Component: US Ecommerce → English US
QA Contact: bc → english-us
I do not know whether a code change to Mozilla or a change to the server hosting the AllTel website resulted in the URL displaying correctly, but the original URL, now, displays correctly. Both my WINXP Pro machine running 2003080204 and my WIN98SE machine running 2003073110 correctly display the AllTel online billing web pages. Thanks.
Thanks !
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Confirming WFM using Firebird 0803 and 0805.
Roy Campbell said in comment #18: (quote) I do not know whether a code change to Mozilla or a change to the server hosting the AllTel website resulted in the URL displaying correctly... (end quote) But I know. Alltel has changed nothing. An older version of Mozilla which displayed only source code still displays only source code: Mozilla 1.5a Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5a) Gecko/20030605 Therefore it must be the browser code that changed. That proves that this was a Browser bug all along and not an evangelism issue. (BTW, I never got any kind of response to comment #16, which was my reply to the request made in comment #14.)
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: