rsnext/errors/gssp-no-mutating-res.mdx

---
title: 'Must not access ServerResponse after `getServerSideProps` resolves'
---

## Why This Error Occurred

`getServerSideProps()` surfaces a `ServerResponse` object through the `res` property of its `context` arg. This object is not intended to be accessed or changed after `getServerSideProps()` resolves.

This is because the framework tries to optimize when items like headers or status codes are flushed to the browser. If they are changed after `getServerSideProps()` completes, we can't guarantee that the changes will work.

For this reason, accessing the object after this time is disallowed.

## Possible Ways to Fix It

You can fix this error by moving any access of the `res` object into `getServerSideProps()` itself or any functions that run before `getServerSideProps()` returns.

If you’re using a custom server and running into this problem due to session middleware like `next-session` or `express-session`, try installing the middleware in the server instead of `getServerSideProps()`.

## Useful Links

- [Data Fetching Docs](/docs/pages/building-your-application/data-fetching)
-												docs: Migrate error messages to MDX and App Router. (#52038)

This PR is part of a larger effort to migrate error messages to MDX and
use App Router: https://github.com/vercel/front/pull/23459
											
										
										
											2023-07-05 15:11:16 +02:00
+								---
 								title: 'Must not access ServerResponse after `getServerSideProps` resolves'
 								---
-												Throw error if res is accessed after gSSP returns (#29010)

* Throw error if res is accessed after gSSP returns

Currently it's possible to access the `ServerResponse` through `context.res`
in `getServerSideProps()`. If one was to store that response and mutate
its headers or status code after gSSP returns (e.g. during rendering), it
would currently happen to work because of when headers are sent. However,
this is an anti-pattern that relies an implementation detail of the framework
and shouldn't be allowed. This will be particularly important once Next.js
starts to support basic streaming (two-part flush: routing then data) because
then the headers will be sent as soon as gSSP returns, which explicitly breaks
this pattern.

With this commit, the framework now throws an error in development mode if
the ServerResponse is accessed after gSSP returns.

* fixup! Throw error if res is accessed after gSSP returns
											
										
										
											2021-09-14 00:10:46 +02:00
-												docs: Migrate error messages to MDX and App Router. (#52038)

This PR is part of a larger effort to migrate error messages to MDX and
use App Router: https://github.com/vercel/front/pull/23459
											
										
										
											2023-07-05 15:11:16 +02:00
+								## Why This Error Occurred
-												Throw error if res is accessed after gSSP returns (#29010)

* Throw error if res is accessed after gSSP returns

Currently it's possible to access the `ServerResponse` through `context.res`
in `getServerSideProps()`. If one was to store that response and mutate
its headers or status code after gSSP returns (e.g. during rendering), it
would currently happen to work because of when headers are sent. However,
this is an anti-pattern that relies an implementation detail of the framework
and shouldn't be allowed. This will be particularly important once Next.js
starts to support basic streaming (two-part flush: routing then data) because
then the headers will be sent as soon as gSSP returns, which explicitly breaks
this pattern.

With this commit, the framework now throws an error in development mode if
the ServerResponse is accessed after gSSP returns.

* fixup! Throw error if res is accessed after gSSP returns
											
										
										
											2021-09-14 00:10:46 +02:00
-												Ensure manifests check has correct exit code on fail (#29183)


											
										
										
											2021-09-17 18:30:54 +02:00
+								`getServerSideProps()` surfaces a `ServerResponse` object through the `res` property of its `context` arg. This object is not intended to be accessed or changed after `getServerSideProps()` resolves.
-												Throw error if res is accessed after gSSP returns (#29010)

* Throw error if res is accessed after gSSP returns

Currently it's possible to access the `ServerResponse` through `context.res`
in `getServerSideProps()`. If one was to store that response and mutate
its headers or status code after gSSP returns (e.g. during rendering), it
would currently happen to work because of when headers are sent. However,
this is an anti-pattern that relies an implementation detail of the framework
and shouldn't be allowed. This will be particularly important once Next.js
starts to support basic streaming (two-part flush: routing then data) because
then the headers will be sent as soon as gSSP returns, which explicitly breaks
this pattern.

With this commit, the framework now throws an error in development mode if
the ServerResponse is accessed after gSSP returns.

* fixup! Throw error if res is accessed after gSSP returns
											
										
										
											2021-09-14 00:10:46 +02:00
 								This is because the framework tries to optimize when items like headers or status codes are flushed to the browser. If they are changed after `getServerSideProps()` completes, we can't guarantee that the changes will work.
 								For this reason, accessing the object after this time is disallowed.
-												docs: Migrate error messages to MDX and App Router. (#52038)

This PR is part of a larger effort to migrate error messages to MDX and
use App Router: https://github.com/vercel/front/pull/23459
											
										
										
											2023-07-05 15:11:16 +02:00
+								## Possible Ways to Fix It
-												Throw error if res is accessed after gSSP returns (#29010)

* Throw error if res is accessed after gSSP returns

Currently it's possible to access the `ServerResponse` through `context.res`
in `getServerSideProps()`. If one was to store that response and mutate
its headers or status code after gSSP returns (e.g. during rendering), it
would currently happen to work because of when headers are sent. However,
this is an anti-pattern that relies an implementation detail of the framework
and shouldn't be allowed. This will be particularly important once Next.js
starts to support basic streaming (two-part flush: routing then data) because
then the headers will be sent as soon as gSSP returns, which explicitly breaks
this pattern.

With this commit, the framework now throws an error in development mode if
the ServerResponse is accessed after gSSP returns.

* fixup! Throw error if res is accessed after gSSP returns
											
										
										
											2021-09-14 00:10:46 +02:00
 								You can fix this error by moving any access of the `res` object into `getServerSideProps()` itself or any functions that run before `getServerSideProps()` returns.
-												Warn when mutating res if not streaming (#30284)

In #29010, we started throwing an error if the res was mutated after
getServerSideProps() returned. This was to support classic streaming,
where it would be possible to accidentally mutate the response headers
after they were already sent. However, this change also caught [a few
non-streaming cases](https://github.com/vercel/next.js/pull/29010#issuecomment-943482743) that we don't want to break.

As such, with this change, we only throw the error if res is mutated
after gSSP returns *and* you've opted into using classic streaming.
Otherwise, we will only add a warning to the console.
											
										
										
											2021-10-26 03:18:03 +02:00
+								If you’re using a custom server and running into this problem due to session middleware like `next-session` or `express-session`, try installing the middleware in the server instead of `getServerSideProps()`.
-												docs: Migrate error messages to MDX and App Router. (#52038)

This PR is part of a larger effort to migrate error messages to MDX and
use App Router: https://github.com/vercel/front/pull/23459
											
										
										
											2023-07-05 15:11:16 +02:00
+								## Useful Links
-												Throw error if res is accessed after gSSP returns (#29010)

* Throw error if res is accessed after gSSP returns

Currently it's possible to access the `ServerResponse` through `context.res`
in `getServerSideProps()`. If one was to store that response and mutate
its headers or status code after gSSP returns (e.g. during rendering), it
would currently happen to work because of when headers are sent. However,
this is an anti-pattern that relies an implementation detail of the framework
and shouldn't be allowed. This will be particularly important once Next.js
starts to support basic streaming (two-part flush: routing then data) because
then the headers will be sent as soon as gSSP returns, which explicitly breaks
this pattern.

With this commit, the framework now throws an error in development mode if
the ServerResponse is accessed after gSSP returns.

* fixup! Throw error if res is accessed after gSSP returns
											
										
										
											2021-09-14 00:10:46 +02:00
-												docs: Migrate error messages to MDX and App Router. (#52038)

This PR is part of a larger effort to migrate error messages to MDX and
use App Router: https://github.com/vercel/front/pull/23459
											
										
										
											2023-07-05 15:11:16 +02:00
+								- [Data Fetching Docs](/docs/pages/building-your-application/data-fetching)