This repository has been archived by the owner on Jan 28, 2025. It is now read-only.
Bug/header-name case-sensitive #331
Merged
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
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
danielcondemarin
approved these changes
Mar 29, 2020
a14m
added a commit
to infographicsgroup/serverless-next.js
that referenced
this pull request
Apr 3, 2020
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
added a commit
to infographicsgroup/serverless-next.js
that referenced
this pull request
Apr 3, 2020
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
danielcondemarin
pushed a commit
that referenced
this pull request
Apr 4, 2020
…t a function (#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 #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 #331 * Update the npm package-lock
sclaughl
pushed a commit
to sclaughl/serverless-next.js
that referenced
this pull request
Jul 16, 2020
* 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
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.
Previously the following behaviour could be observed:
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