-
-
Notifications
You must be signed in to change notification settings - Fork 733
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Throw if headersFieldNamesToLowerCase is not provided an object. #1574
Throw if headersFieldNamesToLowerCase is not provided an object. #1574
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me!
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.
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 📦🚀 |
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.
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.
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.
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:
options
options
objectIn 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.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.