Closed Bug 1267072 Opened 9 years ago Closed 9 years ago

Failure to Recognize HTML Doc Format on Alternate TCP Port Assignments- Other Browser OK

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
45 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: tmall, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160309193552 Steps to reproduce: Atempt to load the following html document when located on TCP port 1459. Firefox displays this same document properly in html mode when when the device is assigned to port 80 and also when the same html source code text is loaded from a local file system html file. Both Chrome and Edge display the file properly in html document format when the device is assigned to port 1459. It appears that Firefox does not detect or rejects the html document mode only when the device is assigned to a TCP port other than 80 and instead displays on the html source code text. This happens with Firefox under Windows 10, Linux Mint and Android. Other browsers under aforementioned operating systems display OK with TCP port 1459 assignment. Actual results: Firefox just displays the html source text. Other html sites on ports other than 80 are displayed OK by Firefox, for example devices on ports 1456, 1457 and 1458 display as html documents OK. The page is displayed as html source code text instead of html page format. Firefox displays this document properly in html mode when port 80 is used and when loaded from an html file. Displays properly in html document mode with Chrome and Edge when assigned to port 1459. However other html sites on ports other than 80 are displayed OK in Firefox, for example different devices on ports 1456, 1457 and 1458 display as html documents OK. The html code that fails is this: <html><head><title></title></head><h1>Amateur Radio Station VA7TA:</h1><h1> ESP8266 Web Server</h1><p>Measurement Time: Sun, 24 Apr 2016 16:33:47 GMT </br> </p> Temperature = 24 degrees C</br>Relative Humidity = 22 %</font><p>Relay <a href="?pin=ON1"><button>ON</button></a>&nbsp;<a href="?pin=OFF1"><button>OFF</button></a></p><p>Buzzer <a href="?pin=ON2"><button>ON</button></a>&nbsp;<a href="?pin=OFF2"><button>OFF</button></a></p><p>Temperature/Humidity <a href="?pin=TEMPRH"><button>UpDate</button></a></p></html> Expected results: Should have displayed as an html document.
OS: Unspecified → All
Hardware: Unspecified → All
Component: Untriaged → Networking
Product: Firefox → Core
I'm going to assume this is http/0.9 - but you need to include a http log to confirm. https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging if 0.9, that's intentional as a security feature. Please reopen if this is not http/0.9. you can make this work by using the default port (80 or 443 if https) or using an http version 1.0 or greater.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
In any event there is inconsistency between browsers as both Chrome and Edge recognize the html file type. There is a need to use a non standard port for passing through the router which re-assigns the port to 80 on the LAN. I solved the problem for FireFox when using port 1459 by sending the following text without html <head></head> delimiting tags at the very beginning: HTTP/1.1 200 OK\n\n With this preamble text FireFox recognizes the file as http document type even when port# 1459 is used. Neither Chrome nor Edge require this preamble statement but still work OK with it. FireFox Inspector indicates the header is blank and the above preamble text is not shown by Inspector at all. The Inspector indicates blank header with: <html> <head></head> <body> If the ”HTTP/1.1 200 OK\n\n” statement is delimited with html <head></head> tags then FireFox fails to recognize the html format.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
it is 0.9 and is working as intended. Thanks for the datapoint, but its the tradeoff we intended.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.