Indeed. This should really be the responsibility of the Wifi stack, which imposes the restriction and sits on a lower level than the HTTP stack. My gopher connections never work when I am behind a captive portal!

There is the standard 8952. But it nowhere implemented yet. it uses https, dhcp and ra to give the client the captive portal information.

It is though. I've implemented a captive portal that uses this successfully for sending modern mobile OS like Android and iOs through captive portal. Marcos works fine too, also newer windows.

Many of those networks block most ports except http, https basically.

The WISPr[0] standard was created for this purpose, and is (or was by now?) used by companies such as iPass to their customers to transparently log in to most WiFi hotspots. I don't think that standard is accessibly anywhere these days. I made a Python implementation [1] that should still work.

[0] https://en.wikipedia.org/wiki/WISPr [1] https://github.com/wichert/wispr

There is a dhcp option that can be used as an alternative that was recently (~2yr ago) introduced but it’s not supported by any major OSes except android

There is rfc 8952, but its not official yet. Including the others which are referenced. The dhcp option is also not official yet.

It took some time to adopt, but works at least on recent mobile OS and MacOS.