This issue is being pulled out other work in progress. #1520 (comment)
The intention should be that nock-produced IncomingMessage instances mimic the native behavior of http.IncomingMessage.rawHeaders.
The raw request/response headers list exactly as they were received.
...
Header names are not lowercased, and duplicates are not merged.
...
For example, the previous message header object might have a rawHeaders list like the following:
[ 'ConTent-Length', '123456',
'content-LENGTH', '123',
'content-type', 'text/plain',
'CONNECTION', 'keep-alive',
'Host', 'mysite.com',
'accepT', '*/*' ]
Some work has been done on this front #707, however, notes taken while working on #1520 identified other edge cases where raw headers are not left pristine.
Because of the nature of how the native implementation receives the raw data, it won't be possible to have identical functionality. The largest factor to this being that headers provided in an object will have an arbitrary order in the resulting rawHeaders array.
Nocks's reply headers can be provided in a couple ways:
Scope.defaultReplyHeaders
Interceptor.reply(status, body, headers)
Interceptor.reply(() => [status, body, headers]
Not including the Scope's replyContentLength and replyDate methods, that add calculated values to the Interceptor instance when reply is called.
These suggested guidelines include breaking behavior, but note that rawHeaders is not currently documented and this could be filed as a bugfix.
- All three of the methods above should accept header arguments as either an array in the raw header style, as a "plain" object, or as a Map.
- Headers provided to
defaultReplyHeaders should always come first in the responses raw headers.
- When headers are provided in the raw format, their order must remain intact on the resulting response.
- The final result of the responses raw headers should have keys exactly as they were provided (should non-strings cast or throw?).
- The final result of the responses raw headers should be a flat array of strings.
- When functions are provided to generate values, each function should be called exactly once. Even if keys would normalize to duplicate headers.
- The Response's headers, with normalized keys, should be generated from the raw header style in FIFO order. Duplicate headers will result in the last entry from the raw array.
This issue is being pulled out other work in progress. #1520 (comment)
The intention should be that nock-produced
IncomingMessageinstances mimic the native behavior ofhttp.IncomingMessage.rawHeaders.Some work has been done on this front #707, however, notes taken while working on #1520 identified other edge cases where raw headers are not left pristine.
Because of the nature of how the native implementation receives the raw data, it won't be possible to have identical functionality. The largest factor to this being that headers provided in an object will have an arbitrary order in the resulting rawHeaders array.
Nocks's reply headers can be provided in a couple ways:
Scope.defaultReplyHeadersInterceptor.reply(status, body, headers)Interceptor.reply(() => [status, body, headers]Not including the Scope's
replyContentLengthandreplyDatemethods, that add calculated values to theInterceptorinstance whenreplyis called.These suggested guidelines include breaking behavior, but note that
rawHeadersis not currently documented and this could be filed as a bugfix.defaultReplyHeadersshould always come first in the responses raw headers.