Firefox Community Forum

NOTE: I have marked this as "Solved" because I figured out the problem described below, and I fixed it. See my following message here for a description of my solution.

Original message starts here ...

I'm using Firefox 144.0 under Debian Linux. I've used Firefox on this machine for years with no problem. Firefox can easily connect to literally thousands of web servers on the internet, both via HTTP and HTTPS.

But now, I'm having an issue:

I started running a web server on the same machine that Firefox is running on. This server only listens for non-HTTPS connections on port 80. I am not using any proxy server with Firefox.

I can easily and directly connect to my local web server's pages from my local machine from Chrome, w3m, curl, and direct telnet connections to port 80 ... all of which are addressing the publicly accessible domain name for my local web server. However, However, Firefox refuses to connect to any URL's on my local machine, and it gives me the following explanation:

Unable to connect

Firefox can’t establish a connection to the server at [ my server's domain name ].

   The site could be temporarily unavailable or too busy. Try again in a few moments.
   If you are unable to load any pages, check your computer’s network connection.
   If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.

In Firefox, I have all auto-forcing of HTTPS disabled by means of Don’t enable HTTPS-Only Mode turned on.

I get the same error in Firefox whether I connect via a URL like "http://MYFULLDOMAINNAME" or a URL like "http://AAA.BBB.CCC.DDD", where "AAA.BBB.CCC.DDD" is my machine's publicly accessible static IP address and "MYFULLDOMAINNAME" is the long-standing, publicly accessible domain name for my machine ... both with and without a suffix of ":80" on the supplied URL.

And again, all other browsers on my machine have no problem whatsoever connecting to my own local web server on this same local machine of mine using those same URL's.

And all browsers (Firefox and otherwise) that are running on other machines all over the internet have no problem connecting to that same web server via the same URL's that I described above

Also, I have no firewall rules on my machine which would block access to my own machine's port 80.

What could be causing this error in Firefox, and what might I be able to do to fix it?

Thank you very much in advance.

UPDATE: Just a bit more information. Looking at the web logs, I see that Firefox's request never even reaches my local web server. In other words, Firefox itself is not even trying to make a TCPIP port 80 connection to my local web server in the first place

bold text When I try to go to my "FIREFOX" it answers me in French of course but here you don't accept to write me in French and so it's very difficult for me ... (could you help me for this of course ???) : "hmm this adress doesn' seem to be valid." Hum, cette adresse ne semble pas valide.

What must I do please ??? [edited from public] @orange.fr

The connection has timed out

The server at eofficepwd.kerala.gov.in is taking too long to respond.

   * itemThe site could be temporarily unavailable or too busy. Try again in a few moments.
   * If you are unable to load any pages, check your computer’s network connection.
   If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.

Hello everyone,

We are currently investigating an issue where browsers are sending HTTP requests with Connection: close in the header during integrated Windows authentication (NTLM authentication) via SAML Service Provider (SP), leading to premature termination of the TCP connection.

This behavior occurs in the middle of the authentication process, preventing the NTLM authentication from completing and subsequently prompting for re-authentication.

We have observed the following browser behaviors:

Chrome and Edge: These browsers function without issues, communicating with Connection: keep-alive. Safari (macOS): Older versions of macOS with Safari exhibit the Connection: close behavior, leading to authentication failure. Newer versions of macOS with Safari work correctly with Connection: keep-alive. Firefox (macOS): Even on the latest versions of macOS, Firefox continues to attach Connection: close, resulting in authentication failure. Upon reviewing logs, we've identified that various browsers attach the Connection: close header during the NTLMSSP_NEGOTIATE request in the NTLM authentication sequence. Although this happens in an environment with a load balancer, we have confirmed that the load balancer is not modifying the header; rather, the client (browser) is adding it.

We would appreciate your insights into the conditions under which Firefox attaches Connection: close to HTTP requests, especially considering the differences across macOS versions and other browsers, addressing the following points:

Are there any known conditions or past cases where Firefox outputs Connection: close in an NTLM authentication environment via SAML SP? Given that older Safari versions show similar behavior, we are also considering if there's a common factor depending on NTLM authentication and browser version. What are the general heuristics, logic, or triggers for a browser to decide to "close" a connection or to attach Connection: close? We are particularly interested in cases that occur mid-authentication process. Could specific configurations (e.g., the combination of SAML and NTLM authentication, or the presence of an intermediate proxy/load balancer) potentially influence Firefox's Connection: close behavior? Are there any additional logs or debugging information we should collect from the Firefox client side to further pinpoint this issue? Any guidance or suggestions you could provide to help us resolve this problem would be greatly appreciated.

Thank you.

For so, me reason i have lost my connection to FireFox. It was in the last week. I was surprised because i have been using it for a few years. Can you help me to be able to use it again please?

BARRY HATHAWAY 14 SPINNERS COTTAGES LONGFORDS MILL MINCHINHAMPTON STROUD, GLOUCESTERSHIRE GL69LP. UK