See discussion at #1712 (comment).
setRequestHeaders() is being called both during and after matching. It struck me that calling it twice probably was not necessary, as headers set during matching would still be in place during playback. Sure enough, if I remove the second call, the tests pass.
As I think about it further, I wondered if setRequestHeaders() may be causing problems that aren't covered by the tests, and if this implementation – which relies on repeatedly mutating the request state – may be problematic.
I've managed to produce some failing tests. They illustrate some inconsistent behaviors, though I haven't really articulated the desired behaviors, and these edge cases may or may not occur in reasonable use cases.
I think the way to get more consistent behaviors is probably not to mutate req.headers, but instead to clone it into a separate object that can be passed around as needed.
I've got a branch that refactors setRequestHeaders(), and a set of tests that illustrate problems with the headers which seem unrelated to the refactor. I'll open PRs with both though I'm not sure the best sequence of events here. Perhaps since I wasn't able to poke holes in the refactor, we should merge the refactor which simplifies the implementation slightly, and from there return to the failing tests.
See discussion at #1712 (comment).
setRequestHeaders()is being called both during and after matching. It struck me that calling it twice probably was not necessary, as headers set during matching would still be in place during playback. Sure enough, if I remove the second call, the tests pass.As I think about it further, I wondered if
setRequestHeaders()may be causing problems that aren't covered by the tests, and if this implementation – which relies on repeatedly mutating the request state – may be problematic.I've managed to produce some failing tests. They illustrate some inconsistent behaviors, though I haven't really articulated the desired behaviors, and these edge cases may or may not occur in reasonable use cases.
I think the way to get more consistent behaviors is probably not to mutate
req.headers, but instead to clone it into a separate object that can be passed around as needed.I've got a branch that refactors
setRequestHeaders(), and a set of tests that illustrate problems with the headers which seem unrelated to the refactor. I'll open PRs with both though I'm not sure the best sequence of events here. Perhaps since I wasn't able to poke holes in the refactor, we should merge the refactor which simplifies the implementation slightly, and from there return to the failing tests.