In Cypress 16, where does the application's traffic actually go in Chrome versus Firefox?

## Where the bytes actually go Cypress runs your spec inside the browser, but until version 16 it also sat **in the middle of every network exchange**. The browser was pointed at a Cypress-managed HTTP proxy, Cypress opened its own connection to your server, read the response, and handed a copy to the browser. That is the **legacy network path**, and because Cypress spoke HTTP/1.1 upstream, every request your bank-statement app made was downgraded to HTTP/1.1 no matter what your server supported. As of **Cypress 16**, Chrome, Chromium and Edge use the **native browser network** instead. The browser opens the connection to `/api/statements` itself and negotiates HTTP/1.1, HTTP/2 or HTTP/3 exactly as it does for a real customer. Cypress pauses each request and response *inside* the browser (implemented over the Chrome DevTools Protocol's `Fetch` domain) rather than being the connection. ## Which browser takes which path | Browser | `forceHttp1: false` (default) | `forceHttp1: true` | | --- | --- | --- | | Chrome, Chromium, Edge | Native browser network | Legacy network path | | Firefox, WebKit | Legacy network path | Legacy network path | | Electron | Legacy network path | Legacy network path | Firefox and WebKit have no native path implemented yet. Electron is Chromium-based and could take it, but it is deprecated as a test browser, so it was not carried over. **A cross-browser run therefore sees both behaviours inside a single suite**, which is the detail most people miss. ## What the change buys a suite - **Your production protocol is the one under test.** HTTP/2 and HTTP/3 are no longer downgraded, so a statement list that fires forty thumbnail requests multiplexes over one connection instead of queueing behind the browser's six-connections-per-origin ceiling. - **Your certificate is the one the browser validates.** Cypress no longer terminates TLS for the app under test. On the legacy path it acts as its own certificate authority and mints a certificate for your origin, which Chrome reports as issued by an unknown authority. - **What you stub is what the browser sees.** Modified request headers and bodies, stubbed responses and overridden status codes all appear in the browser's own network panel, because the browser is the one making the request. - **The "not secure" badge still appears**, and it is not about your app: the Cypress app itself is served over `http` on `localhost`, and the indicator describes that shell. ## What did *not* change `cy.intercept()` has the same API on both paths, and adopting the native browser network needs no configuration change at all. Cookie handling, `blockHosts`, obstructive-code rewriting and intercept matching run through the same request middleware on **both** transports, so a rule that blocks a telemetry host behaves identically in Chrome and in Firefox. What differs is a short list of **transport metadata Cypress can no longer observe**, because it is no longer the thing making the connection: 1. `req.httpVersion` is `undefined` and `res.httpVersion` is `null` in Chrome, Chromium and Edge; the legacy path still reports `'1.1'`. 2. `content-encoding`, `content-length` and `transfer-encoding` are absent from an intercepted response's headers — the body you get has already been decoded. 3. A revalidated resource reports `200` rather than the `304` your server actually sent, because the browser's cache merges the conditional response before Cypress sees it. 4. A response the browser's own network stack rejects never reaches Cypress at all; the request is still recorded, but `interception.response` is `undefined`. 5. Anything Cypress answers without a network exchange — a stubbed body, an `http` document loaded by `cy.visit()` — is not stored in the browser's HTTP cache, so a second navigation issues the request again. ## The escape hatch, and why it is already deprecated `forceHttp1: true` routes **every** browser back onto the legacy path, reproducing the pre-16 behaviour everywhere. It is worth knowing three things about it: - It was **introduced and deprecated in the same release**. It exists to buy a suite migration time or to work around a bug you have filed, and it will be removed. - Changing it **restarts the Cypress server**, and it cannot be set per test or per suite. - Setting it purely to avoid updating a handful of assertions is the wrong trade: it puts Chrome back on a transport your users never use, which is the gap the change closed. If a suite only passes with `forceHttp1: true` and the difference is not one of the documented behaviours above, that is a bug worth reporting rather than a setting worth keeping.