Your Cypress 16 suite passes only with `forceHttp1: true`. Is that an acceptable place to stop?

## What the switch actually buys and costs `forceHttp1: true` is a project-level configuration option that routes every browser through the **legacy network path** — the pre-16 arrangement in which Cypress holds the connection between the browser and your server. Setting it restores the old `cy.intercept()` behaviour wholesale: `req.httpVersion` reports `'1.1'` again, compression headers reappear on intercepted responses, revalidations show `304`, and Cypress terminates TLS for the application under test. Changing it restarts the Cypress server, and it **cannot be set per test or per suite** — it is all-or-nothing for the project. The cost is that the suite goes back to testing something your users never do: - **The protocol is wrong.** Requests are downgraded to HTTP/1.1 and queue behind the per-origin connection ceiling, so a request-heavy dashboard behaves differently under test than in production, and HTTP/2 or HTTP/3 specific behaviour is unreachable. - **The certificate is wrong.** Cypress acts as its own certificate authority and issues a certificate for the origin under test, instead of the browser validating your real one. - **The network panel is wrong.** Request modifications are applied after the browser has logged the request, so what you changed is not what the browser records. ## Why "it is deprecated already" is the decisive fact Cypress **introduced and deprecated `forceHttp1` in the same release**. That is an unusually clear signal: the option exists to give suites time to migrate, or as a temporary escape hatch while an issue you filed is investigated, and it will be removed once the native browser network is supported long term. Setting it prints a warning on every run. Reading that correctly is the judgement being tested. An option that is deprecated at birth is not a supported configuration choice with a trade-off to weigh — it is **a countdown**. Any plan that treats it as a setting rather than as a scheduled piece of work is planning for a forced migration later, under whatever deadline the removal lands on. ## The decision I would defend 1. **Turn it on to unblock, not to finish.** A red suite blocking a release is a real cost; take the switch, and record the date you took it. 2. **Identify which difference you actually depend on.** The behaviour changes are documented and short: transport metadata, compression headers, request `content-length`, revalidations reported as `200`, stubbed responses never cached, responses the browser rejects, and `responseTimeout` no longer bounding a response handler. Find yours before you write a plan. 3. **File an issue if it is not on that list.** If the switch fixes something undocumented, that is a bug report, and filing it is what keeps the escape hatch honest for everyone. 4. **Fix the assertions, not the transport.** Most of the work is replacing transport assertions with application ones; the residue is a handful of assertions gated by `Cypress.isBrowser()` for the browsers still on the legacy path. 5. **Delete the option and keep the run green.** The exit criterion is the flag removed, not the suite passing with it on. | Position | Defensible when | Fails when | |---|---|---| | On, with a date and an owner | Migrating, or an issue is open | The date passes unremarked | | On, indefinitely | Never in a maintained suite | Removal lands on a deadline | | Off, with gated assertions | The differences are understood | Nobody owns the gates | ## What makes this an organisational call, not a technical one The technical fix is small and mostly mechanical. What is hard is the standard the team adopts: **whether a test suite is allowed to assert on transport at all.** Every assertion this migration breaks was an assertion about the plumbing rather than about the product, and a team that writes those will collect the same debt at the next runner change, the next proxy change, the next protocol change. The durable position is to say so out loud — tests assert on what the application did, transport assertions need a written reason — and to treat a compatibility switch as a tracked item with a name against it. The alternative, a flag nobody owns quietly diverging the test environment from production, is how a suite stops being evidence. ## What to remember - `forceHttp1` is a **migration aid deprecated at introduction**, project-wide, and it restarts the Cypress server when changed. - Leaving it on keeps testing HTTP/1.1, a Cypress-issued certificate, and a cache Cypress sits in front of. - The exit criterion is the flag removed, not the suite green with it on. - If the difference that forces it is undocumented, filing the issue is part of the job.