3

I have a web server, built into a device, sitting behind a firewall. The web server is on port 80, but many times port 80 is already in use by some other device. i.e. DVR.

To access the server from the web, I use an alternative port, like 9300. Until recently this worked fine in Chrome, but as of around version 56 I get a "net::ERR_INVALID_HTTP_RESPONSE" when the page tries to load other resources, like java script or css files. I have read that Chrome is blocking standard ports < 1024, but I don't understand what that has to do with the port I'm using. The page loads, but not the resources. This acts more like across-origin problem. Everything still works, at the moment in Fire Fox.

Can anyone explain why Chrome isn't working and if there is a solution, other than just giving up on Chrome? Any help would be greatly appreciated. I have spent many hours trying to find a solution, but nothing I can find seems to fit this situation.

  • Is this something that we can get to and test too? It sounds like Chrome may not handle relative links with port numbers the same as Firefox or something. – Stephen Ostermiller Aug 1 '17 at 14:48
  • You can use link to see live. The link will work in Fire Fox, but not Chrome. – jwolf Aug 1 '17 at 14:58
  • Simple, update your Chrome. – Simon Hayter Aug 1 '17 at 14:59
  • 1
    Already on latest Version 60.0.3112.78 (Official Build) (64-bit) – jwolf Aug 1 '17 at 15:10
  • Well, your headers are not correctly using valid character encoding which could be causing your issue. – Simon Hayter Aug 1 '17 at 15:34
2

Chrome 55 was notorious for net::ERR_INVALID_HTTP_RESPONSE, when using custom ports outside of 80, 8080 and 443. This affected thousands of servers but notably Shoutcast Version 1 and 2.

A simple fix may just be to use 8080 instead of 9300 as it can coexist with 80. But your issue here is your browser, not your server or hardware. The real fix is to update your browser to a version that is considered stable and up to date.

Google released a build that fixed this very issue after many complaints. Considering that we are now in version 59 stable and 60 stable development, you should update your Chrome to resolve this issue, after all that's why we get new versions of browsers all the time to fix issues, sometimes new fixes break things etc.

Further findings...

Your server is not serving CSS or JS correctly, and possibly other server-side resources. This is actually reported in the Firefox console.

Doing a curl on a element or page should look something like this:

https://www.bybe.net/wp-content/themes/showboat/style.css

HTTP/1.1 200 OK
Date: Tue, 01 Aug 2017 15:36:05 GMT
Content-Type: text/css
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d01134b2133a3b0424baada976e2258ff1501601765; expires=Wed, 01-Aug-18 15:36:05 GMT; path=/; domain=.bybe.net; HttpOnly
Last-Modified: Fri, 07 Apr 2017 14:51:08 GMT
ETag: W/"28c5b-54c94c1738f00-gzip"
Vary: Accept-Encoding
CF-Cache-Status: HIT
Expires: Tue, 01 Aug 2017 19:36:05 GMT
Cache-Control: public, max-age=14400
Server: cloudflare-nginx
CF-RAY: 3879defb19795687-IAD

Doing a CURL on your resources returns this:

  1. NULL
  2. NULL

The code above is not valid and should not work at all. The reason that FireFox is working while Chrome is not is because Chrome is more strict when it comes to security concerns.

Doing a CURL on your pages returns:

HTTP/1.0 200 OKAY
Content-Type: text/html
Cache-Control: no-cache

To replicate this issue, you can do a online test yourself using online CURL. To add your username and password, click + Add Option, find user -u and click it, then Insert Attributes as YourUsername:YourPassword.

So, the solution to all your problems is to fix your web server serving all files and pages correctly.

  • I was on Version 59 and just updated to 60 today, this still doesn't fix the issue. I will try port 8080. – jwolf Aug 1 '17 at 15:12
  • Tried port 8080 and this didn't solve the issue. Still getting INVALID_HTTP_RESPONSE>. – jwolf Aug 1 '17 at 15:18
  • Unfortunately the server is built into the device, so I don't have access to the settings. Funny thing is, if I VPN into the site and use the local address in Chrome, everything works. I have been using this in Chrome since 2012 and it worked until a few months back. – jwolf Aug 1 '17 at 15:52
  • 1
    As a note, if I use port 80 on the WAN interface, Chrome WILL load the resources. – jwolf Aug 1 '17 at 15:55
  • Yes... but its stricter on other ports. It shouldn't really work at all in any browser. It looks like the device is designed by a company who has no idea on web standards and browsers. – Simon Hayter Aug 1 '17 at 15:57
2

I am seeing this on Chrome 63 where there is a bad proxy. To resolve:

  1. Open chrome://net-internals/#proxy
  2. Click Clear bad proxies

The chrome://net-internals/#events tab can be useful to view what is going on.

  • 1
    Thanks for posting. The problem seems to be, in my case, that Chrome sees a port redirection as cross domain. Firefox does not have this issue. If I directly use port 80 at the router upstream of the device hosting the web server Chrome will work. Unfortunately, I occasionally have multiple devices sitting behind a single router so I use PAT to redirect the request to the appropriate device. I wrote a Node server backend to make the requests from a server in my office and just do a GET request to that server to get the data I need. – jwolf Jan 25 '18 at 5:33
  • 1
    Absolutely this. In a complex app there's often no substitute for looking at the bytes the browser is actually getting on the socket. – rakslice Mar 26 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.