Repository navigation
Documentation about HTTP vs HTTPS connections is unclear #183153
Description
When controlling dart uri connections, the documentation is less than clear.
In the Android embedder, we definitely parse the network_security_config.xml file - but then it doesn't go anywhere as far as I can tell. It's passed all the way down into Dart::Io to initialize the isolate. But the parameter is no longer used: flutter/engine/34010
Even the engine's code describes how to set the policy per domain:
flutter/engine/src/flutter/shell/common/switch_defs.h
Lines 229 to 233 in 72e216e
| DEF_SWITCH(DomainNetworkPolicy, | |
| "domain-network-policy", | |
| "JSON encoded network policy per domain. This overrides the " | |
| "DisallowInsecureConnections switch. Embedder can specify whether " | |
| "to allow or disallow insecure connections at a domain level.") |
There has been lots of discussion about this and it appears that it settled on only allowing a boolean on/off for HTTP connections:
- Add API for blocking clear text HTTP connections dart-lang/sdk#53929
- Add documentation describing how to use the Flutter engine HTTP blocking mechanism. #95341
- Ban HTTP on iOS and Android platforms by default #54448
Currently, there is no way for the Android embedder to turn on/off insecure connections for dart uri connections and, if this comment is to be believed, insecure uri connections are on by default:
flutter/engine/src/flutter/shell/common/switch_defs.h
Lines 225 to 228 in 72e216e
| DEF_SWITCH(DisallowInsecureConnections, | |
| "disallow-insecure-connections", | |
| "By default, dart:io allows all socket connections. If this switch " | |
| "is set, all insecure connections are rejected.") |
The setting is on by default:
https://github.com/flutter/flutter/blob/6593592c450e5399a703353f42a6cc91b128b888/engine/src/flutter/shell/common/switches.cc#L269C1-L270C59
And the engine uses that setting.
We used to check if cleartext traffic was allowed and set the flag accordingly: flutter-team-archive/engine#20733
But that was removed: flutter-team-archive/engine#25299
So the Android and iOS embedders are not controlling if HTTP is allowed on a dart uri connection.
In the minimum, we should remove the dead code and update the documentation to indicate:
- Only native (Android) uri connections can be configured to disallow/allow HTTP cleartext traffic. Via the network_security_config.xml (preferred) or via the (soon to be deprecated) usesCleartextTraffic tag. So if this is a need, consider using cronet_http.
- Dart uri connections will be subjected to the following code where mayInsecurelyConnectToAllDomains is always true
To go above and beyond, we could use base-config from the network_security_config to indicate if --disallow-insecure-connections should be set to true/false. But we could not necessarily honor per domain settings without re-instantiating the per-domain network policy that was removed from hooks.dart.
Activity
mboetger commentedon Mar 3, 2026
I think this is causing confusion because there needs to be a distinction between Android and Dart uri connections.
#106678
#65841
mboetger commentedon Mar 3, 2026
I think I see the confusion.
The documentation was added to support the breaking changes in:
Since then, all of the functionality has been removed.
This breaking change documentation only re-iterates information about the Android, iOS networking policies and therefore only affects Android, iOS uri connections - not Dart/Flutter uri connections. This is stated on the page, but the page also makes it seem like there's a way around it.
Beyond that, no one - not Android, iOS, or Flutter, does this on the socket level. If you open a socket you are on your own.
Should we just remove the documentation?
[Espresso] remove metadata network policy (#11164)
[Many] Remove network policy from metadata (#11165)
Remove documentation about metadata (#13133)
mboetger commentedon Mar 11, 2026
Since the documentation has been updated, closing this.
github-actions commentedon Mar 25, 2026
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.