Closed tyx closed 7 years ago
Yes for sandRequest, in fact I guess most of the time headers should be stateless. The only case when we want to keep a state of headers is thing like auth token, we made the error to believe that the exception was the rule so in any cases we should be BC break about.
PR updated to reflect these changes.
Need to test with real app to see impact
LGTM. We need to test in real situation indeed.
The current behavior where headers persist for the entire lifetime of a test suite came from the removal of the line which emptied this the requestHeaders
array in RestApiBrowser
.
Without patching this class to restore the original behavior where the headers were reset after the request was sent, our test suite is completely nonfunctional.
We can close here. The fix in #70 is just enough to handle the behavior needed
If we want to let people use the same instance of RestApiBrowser to perform different type of request with different context (Auth and no Auth for example)
Drawbacks:
One solution could be to move headers storage inside RestContext. So people could use restApiBrowser by passing directly headers to
sendRequest
. Still BC break but with less impact ?