Skip to content
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

How to relate request and response? #80

Open
OnkelTem opened this issue May 12, 2022 · 1 comment
Open

How to relate request and response? #80

OnkelTem opened this issue May 12, 2022 · 1 comment

Comments

@OnkelTem
Copy link

I'm not quite sure how to connect response with its request?

Say I'd like to be able to do:

  server.forUnmatchedRequest().thenPassThrough({
    beforeRequest: (req) => {
      console.log('Request:', req.url.substring(0, 80) + '...');
    },
    beforeResponse: (res) => {
      if (req.url.match(/^url/)) {
        console.log('Response:', res.headers);
      }
    },
  });

Maybe it's worth adding req as the second argument of beforeResponse()? Then it would be possible to do like:

    beforeResponse: (res, req) => {
      if (req.url.match(/^url/)) {
        console.log('Response:', res.headers);
      }
    },
@pimterry
Copy link
Member

There's a .id property on both requests & responses which will match, and you can use that to join up the two. This is also available on requests and responses from events e.g. via server.on('response', (res) => ...), which will fire for all messages, not just for this one specific rule.

That said, I'm open to adding a 2nd req parameter to beforeResponse too if that would be useful, PRs welcome.

This will be mildly tricky in some places but not super difficult - just remember to handle the remote-client case too for both serialization & deserialization. It's easy to check that's working properly by including a test in remote-client.spec.ts, most of those tests run in node (so fast & easy) but uses a remote client like a browser to cover the serialization/deserialization code. I'd suggest just copying this test, changing the contents of beforeRequest and beforeResponse to check that the expected parameters are all there and serialized properly, and then checking you get a 200 at the end (i.e. no assertion errors in the callbacks). Does that make sense?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants