Handle the case where the access-control-request-header is not provided #347
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.
This fixes issue #346
So for whatever reason the client I am using, when making an
OPTIONS
request tos3rver
is not specifying anyAccess-Control-Request-Header
headers at all. As a results3rver
erroneously responds with a 403 error. S3 proper does not have this same issue for the exact same request.I have added a test which fails with vanilla master code and passes once I made the corresponding fix.
The issue appears to be here where if the header is not specified then
requestHeaders
ends up being[ '' ]
rather than[]
. Then when we get to the check here the conditional expressionallowedHeaders.length < requestHeaders.length
fails because[].length < [ '' ].length === true
.Therefore my solution is to remove empty elements from the set since that should never happen provided there is a value specified in the header.
Before
curl:
s3rver:
$ node . now listening on host 0.0.0.0 and port 4569 info: [S3rver] OPTIONS /example/abc123 403 344 - 3.963 ms
After
curl:
s3rver:
$ node . now listening on host 0.0.0.0 and port 4569 info: [S3rver] OPTIONS /example/abc123 200 - - 1.668 ms