Throw if headersFieldNamesToLowerCase is not provided an object. #1574
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
|
I was going to commit this as a new feature, though I'm not sure how best to describe this from the caller's perspective. Do we still support header arrays passed as e.g. |
Adds a test to cover the exception case. Going through the git history for this function, all the way back to when it was added with 4048734, I can't find a case where a non-object input was valid. Once PR # 1564 is merged in, this utility will only be called in two places: - Creating an Interceptor if the Scope was created with `options` - When http.request is called with an `options` object In both places, providing defined, but non-object values causes chaos. If the value is a truthy, non-iterable then the header was ignored during matching. For example, the following will match Interceptors as if `reqheaders` had not been provided. ```js nock('http://example.com', { reqheaders: 1 }).get('/').reply ``` However, if the value was provided as a non-plain object iterable, such as an array or string, the header matching logic would attempt to match header field names with numerical keys, rendering the whole Scope useless.
mastermatt
force-pushed
the
fix-todo/headers-field-names-to-lower-case
branch
from
bafe6e7
to
7ce75b8
Compare
|
The changes to headers in #1564 (that allowed headers as arrays) was only for reply headers. Since that PR was merged, |
|
🎉 This PR is included in version 11.0.0-beta.19 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 11.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
gr2m
pushed a commit
that referenced
this pull request
Sep 4, 2019
Throw if headersFieldNamesToLowerCase is not provided an object. Adds a test to cover the exception case. Going through the git history for this function, all the way back to when it was added with 4048734, I can't find a case where a non-object input was valid. Once PR # 1564 is merged in, this utility will only be called in two places: - Creating an Interceptor if the Scope was created with `options` - When http.request is called with an `options` object In both places, providing defined, but non-object values causes chaos. If the value is a truthy, non-iterable then the header was ignored during matching. For example, the following will match Interceptors as if `reqheaders` had not been provided. ```js nock('http://example.com', { reqheaders: 1 }).get('/').reply ``` However, if the value was provided as a non-plain object iterable, such as an array or string, the header matching logic would attempt to match header field names with numerical keys, rendering the whole Scope useless.
gr2m
pushed a commit
that referenced
this pull request
Sep 4, 2019
Throw if headersFieldNamesToLowerCase is not provided an object. Adds a test to cover the exception case. Going through the git history for this function, all the way back to when it was added with 4048734, I can't find a case where a non-object input was valid. Once PR # 1564 is merged in, this utility will only be called in two places: - Creating an Interceptor if the Scope was created with `options` - When http.request is called with an `options` object In both places, providing defined, but non-object values causes chaos. If the value is a truthy, non-iterable then the header was ignored during matching. For example, the following will match Interceptors as if `reqheaders` had not been provided. ```js nock('http://example.com', { reqheaders: 1 }).get('/').reply ``` However, if the value was provided as a non-plain object iterable, such as an array or string, the header matching logic would attempt to match header field names with numerical keys, rendering the whole Scope useless.
gr2m
pushed a commit
that referenced
this pull request
Sep 5, 2019
Throw if headersFieldNamesToLowerCase is not provided an object. Adds a test to cover the exception case. Going through the git history for this function, all the way back to when it was added with 4048734, I can't find a case where a non-object input was valid. Once PR # 1564 is merged in, this utility will only be called in two places: - Creating an Interceptor if the Scope was created with `options` - When http.request is called with an `options` object In both places, providing defined, but non-object values causes chaos. If the value is a truthy, non-iterable then the header was ignored during matching. For example, the following will match Interceptors as if `reqheaders` had not been provided. ```js nock('http://example.com', { reqheaders: 1 }).get('/').reply ``` However, if the value was provided as a non-plain object iterable, such as an array or string, the header matching logic would attempt to match header field names with numerical keys, rendering the whole Scope useless.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Adds a test to cover the exception case.
Going through the git history for this function, all the way back to
when it was added with 4048734, I can't find a case where a non-object
input was valid.
Once PR # 1564 is merged in, this utility will only be called in two
places:
optionsoptionsobjectIn both places, providing defined, but non-object values causes chaos.
If the value is a truthy, non-iterable then the header was ignored
during matching. For example, the following will match Interceptors as
if
reqheadershad not been provided.However, if the value was provided as a non-plain object iterable, such
as an array or string, the header matching logic would attempt to match
header field names with numerical keys, rendering the whole Scope
useless.