pierrejeambrun opened a new pull request, #67320: URL: https://github.com/apache/airflow/pull/67320
## Summary `breeze start-airflow` launches `airflow api-server` with no `--host` override, so it picks up the default `[api] host = 0.0.0.0` — **IPv4 only**. On macOS with OrbStack (and any other dual-stack-forwarding runtime), this breaks `http://localhost:28080` in Chrome and Safari but not Firefox — a confusing failure mode hidden behind an opaque `chrome-error://chromewebdata/...` page. This change makes the breeze-spawned api-server bind `::` (the IPv6 wildcard), which on Linux/macOS dual-stack sockets accepts both IPv4 and IPv6 connections. One-line behavior fix; no public Airflow config changes. ## Why this happens - macOS `/etc/hosts` resolves `localhost` to both `127.0.0.1` (A) and `::1` (AAAA). - **Chrome / Safari** prefer the IPv6 address — they try `[::1]:28080` first. - **OrbStack** binds the host-side port-forward dual-stack: `OrbStack ... TCP *:28080 (LISTEN)` on both IPv4 and IPv6. The IPv6 TCP handshake therefore succeeds at the host… - …but the api-server inside the container is bound to `0.0.0.0` only, so there's no listener on `[::]:8080`. The container responds with TCP RST. - The browser then renders `chrome-error://chromewebdata/` and emits the misleading *"Unsafe attempt to load URL ... from frame with URL chrome-error://chromewebdata/"* console message. - **Firefox** prefers IPv4, so it hits `127.0.0.1:28080` and never sees this. **Docker Desktop** historically only forwards IPv4, so happy-eyeballs falls back cleanly to IPv4 there too. The combo of Chrome + macOS + OrbStack is what surfaces it. ## Reproduce (before this patch) ```bash breeze start-airflow curl -v http://localhost:28080/ # → Recv failure: Connection reset by peer curl -v http://127.0.0.1:28080/ # → 200 OK # open http://localhost:28080/ in Chrome → chrome-error page # open http://localhost:28080/ in Firefox → works ``` ## After this patch The api-server binds dual-stack inside the container, so `localhost` reaches it regardless of which family the browser picks. ## Test plan - [ ] `breeze stop && breeze start-airflow`, then `curl -v http://localhost:28080/` and `curl -v http://127.0.0.1:28080/` both return 200 (302 to `/auth/login` actually). - [ ] Open `http://localhost:28080/` in Chrome → loads normally. - [ ] Existing IPv4-only setups (Linux + Docker) still work: `airflow api-server --host '::'` accepts IPv4 connections via dual-stack sockets. - [ ] `BREEZE_DEBUG_APISERVER=true` codepath still works (debugpy + `airflow api-server --host '::' -d`). --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 4.7) Generated-by: Claude Code (Opus 4.7) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
