Failed to convert header keys to lower case due to field name conflict: x-request-id
See original GitHub issuestack":["Error: Failed to convert header keys to lower case due to field name conflict: x-request-id"," at /usr/src/node_modules/nock/lib/common.js:247:13"," at /usr/src/node_modules/nock/node_modules/lodash/lodash.js:4925:15"," at baseForOwn (/usr/src/node_modules/nock/node_modules/lodash/lodash.js:3010:24)"," at Function.forOwn (/usr/src/node_modules/nock/node_modules/lodash/lodash.js:13013:24)"," at Object.headersFieldNamesToLowerCase (/usr/src/node_modules/nock/lib/common.js:244:5)"," at RequestOverrider (/usr/src/node_modules/nock/lib/request_overrider.js:104:30)"," at new OverriddenClientRequest (/usr/src/node_modules/nock/lib/intercept.js:260:23)"," at /usr/src/node_modules/nock/lib/intercept.js:395:13"," at Object.module.request (/usr/src/node_modules/nock/lib/common.js:140:14)",
I saw there was a PR related to that? @gr2m
Issue Analytics
- State:
- Created 5 years ago
- Comments:11 (4 by maintainers)
Top Results From Across the Web
How to prevent of converting header name into lower case
Looks like tomcat container turns the headers to lowercase. Since spring boot uses an embedded tomcat is been affected by it.
Read more >Failed to convert header keys to lower case due to field name ...
I get this error when I use express-http-proxy >= 0.9.1: Failed to convert header keys to lower case due to field name conflict: ......
Read more >HTTP header manipulation - Envoy Proxy
The HTTP connection manager manipulates several HTTP headers both during decoding ... URI The URI type Subject Alternative Name field of the current...
Read more >HTTP/1.1: Header Field Definitions
The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used...
Read more >Elastic Common Schema (ECS) Reference
ECS specifies field names and Elasticsearch datatypes for each field, ... labels doesn't work for your use case, here's a few more tips...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
We fixed it by just changing our code because and sticking with one casing for our requests. Fingers crossed it won’t fail elsewhere 😃 but indeed I don’t think nock should care about header casing or there should be an option a switch or a regexp we can use to accept both. An option ideally for case sensitive or insensitive headers. Or just what @krekkied suggested
Checked it a bit more. It throws the error when the request has the same header name in different casing. Formally headers should be case insensitive, but technically it’s possible to send in the same header with different casing.
I’m not sure nock should be throwing errors when this occurs. I mean sure it’s not desirable to have the same header names on the consuming side (because which of the variations is the one that should be used…?), but it’ll complicate consuming nock if it throws errors on it.
Also an actual server would not error on it by default, which could mean nock shouldn’t either. I’m not sure if there are rules that state which of the headers should be used.
Maybe nock should use the first value instead:
or the last;