In the past, I could reliably see the response of a request, even if that request received a 301/302 in the response headers.
Somewhat recently, that has changed, and now the FF network tab shows the response body of the page after redirect. This is something that Chrome does, and the fact that FF always continued to show these granular, more accurate, details, is a reason I stick to FF.
This change isn’t particularly helpful, as the next request is usually the browser following the redirect, which shows the same response.
As someone who is often debugging redirects, this is a flaw, because it doesn’t show the true response body of the request with the redirect header.
Can we at least have a setting which allows us to turn back to the old, more accurate, behavior?
1 Like
Yes, this is a bug, not a feature and it is extremely confusing.
A server is permitted to include a response body with a 303, so the Firefox depiction of the request / response pair could be correct. Using Copy as cURL and curl is only way to determine the real response.
I have a PUT request using Accept HTML, for which Firefox shows a response with a large JSON payload! This response payload is the same size as the subsequent GET (following the redirect). This gives the impression there is twice the data transfer, and is a completely incorrect representation of the server behaviour.
As seen with curl, the actual response is HTML (as expected), with redirect information in the title and body (as recommended by the RFC).
Firefox is therefore unreliable and misleading for redirects. This is a disservice to anyone debugging, but especially to any new developers learning HTTP.
FWIW, Chrome is also broken, but at least somewhat less so. It indicates:
Failed to load response data
No content available because this request was redirected
1 Like