This repository has been archived by the owner on Jan 28, 2025. It is now read-only.
Fix the issue with TypeError hasHeader is not a function #342
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When deploying to netlify or AWS (both depend on AWS-lambda)
The SSR components (using `getServerSideProps` fails with the following
error:
```
ERROR TypeError: res.hasHeader is not a function
at sendPayload (/var/task/pages/test.js:5787:41)
at renderReqToHTML (/var/task/pages/test.js:1773:13)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async Module.render (/var/task/pages/test.js:1816:22)
```
This is caused by nextjs trying to use the default node `hasHeader`
method here: https://github.com/zeit/next.js/blob/v9.3.1/packages/next/next-server/server/send-payload.ts#L25
This commit fix the issue reported here: vercel/next.js#11223
which I could verify also happening on our stack by adding the method
that mimics the nodeJS method (using `res.getHeader(name)` internally wrapping it
in boolean response)
Previously fixed for next-aws-lambda in serverless-nextjs#329
Previously the following behaviour could be observed:
```
res.setHeader("X-CUSTOM", "VAL")
res.getHeader("X-CUSTOM") => null
res.hasHeader("X-CUSTOM") => false
res.setHeader("x-custom", "val")
res.getHeader("X-CUSTOM") => "val"
res.hasHeader("X-CUSTOM") => true
```
There is no way of accessing a header that isn't set in lower case,
This fixes the issue by always storing the header name as lower case,
allowing a similar behaviour to node HTTP ResponseObject behaviour
- https://nodejs.org/api/http.html#http_request_getheader_name
- https://nodejs.org/api/http.html#http_request_removeheader_name
- https://nodejs.org/api/http.html#http_request_setheader_name_value
Previously fixed for next-aws-lambda in serverless-nextjs#331
a14m
force-pushed
the
bug/res.hasHeader-cloud-front
branch
from
0f2a18d to
e2e81b1
Compare
danielcondemarin
approved these changes
Apr 4, 2020
|
Thanks again 🙏 |
|
What's the ETA of this getting into release? |
|
I've just published it. Should be available in |
sclaughl
pushed a commit
to sclaughl/serverless-next.js
that referenced
this pull request
Jul 16, 2020
…t a function (serverless-nextjs#342) * Fix the issue with TypeError hasHeader is not a function When deploying to netlify or AWS (both depend on AWS-lambda) The SSR components (using `getServerSideProps` fails with the following error: ``` ERROR TypeError: res.hasHeader is not a function at sendPayload (/var/task/pages/test.js:5787:41) at renderReqToHTML (/var/task/pages/test.js:1773:13) at processTicksAndRejections (internal/process/task_queues.js:97:5) at async Module.render (/var/task/pages/test.js:1816:22) ``` This is caused by nextjs trying to use the default node `hasHeader` method here: https://github.com/zeit/next.js/blob/v9.3.1/packages/next/next-server/server/send-payload.ts#L25 This commit fix the issue reported here: vercel/next.js#11223 which I could verify also happening on our stack by adding the method that mimics the nodeJS method (using `res.getHeader(name)` internally wrapping it in boolean response) Previously fixed for next-aws-lambda in serverless-nextjs#329 * Fix the headers to always work with lower case Previously the following behaviour could be observed: ``` res.setHeader("X-CUSTOM", "VAL") res.getHeader("X-CUSTOM") => null res.hasHeader("X-CUSTOM") => false res.setHeader("x-custom", "val") res.getHeader("X-CUSTOM") => "val" res.hasHeader("X-CUSTOM") => true ``` There is no way of accessing a header that isn't set in lower case, This fixes the issue by always storing the header name as lower case, allowing a similar behaviour to node HTTP ResponseObject behaviour - https://nodejs.org/api/http.html#http_request_getheader_name - https://nodejs.org/api/http.html#http_request_removeheader_name - https://nodejs.org/api/http.html#http_request_setheader_name_value Previously fixed for next-aws-lambda in serverless-nextjs#331 * Update the npm package-lock
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When deploying to netlify or AWS (both depend on AWS-lambda)
The SSR components (using
getServerSidePropsfails with the followingerror:
This is caused by nextjs trying to use the default node
hasHeadermethod here: https://github.com/zeit/next.js/blob/v9.3.1/packages/next/next-server/server/send-payload.ts#L25
This commit fix the issue reported here: vercel/next.js#11223
which I could verify also happening on our stack by adding the method
that mimics the nodeJS method (using
res.getHeader(name)internally wrapping itin boolean response)
Previously fixed for next-aws-lambda in #329
also fix the header inconsistencies previously fixed for next-aws-lambda in #331