xak2000
commented
8 months ago I have a similar problem caused by this behavior.
I have a Nitro middleware that calls getServerSession(event). If an actual API handler also calls getServerSession(event), then useFetch() doesn't read data properly when it is called from SSR. It decodes the data as Blob instead of simple JS object, so the client can't render the data.
So, calling getServerSession(event) more than one time from anywhere (e.g. a handler, a middleware) causes this problem.
The problem is caused by modifying the response headers. Even calling getServerSession(event) just once still modifies the headers, so this can still cause the same problem if the response headers already have had a content-type header at the moment of the first call of getServerSession(event).
Examples:
With no calls to getServerSession(event):
Headers in the middleware (event.node.res.getHeaders()):
{}
Headers that useFetch() sees (context.response.headers):
HeadersList {
cookies: null,
[Symbol(headers map)]: Map(1) {
'content-type' => { name: 'content-type', value: 'application/json' }
},
[Symbol(headers map sorted)]: null
}
Data that useFetch() sees:
{ ...normal JS object... }It's OK.
With 1 call to getServerSession(event):
Headers in the middleware before calling getServerSession(event):
{}
Headers in the middleware after calling getServerSession(event):
{ 'content-type': 'application/json' }
Headers that useFetch() sees:
HeadersList {
cookies: null,
[Symbol(headers map)]: Map(1) {
'content-type' => { name: 'content-type', value: 'application/json' }
},
[Symbol(headers map sorted)]: null
}
Data that useFetch() sees: { ...normal JS object... }It's still OK in the content-type header was empty at the moment of the getServerSession(event) call.
With 2 calls to getServerSession(event):
Headers in the middleware before calling getServerSession(event):
{}
Headers in the middleware after calling getServerSession(event):
{ 'content-type': [ 'application/json', 'application/json' ] }
Headers that useFetch() sees:
HeadersList {
cookies: null,
[Symbol(headers map)]: Map(1) {
'content-type' => {
name: 'content-type',
value: 'application/json,application/json'
}
},
[Symbol(headers map sorted)]: null
}
Data that useFetch() sees: Blob { size: 1856, type: '' }It's not OK, as useFetch() cannot understand the content-type header, so it considers the returned data as Blob.
The workaround is to call event.node.res.removeHeader('content-type') after calling getServerSession(event), but this workaround is fragile as it will remove any values, even if they are previously set intentially by user's middleware or api handler.
I think that getServerSession(event) should just not modify the headers (or any other data of the H3Event object).
phoenix-ru
j2L4e
warflash
Environment
Build Modules: -
Reproduction
Call getServerSession() multiple times from within any api route handler
Describe the bug
Calling
getServerSessioninternally calls the auth handler. This has side-effects because cookies and headers are set. In my case, having multipleContent-Typeheaders set, caused errors in client-side content type detection.$fetchwouldn't automatically parseapplication/jsonresponses correctly, but return a blob instead.Some component of the nuxt dev setup seems to be deduping or resetting
Content-Typeheaders, effectively mitigating this problem in development. an observable error only occurs in production builds.The cause of this can be observed in dev mode, though.
Additional context
No response
Logs
No response