Allow injection of additional headers in replay #43
Conversation
|
@dcarley Can you describe possible usecases, except auth stuff? Thanks! |
|
Our immediate use is setting an HTTP header that triggers a feature flag in staging. So that we can selectively see how it performs under real traffic. I've also been using it to modify I'll work on some tests; for argument validation and making sure the right thing appears in the request. Do you think they belong with the existing integration tests? |
|
Thanks! Definitly useful feature. |
|
Also wanted to ask if i can add your organization to list of companies using "Gor"? If so, i need organization name and URL. Thanks! |
|
Sure, "we" are the Government Digital Service :) |
Run all tests + fix failing ES test
|
I'll reopen when I'm done with the tests. |
Similar to curl(1) and siege(1): - Can be specified multiple times. - Will overwrite headers of the same key name in the original request. - An argument without a value (`Foo:`) will be set as empty. - Leading and trailing whitespace will be stripped from the key and value, otherwise it's difficult to determine where the key or value begin/end.
Per the features described in the preceding commit.
Re-using one of the existing integration tests. If we were to refactor some of the logic to send and receieve a single request then it would make sense to split this, and the cookie validation, out to separate test cases.
|
Now with tests. |
|
Looks good! Pls update README.md |
It's in the first commit ;) |
|
Oh, awesome. Merging :) |
Allow injection of additional headers in replay
Similar to curl(1) and siege(1):
Foo:) will be set as empty.otherwise it's difficult to determine where the key or value begin/end.