Be able to handle non-default http clients #6
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
+1 @timkaye11 Can this be used to work with |
|
@pires I believe so - you'd just have to call |
|
@timkaye11 didn't work. |
|
@timkaye11 what is now obvious to me is that I had to comment the line you linked and it worked. Ofc, commenting said line will break runtime. |
jarcoal
added a commit
that referenced
this pull request
Aug 1, 2015
Be able to handle non-default http clients
|
@timkaye11 thanks! |
constantoine
added a commit
to constantoine/httpmock
that referenced
this pull request
Nov 14, 2024
Although RFC 2616 has been superseded with RFC 9110, some client implementation still rely on certain behavious regarding the Status-Line. Now, as httpmock currently implements it, per [RFC 9110#6.2-1](https://www.rfc-editor.org/rfc/rfc9110.html#section-6.2-1), the "reason phrase" is actually optional, and you need only to include the status code. Back in the days of [RFC 2616](https://www.rfc-editor.org/rfc/rfc2616.html#section-6.1), per jarcoal#6.1, the Status-Line had to contain both the status code (eg. 200) and its textual representation (eg. OK). Change code is directly stolen from the Go standard library. Signed-off-by: Cléo Rebert <cleo.rebert@gmail.com>
constantoine
added a commit
to constantoine/httpmock
that referenced
this pull request
Nov 14, 2024
Although RFC 2616 has been superseded with RFC 9110, some client implementation still rely on certain behavious regarding the Status-Line. Now, as httpmock currently implements it, per [RFC 9110#6.2-1](https://www.rfc-editor.org/rfc/rfc9110.html#section-6.2-1), the "reason phrase" is actually optional, and you need only to include the status code. Back in the days of [RFC 2616](https://www.rfc-editor.org/rfc/rfc2616.html#section-6.1), per jarcoal#6.1, the Status-Line had to contain both the status code (eg. 200) and its textual representation (eg. OK). Change code is directly stolen from the Go standard library. Signed-off-by: Cléo Rebert <cleo.rebert@gmail.com>
maxatome
pushed a commit
that referenced
this pull request
Nov 14, 2024
Although RFC 2616 has been superseded with RFC 9110, some client implementation still rely on certain behavious regarding the Status-Line. Now, as httpmock currently implements it, per [RFC 9110#6.2-1](https://www.rfc-editor.org/rfc/rfc9110.html#section-6.2-1), the "reason phrase" is actually optional, and you need only to include the status code. Back in the days of [RFC 2616](https://www.rfc-editor.org/rfc/rfc2616.html#section-6.1), per #6.1, the Status-Line had to contain both the status code (eg. 200) and its textual representation (eg. OK). Change code is directly stolen from the Go standard library. Signed-off-by: Cléo Rebert <cleo.rebert@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to enable mock testing, we currently replace the
http.DefaultTransportwith the mock transport in theActivatefunction. However, we run into errors when we use clients other thanhttp.DefaultClient(which uses the default transport). In order to handle non-default clients, this PR introduces theActivateNonDefaultfunction, which replaces custom thehttp.Transportwith the mock transport for customhttp.Clients.Also bumped travis to the newest version and added a unit test for the new function.