I have a bunch of captured flows that include some POST requests to the same URL with different bodies, and corresponding different responses.
I want to replay these using -S in an offline scenario. However, if I do not specify the --replay-ignore-content header the requests are not matched (so connection is killed because I use -k to enforce that it’s offline only because I don’t want to hit the third-party server while testing this) and if I do specify --replay-ignore-content then all of the POST requests return the same response (the first one in the file) because the content isn’t included in the match.
Is there a way to see what isn’t matching correctly in the first scenario so I can have different POSTs to the same URL? So far I have verified the method, scheme, host, port, path, and query string, and the content appears to be correct as well.
I am not specifying --norefresh, --server-replay-use-header, etc. I am specifying --no-pop so that I don’t have to restart the proxy to return the same content multiple times. (I want it to vary by the request content)
I have stopped using --no-pop for now so that I can progress, but this results in the server replaying the messages in the order they were originally captured, regardless of the message body. This is less than ideal from a testing standpoint since any POST to a particular route pops the next response message, resulting in there being no relationship between what is posted and what is returned.
Thanks, that’s pretty much exactly what I ended up doing. (Logged to file, but same concept.)
Turned out that it was my own fault. I had translated the dump file to json, thought I had made some modifications, then back to tnetstrings. However, for these forms it was using the original data instead of my modifications because I forgot to change a flag in my software that translated it back and forth. Once I realized that, I was able to test with the original data to prove it worked, then actually make my modifications and test that it still worked.