Captive portal compatibility methodology

Test matrix

Change one variable and record the actual path.

Each field record should identify the device and venue class without retaining sensitive network identifiers.

• Safari, Chrome, Firefox, Edge, and Android Chrome.
• Typed bare domain, explicit HTTP link, QR, private mode, cached state, and HTTPS-first mode.
• VPN, proxy, Private Relay, automatic DNS, custom DNS, IPv4, IPv6, and dual stack.
• Operating-system prompt, NeverSSL, a second HTTP utility, and WiFi 4 Breakfast.

Outcome language

Record what happened without turning it into a guarantee.

A result can show that the venue portal appeared, that our server was reached, that the request failed, or that the evidence was unclear. It must not claim success merely because cellular data kept a phone online.

• Portal appeared and venue flow became available.
• Our fixed HTTP response was reached without interception.
• Request failed or timed out.
• Interface path was not verified.
• Operator action was required.

Publication gate

Publish compatibility only with scope and limitations.

Every public row needs a test date, environment, browser and OS version, result, limitation, and reproducible evidence reference. Redact SSID, BSSID, portal URLs, credentials, precise location, and personal identifiers.

Sources

First-party references.

1. RFC 8952: Captive Portal ArchitectureInternet Engineering Task Force
2. RFC 8908: Captive Portal APIInternet Engineering Task Force
3. How to modernize your captive networkApple Developer
4. Support captive portal APIsAndroid Developers
5. Network Connectivity Status Indicator overviewMicrosoft Learn
6. Captive portal detectionMozilla Support

Keep going

Related help.