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

Aperta
  • Qualcosa non va?
#8,832 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, java
Ambito
authentication, mobile-dev, networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Java
Stelle
2.6k
Fork
733
Merge medio
2g 15h
PR unite (30g)
72

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di firebase/firebase-android-sdk

Tutte le issue di firebase/firebase-android-sdk

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.