You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs/app/guides/native-network-interception.mdx (currently on the release/16.0.0 branch) lists eleven behavior differences under Behavior differences, but does not mention that redirect response bodies are empty on the native browser network path. Found while testing the Cypress 16 pre-release build against an HTTP/2 origin.
This is a deliberate platform limitation rather than a bug — CDP refuses Fetch.getResponseBody for a pause in the redirect-received state, and the Cypress source carries a comment saying exactly that — so there is nothing to fix in the product. It is only missing from the docs, which is why this is filed here and not in cypress-io/cypress.
Measured
A 302 whose origin also sent a body, observed in a cy.intercept response handler:
Path
res.statusCode
res.body
default (native browser network)
302
""
forceHttp1: true
302
"<html><body>redirect body from origin</body></html>"
res.statusCode and the response headers, location included, are present and correct on both paths. Only the body is lost.
Cypress 16.0.0 pre-release (16.0.0-3bcc0e1576ea6253d908bc1a9d328b34ad0aeaf1), Chrome 151, macOS, Node 24.15.0. Firefox matches the forceHttp1 column, as it stays on the legacy path.
Why it is worth an entry
The page already documents differences of the same shape and severity — httpVersion not being reported, content-length being absent, revalidated responses reporting 200 instead of 304. A test that asserts on the body of a redirect response passes in Cypress 15 and fails in 16 with an empty string and no explanation, which is precisely the situation the section exists to prevent. Searching the page for "redirect", "3xx", and "location" currently returns nothing.
Suggested section
Drafted to match the house style of the surrounding entries. Placing it next to Response headers do not report content-encoding would group it with the other response-shape entries.
Redirect response bodies are empty
res.body is an empty string for a 3xx response. The browser exposes a paused redirect
differently from a paused response and does not make its body available to Cypress, so there is
nothing for Cypress to hand your handler. The status code and the response headers, including location, are reported normally.
// Cypress 15 and earliercy.intercept('/api/old-path',(req)=>{req.on('response',(res)=>{expect(res.statusCode).to.equal(302)expect(res.body).to.contain('Moved')})})
// Cypress 16: assert on the status code and the location headercy.intercept('/api/old-path',(req)=>{req.on('response',(res)=>{expect(res.statusCode).to.equal(302)expect(res.headers.location).to.equal('/api/new-path')})})
One thing to confirm before publishing
The Cypress source suggests a handler can still replace the body of a redirect even though it cannot read it — the empty buffer is used as the origin-body digest, so a handler that writes a body onto a 3xx should take the fulfill path rather than being passed through. I did not verify that, so I have deliberately left it out of the draft above. If it holds, a sentence saying "you can set a body on a redirect, you just cannot read the one the origin sent" would make the entry complete. If it does not hold, the draft is correct as written.
Description
docs/app/guides/native-network-interception.mdx(currently on therelease/16.0.0branch) lists eleven behavior differences under Behavior differences, but does not mention that redirect response bodies are empty on the native browser network path. Found while testing the Cypress 16 pre-release build against an HTTP/2 origin.This is a deliberate platform limitation rather than a bug — CDP refuses
Fetch.getResponseBodyfor a pause in the redirect-received state, and the Cypress source carries a comment saying exactly that — so there is nothing to fix in the product. It is only missing from the docs, which is why this is filed here and not incypress-io/cypress.Measured
A 302 whose origin also sent a body, observed in a
cy.interceptresponse handler:res.statusCoderes.body""forceHttp1: true"<html><body>redirect body from origin</body></html>"res.statusCodeand the response headers,locationincluded, are present and correct on both paths. Only the body is lost.Cypress 16.0.0 pre-release (
16.0.0-3bcc0e1576ea6253d908bc1a9d328b34ad0aeaf1), Chrome 151, macOS, Node 24.15.0. Firefox matches theforceHttp1column, as it stays on the legacy path.Why it is worth an entry
The page already documents differences of the same shape and severity —
httpVersionnot being reported,content-lengthbeing absent, revalidated responses reporting200instead of304. A test that asserts on the body of a redirect response passes in Cypress 15 and fails in 16 with an empty string and no explanation, which is precisely the situation the section exists to prevent. Searching the page for "redirect", "3xx", and "location" currently returns nothing.Suggested section
Drafted to match the house style of the surrounding entries. Placing it next to Response headers do not report
content-encodingwould group it with the other response-shape entries.One thing to confirm before publishing
The Cypress source suggests a handler can still replace the body of a redirect even though it cannot read it — the empty buffer is used as the origin-body digest, so a handler that writes a body onto a
3xxshould take the fulfill path rather than being passed through. I did not verify that, so I have deliberately left it out of the draft above. If it holds, a sentence saying "you can set a body on a redirect, you just cannot read the one the origin sent" would make the entry complete. If it does not hold, the draft is correct as written.Related
cy.interceptfield differences from the same testing pass are filed as product issues, since each looks fixable rather than platform-imposed: Proxy Disabled: res.statusMessage is null in cy.intercept, but its published type is a non-optional string cypress#34656 (res.statusMessageisnull), Proxy Disabled: req.headers in cy.intercept omits headers the origin receives (accept-language, accept-encoding, sec-fetch-*) cypress#34657 (req.headersomitsaccept-language,accept-encoding,sec-fetch-*), Proxy Disabled: a binary req.body reaches cy.intercept as a lossy UTF-8 string cypress#34658 (a binaryreq.bodyarrives as a lossy UTF-8 string). If any of those is resolved as "keep the behavior" rather than fixed, it will need an entry on this page too —res.statusMessagemost likely, since HTTP/2 carries no reason phrase on the wire.