[p1mrx]

Chrome redirects to https://example.com, so that's no bueno for testing http:// in your URL bar.

Edit: I'm running Chrome OS 113 beta. Maybe they changed something recently, to automatically use HTTPS unless prohibited by the server? This also happens in Guest mode with no extensions.

[dadrian]

In (50%) of Beta, Chrome attempts HTTPS and silently falls back to HTTP on all HTTP links. We're still poking around with opt-outs, currently if you allow insecure content via Page Info / Site Controls, we stop upgrades.

[mh-]

If you're open to feedback: I'm not strictly opposed to that behavior, but it seems like a reasonable compromise to not do that for URLs explicitly entered in the Omnibox. It seems like that will provide the transport upgrade effect we want, without breaking some of the workflows mentioned in this thread.

[pabs3]

There are tons of sites where http and https are different content; for example the https might be an admin interface, or the IP could have multiple domains but only a couple of them support https, or the vhosts could be very misconfigured. The HSTS and other browser things that force https often do not allow any way to get around this. I often have to resort to creating a new browser profile from scratch and trying hard to avoid https when loading the page. So please allow some way to deal with this sort of issue, for technical folks at least.

Edit: if you search for "forget HSTS", you will see how hard it is to avoid this on some browsers.

[noduerme]

In chrome on Android it seems basically impossible.

[noduerme]

Somewhere in the past six months, on a page where we have to force users to HTTP, Chrome on Android has broken about 90% of the time with "too many redirects" and no way to even type "http://" into the URL bar without Chrome changing it. Finally had to just give users a raw IP address. I would love if your team could fix this or provide some opt-out.

For context, each of the retail locations of our company runs its own local MAMP server that serves a web app used all day by the employees on their tablets. It's accessible only on the LAN. Rather than have every employee need to know or type the local IP address for these (which change sometimes), we serve a centralized web page at http://ourcompany.com/employeeApp that just keeps a live list of the local (192.x.x.x) IP addresses harvested from each server in each location, and opens a connection to the local server in an iFrame. Because of what's now a hard ban on loading insecure HTTP content within an HTTPS page, we must serve that central iFrame wrapper page over HTTP. Unfortunately, we now need to give Chrome users a raw IP address for ourcompany.com, to avoid them being redirected infinitely to HTTPS and back.

[edit] I should add that the oddest thing is that it doesn't always overflow with redirects, and on a new device it often is able to go to the HTTP site. But once someone does type https:// or leave out the http:// by mistake, no level of cache clearing seems to remove Chrome's insistence on trying to force HTTPS on that page forever afterwards.

[edit2] The rationale for not setting up local DNS and SSL is that these servers are on all kinds of different local networks in stores around the country, are switched on and off by non-technical managers onsite, and I'm the author of the web app and the only tech support for it. It needs to be as simple as possible so that I'm not spending all my time tunneling into those servers, walking them through router problems and stuff like that.

[derefr]

Why not use Talescale / ZeroTier / etc to get those local boxes connected together into a single virtual overlay network with that gateway (which, from the client site's perspective, is basically just "install app, paste pairing token", and is zero maintenance from then on); and then make your web iframe "gateway" discover these devices that are now on its network, and act as an actual request-proxying gateway for them?

This is similar (though simpler!) to how e.g. Plex's "watch from anywhere" cloud integration works. Your local plex-server install starts a (plaintext HTTP, Bearer-auth) HTTP server on some uPnP port on your local network; derives a public URL for that server via TURN/STUN; connects to Plex's cloud service, and registers that URL to your Plex account. Then, when you visit https://app.plex.tv/ from any device, the plex webapp talks to the backend of their cloud service; and that cloud backend takes your HTTPS request payload, and makes equivalent plaintext-HTTP requests to the registered Plex server on your local network.

[noduerme]

TBH, this system has been in production since 2016, and the stores essentially can't operate with any downtime... I dispatch updates that are auto-downloaded, and when one of them misfires and I have to spend an hour on remote access, that store's business comes to a halt causing a huge disruption as they transition to paper notes and whiteboards. (The software lets employees track and take ownership of the checkin/checkout and movement of dogs around 30k sqft petcare facilities, each with hundreds of dogs per day... so just the amount of barking when I'm on the phone with these places makes it hilariously difficult to guide people through tech support).

I looked a little bit at Tailscale but assumed it would be too complex for the store employees to manage and would require a lot of hands-on maintenance, and a store-by-store hand holding process which requires scheduling each of them weeks in advance. As it is, the system is secure (local wifi only accessible to employees) and runs even if the store's internet connection goes fully offline... so... I think I'll take your tip and look at it again... the plex model is essentially what I was going for... but I'd be reticent to add any other layers of complexity or anything that could cause downtime.

[iudqnolq]

Can you change to employeeApp.ourcompany.com?

Then you can support both http & https on ourcompany.com but only http on employeeApp.ourcompany.com.

That should at least be simpler than changing to a raw ip.

Another option might be redirecting to the local ip rather than framing.

[noduerme]

Interesting. You mean Chrome wouldn't do this if there was no ssl on the whole subdomain? Might be worth trying.

Redirecting isn't really a great option because the wrapper app is usually saved as a shortcut to the tablet homescreens to run in full screen mode... saving the redirected url would break more frequently. Also the wrapper iframe polls lots of known local addresses and sees which one loads.

[iudqnolq]

A quick skim of what I think is the relevant file[1] in the chrome source suggests that would work. So worth a shot. If you can deploy enterprise chrome settings to the tablets that's also apparently an option.

Here's what I'm assuming is the relevant bugtracker entry for the implementation [2].

[1]: https://chromium.googlesource.com/chromium/src/+/19719792bbd...

[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=139491...