Looking at a single HTTP response with status code 302 can not be used to make any assumptions about previous communication with the site, including no assumptions about the existence or the content of previous HTTP responses from the site. It is even possible that the same requests sometimes serves content and other times results in a 302 redirect.
As for returning script within the same response as the 302: The status code by itself might not be sufficient information for this. I think one can rely on common browsers not executing the body of the response if they actually do a redirect. But a server can send a HTTP response with code 302 which does not cause a redirect, for example by omitting the Location header.
For example Google Chrome will happily execute code in a HTML response served with status code 302 and a missing Location header. By combining this with a script based redirect one can make it look like a redirect was caused by status code 302, but still execute code before the redirect:
HTTP/1.1 302 ok
Content-type: text/html
<script>
alert("foo"); // some malicious code here
location.href="http://example.com"; // redirect
</script>