Поиск в Поддержке

Избегайте мошенников, выдающих себя за службу поддержки. Мы никогда не попросим вас позвонить, отправить текстовое сообщение или поделиться личной информацией. Сообщайте о подозрительной активности, используя функцию «Пожаловаться».

Learn More

Firefox forces https in address bar

  • 7 ответов
  • 1 имеет эту проблему
  • 641 просмотр
  • Последний ответ от Godyay

more options

FF keeps replacing

http://mysite.domain.net:3344 with httpS://mysite.domain.net:3344

whatever I try to fix this behavior. Thing is that I own this server and there ever was't any SSL implemented. I mean this - never.

Other browsers (Chromium, Chrome, Opera) don't take such a forcing action, website opens like a charm. Why FF thinks it knows better which URL I really want to open?

I already googled _a lot_ in order to find solution, but no one worked.

Setup: Debian 11 Mate no proxy and no separate "internet security" stuff on laptop (other browsers with default settings confirm that) FF 102.11.0 ESR 64 no addons (all switched off)

already tried: browser.urlbar.autoFill false browser.cache.check_doc_frequency 1 network.stricttransportsecurity.preloadlist false browser.fixup.fallback-to-https false dom.security.https_first false

What else I could do to stop this madness? Thank you in advance for any help

FF keeps replacing http://mysite.domain.net:3344 with httpS://mysite.domain.net:3344 whatever I try to fix this behavior. Thing is that I own this server and there ever was't any SSL implemented. I mean this - never. Other browsers (Chromium, Chrome, Opera) don't take such a forcing action, website opens like a charm. Why FF thinks it knows better which URL I really want to open? I already googled _a lot_ in order to find solution, but no one worked. Setup: Debian 11 Mate no proxy and no separate "internet security" stuff on laptop (other browsers with default settings confirm that) FF 102.11.0 ESR 64 no addons (all switched off) already tried: browser.urlbar.autoFill false browser.cache.check_doc_frequency 1 network.stricttransportsecurity.preloadlist false browser.fixup.fallback-to-https false dom.security.https_first false What else I could do to stop this madness? Thank you in advance for any help

Выбранное решение

Clearing cookies in padlock menu helped, finally - dunno why.

Anyway, it seems wrong that FF ignores HO settings in such a way, probably this should be addressed... I was really very close to the point of no return thinking of getting back to Chromium.

Thank you for being kind and helpful, @cor-el!

Прочитайте этот ответ в контексте 👍 0

Все ответы (7)

more options

Did you try to create an HTTPS-Only Mode 'off' exception ?

more options

HTTPS-Only Mode is disabled, off cause (tried both - private only and total off), so it's impossible to add any exception - it's already off for all.

more options

Best in such a case is enabling HTTPS-Only mode as that gives you the option to bypass a forced HTTPS. With HO mode disabled there is nothing you can do to make Firefox use HTTP in case Firefox insists in using HTTPS. In some cases where the top level domain is on the HSTS preload list there is also not much that you can do.

more options

I'm in doubt that *.no-ip.org free DDNS is there, but I gave a try (I see no resorts left to the moment) - 1) HO switched on 2) added exceptions (both http* and https*) 3) restarted FF (just in case)

= no changes. FF keeps replacing http with https and throws the same error: "SSL_ERROR_RX_RECORD_TOO_LONG"

There is no SSL at all, other browsers confirm that clearly opening site like a charm with proper http:// prefix.

Is it bug then?

Изменено Godyay

more options

I'm in doubt that *.no-ip.org free DDNS is there in HSTS lists but I gave a try:

1) HO enabled 2) both http* and https* exceptions added 3) FF restatrted (just in case) = no changes: FF keeps replacong http with https throwing the same error "SSL_ERROR_RX_RECORD_TOO_LONG"

There is _not_ any SSL at all, other browsers confirm that clearly openening site like a charm with proper http:// prefix (which they don't replace voluntarily).

Is that a bug then?

more options

Did you try to create the exception via the slider in the padlock icon drop-down as I'm not sure how exception work with port numbers ? Did you include the port number ? Note that you need to specify the http:// protocol.

more options

Выбранное решение

Clearing cookies in padlock menu helped, finally - dunno why.

Anyway, it seems wrong that FF ignores HO settings in such a way, probably this should be addressed... I was really very close to the point of no return thinking of getting back to Chromium.

Thank you for being kind and helpful, @cor-el!