Søg i Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

HTML generated from Web server on different port than 80 is displayed wrongly on Firefox. Why ?

  • 11 svar
  • 1 har dette problem
  • 17 visninger
  • Seneste svar af gidigal

more options

Hello to Firefox community users,

I have a web server that generates HTML pages. When the web server is set to port 80 Firefox displays correctly the generated pages. When the port is different than 80 the HTML content is displayed as text and not parsed correctly by Firefox. Both Google Chrome and Microsoft Internet Explorer have no problems with other ports.

I looked in Firefox debugger and saw some warnings regarding character encoding. I tried adding some 'content="text/html;charset=UTF-8" ' strings into my HTTP header and to the <head> tags under <meta> tags, got some more warnings about generated frames that do not have character encoding, tried to add also these strings to <iframe> tag. Still the generated HTML is not displayed correctly. Also, this does not explains the difference between port 80 and other ports.

I'll be grateful for your thoughts\comments\ideas.

Best regards, Gidi

Alle svar (11)

more options

Did you check what content type the server sends?

You see the text instead of rendered HTML content if the server sends the content as text/html. If Firefox sees text/plain then Firefox will show the content as text. You can check that in "Tools > Page Info > General" and with the Live Http Headers extension.

On Windows it is always possible that security software is interfering and wants to protect you because of an uncommon port number and changes the content type in the HTTP response headers.

more options

When you say "displayed as text" do you mean you see raw HTML source code, or that the CSS is not being applied? I'm assuming the latter.

I suggest reviewing the URLs Firefox is retrieving using the Network Monitor. Open the Web Console using Ctrl+Shift+k, the click the Network tab on the top bar of the console, then reload the page bypassing the cache using Ctrl+Shift+r. Firefox should list the URLs retrieved in attempting to load the page, along with status codes and file sizes, etc.

Anything strange about the CSS files?

If this is an HTTPS site, could you check the URLs for any that might not be loading off the same port (e.g., absolute URL to the host without a port number) in case that might be causing a "cross-site" security issue?

more options

Many thanks for your help, I checked "Page Info" for all three frames consisting the web page. All three of them show "text/html". I saw something interesting - the render mode was set to "Quirks mode". I did some reading about and added "!DOCTYPE" to my tags. The problem still exists - I see in two of the frames HTML source code instead of the rendered HTML. Thanks again, Gidi

more options

I compare the data sent and received by the web-server, I found that the big difference is after an html page is sent to the browser with tag <link rel='stylesheet' type='text/css' href='style.css'>. When the port is 80, the next request from the browser is: received: GET /style.css HTTP/1.1 while in port 8000 it is: received: GET / HTTP/1.1

I tried setting instead of href='style.css' => href='./style.css' but it did not help.

more options

gidigal said

When the port is 80, the next request from the browser is:
received: GET /style.css HTTP/1.1
while in port 8000 it is:
received: GET / HTTP/1.1

That's strange. Firefox definitely should not be confused about a relative URL to a file in the same folder.

Apologies for directing you to a second tool, but could you also try the browser console, where error messages may appear? You can launch that using Ctrl+Shift+j (or the Developer menu), then click Clear at the top to remove existing content. Leave this window open, reload your frameset, then check back in the console to see whether there is any indication of an error parsing the page or a security issue.

more options

I checked browser console, the following error message is displayed twice:

The character encoding of a framed document was not declared. The document may appear different if viewed without the document framing it.

It is displayed for the two frames that show their HTML source code instead of being rendered. Both of these frames contain "<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">" in their source code.

more options

If you right-click the unstyled page and View Page Info, I suspect it will say

Text-Encoding: Windows-1252

or similar.

If you open the CSS file in a tab and check its Text Encoding the same way, what does that one say?

My guess would be the same, but is there a severe mismatch (such as UTF-16LE)?

more options

For main page: Type: text/html Render Mode: Standards compliance mode Encoding: UTF-8

For CSS page: Type: text/css Render Mode: Quirks mode Encoding: windows-1252

more options

I don't think there is a character set incompatibility between UTF-8 and windows-1252; that combination is very common.

I think the problem is related to your earlier note that the wrong URL is requested for the style sheet, and I don't have an explanation for that.

more options

You are sure that there aren't any extended (0x80-0xff) characters in the CSS file, possibly in a comment?

more options

I compared again the GET requests the browser sends to the web server: the first one is "GET / HTTP/1.1", the only difference between port 80 scenario and port 8000 scenario is "Host: localhost" vs "Host: localhost:8000" in the HTTP header. The second request is "GET /style.css HTTP/1.1" (this is a previous request to the request I mentioned before where there's a big difference between port 80 and port 8000). Here, apart from the understood differences of "Host: localhost" vs "Host: localhost:8000" and "Referer: http://localhost/" vs "Referer: http://localhost:8000/" there's a single line existing in port 80 scenario and not in port 8000 scenario. This line contains "live" string and it comes after "Connection: keep-alive" line that exists in both scenarios.

Ændret af gidigal den