Auth: sign-in takes ~80 s on dual-stack networks with broken IPv6 (addresses tried one by one, 10 s each), and requests fail under HttpEngine/Cronet because of a null header value

The payload names no source files, so start by locating where the SDK sets the X-Firebase-Locale request property and where its HttpURLConnection connect and read timeouts are configured. Confirm that a null language code reaches setRequestProperty on the signInWithPassword path. Done means the null-valued header is skipped and the auth requests succeed with a custom URLStreamHandlerFactory installed. The IPv6 fallback part needs a maintainer decision on the HTTP stack before any change.

Environment

• Firebase Android BoM 35.1.0, firebase-auth 25.0.0 (pulled in by FlutterFire firebase_auth 7.0.1 / firebase_core 5.1.0)
• Device: Samsung SM-A176B, Android 17 (API 37)
• Emulator for Problem 2 follow-up: API 36, google_apis image
• Network: home Wi-Fi where the router hands out a global IPv6 address and a default IPv6 route, but IPv6 traffic is dropped upstream. IPv4 works. Android reports the network as validated.

Problem 1: no fast fallback, sign-in blocks for about 80 seconds

On this network signInWithCredential (Google) took 81.16 s. The same call takes about 1 s once an IPv4 connection is already open.

What we measured during the 81 s, by sampling the app's sockets once per second:

• The app opened TCP connections to 8 different IPv6 addresses of the Identity Toolkit host (2001:4860:484x:400::, the 8 AAAA records), strictly one after another.
• Each attempt stayed in SYN_SENT for 10.0 s on average (range 9.77 to 10.17 s) before the next address was tried.
• 80.3 s after the first attempt, an IPv4 connection to port 443 was established and the sign-in completed right away.

This matches what is in the 25.0.0 AAR: requests go through java.net.HttpURLConnection with setConnectTimeout(10000) and setReadTimeout(60000). Android's HttpURLConnection tries the resolved addresses sequentially in resolver order and has no Happy Eyeballs behaviour, so with 8 AAAA records the caller waits 8 x 10 s before the first IPv4 address is tried.

For comparison, on the same phone and network:

• Requests made from Dart (dart:io) to our own dual-stack backend connect over IPv4 in about 0.2 s.
• curl and Chrome on the same Wi-Fi are not affected.

The email and password flow and the FCM token registration show the same kind of delay on this network (about 84 s and about 64 s in earlier runs; those two were timed end to end, without socket sampling).

From the user's side the app shows a spinner for over a minute on first sign-in. We cannot tell them the problem is their ISP, and we have no way to influence address selection from outside the SDK.

Expected: sign-in falls back to IPv4 within a second or two, as browsers and most HTTP stacks do (RFC 8305).

Request: use an HTTP stack with fast fallback for Auth requests, or at least avoid paying the full connect timeout per address (for example by interleaving address families or capping the total connect time).

Problem 2: Auth requests fail under HttpEngine/Cronet with "Invalid header value."

As a workaround we tried routing HttpURLConnection through the platform HTTP engine on API 34+:

val engine = HttpEngine.Builder(context).build()
URL.setURLStreamHandlerFactory(engine.createUrlStreamHandlerFactory())

The factory installs correctly (HttpEngine 147.0.7727.132 on the phone, 133.0.6876.3 on the emulator), but Auth stops working:

• Email and password sign-in fails within about 35 ms, before anything reaches the network:
  E/RecaptchaCallWrapper: Initial task failed for action RecaptchaAction(action=signInWithPassword) with exception - An internal error has occurred. [ Invalid header value. ]
• Google sign-in (signInWithCredential) never completes. For 150 s the task reported neither success nor failure and the app had no open socket. We did not trace why this path hangs instead of failing.

"Invalid header value." is the message Cronet throws from UrlRequest.Builder.addHeader when the value is null. Without the custom factory, the platform implementation logs this on the same requests and carries on:

Ignoring header X-Firebase-Locale because its value was null

So the SDK calls setRequestProperty("X-Firebase-Locale", null) when no language code is set. The default HttpURLConnection drops such a header; Cronet's HttpURLConnection keeps it and throws when the request starts.

We then called FirebaseAuth.useAppLanguage() before signing in (through FlutterFire's setLanguageCode(null)). On the API 36 emulator the same "Invalid header value." error still occurred on signInWithPassword. We could not determine which header was null in that run, because Cronet does not log the header name.

Expected: the SDK does not pass null header values to URLConnection, so that it also works when the app installs a different URLStreamHandlerFactory.

Request: skip headers whose value is null instead of calling setRequestProperty with null.

Steps to reproduce

Problem 1:

1. Use a network that advertises a global IPv6 prefix and default route but drops IPv6 traffic, with working IPv4.
2. Cold start an app that uses firebase-auth 25.0.0 and sign in.
3. Observe the time until the sign-in task completes, and the app's TCP sockets during the wait.

Problem 2:

1. On API 34 or later, install the HttpEngine factory shown above in Application.onCreate.
2. Call signInWithEmailAndPassword without having set a language code.
3. Observe the "Invalid header value." error in logcat. No request is sent.