Context

I use sendgrid library to send emails. What I want to test is whether email is sent under certain conditions and whether Authorization header contains token that was provided in app configuration. Sendgrid library slightly misses casing of User-Agent header. Again, nothing criminal. Resulting headers are

    {
        "Accept": "application/json",
        "Content-Type": "application/json",
        "User-agent": "sendgrid/7.0.0;nodejs",
        "Authorization": "Bearer SG.fake-api-key",
        "User-Agent": "axios/0.19.2",
        "Content-Length": 188
    }

But my tests now fail with Error: Failed to convert header keys to lower case due to field name conflict: user-agent. Clearly, in this case functionally everything will continue to work on sendgrid's side, the only problem is that now I can't test what I want to test.

I understand why you would hesitate to change this behaviour: would I be an author of a library, I would like to know that I messed up in casing of one of my header, since that could lead to a bug that would be hard to detect and time-consuming to debug.
But as an end-application developer I think I provided a convincing example of a situation in which this behaviour is undesirable.
I believe that approach taken in #1741 (replace exception with a warning) would achieve both goals: it would be possible to go on with your testing while being informed that there is a problem with one of your headers.

Alternatives

The options currently present are:

• to ask third-party library authors to fix wrong header (the only rationale being is that it makes hard to test their libraries with nock)
• to include a hack in the actual code trying to work around this problem (changes to the code made just for the sake of fixing tests is a code smell)
• to include a hack in the testing code (which is slightly better, but still messy)
• to fix this in the nock (this seems like a most logical solution)

Has the feature been requested before?

I understand that the issue has been raised a number of times, the most recent being #1741, but it seems that there is no understanding as to why this is important, so I am trying to make my case.

If the feature request is accepted, would you be willing to submit a PR?

Yes