mirror of
https://github.com/wiremock/WireMock.Net.git
synced 2026-01-11 22:30:41 +01:00
Feature: Please provide support for Bad responses. #212
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @grzegorz-wolszczak on GitHub (Sep 10, 2019).
Hi.
I can see that WireMock-Net already supports delayed responses, but
it would be even more cool if WireMock-Net supported simulating bad responses as in
http://wiremock.org/docs/simulating-faults/
@StefH commented on GitHub (Sep 16, 2019):
What kind of bad responses do you need?
@grzegorz-wolszczak commented on GitHub (Sep 18, 2019):
I was referring to the bad responses described as:
EMPTY_RESPONSE: Return a completely empty response.
MALFORMED_RESPONSE_CHUNK: Send an OK status header, then garbage, then close the connection.
RANDOM_DATA_THEN_CLOSE: Send garbage then close the connection.
CONNECTION_RESET_BY_PEER:
@StefH commented on GitHub (Sep 23, 2019):
Something like:
This will return an empty response 1 on 10 times.
This code will always return an empty response...
Is this an idea?
@grzegorz-wolszczak commented on GitHub (Sep 23, 2019):
Yea, that would be cool.
But the feature I would like the most (and might be most difficult to create) is to have response
CONNECTION_RESET_BY_PEER.
@StefH commented on GitHub (Sep 24, 2019):
About :
MALFORMED_RESPONSE_CHUNK: Send an OK status header, then garbage, then close the connection.@grzegorz-wolszczak commented on GitHub (Sep 25, 2019):
I agree with you that sending 200 OK and closing connection is enough.
@StefH commented on GitHub (Oct 11, 2019):
@grzegorz-wolszczak
A preview NuGet (from MygGet) -->
WireMock.Net.1.0.32-ci-12002.nupkgcan be tested.@StefH commented on GitHub (Oct 22, 2019):
@grzegorz-wolszczak Can you please test this preview and report back your findings?
@grzegorz-wolszczak commented on GitHub (Oct 22, 2019):
Hi Stef
Sorry for not responding sooner.
I really couldn't find time for testing.
I will try to do as soon as possible.
@grzegorz-wolszczak commented on GitHub (Oct 23, 2019):
How should I test new library ? What new Api was introduced to handle cases like:
MALFORMED_RESPONSE_CHUNK
RANDOM_DATA_THEN_CLOSE
CONNECTION_RESET_BY_PEER
I was trying to find some methods on IResponseBuilder interface but I did not see anything that would map to the responses I've described in my feature request. I tried to grep your git commit history by the issue number (#343) but also could not find any. In which commit (or commits) did you introduce changes for this issue? I will look into it and figure out the rest.
@StefH commented on GitHub (Oct 23, 2019):
1]
This NuGet package on the MyGet feed should implement this fix:
https://www.myget.org/feed/wiremock-net/package/nuget/WireMock.Net/1.0.32-ci-12002
2]
Or you can clone this project and switch to branch https://github.com/WireMock-Net/WireMock.Net/tree/WithFault
3a]
New API is like:
https://github.com/WireMock-Net/WireMock.Net/blob/WithFault/test/WireMock.Net.Tests/ResponseBuilders/ResponseWithWithFaultTests.cs
3b]
Or via JSON admin interface :
@grzegorz-wolszczak commented on GitHub (Oct 23, 2019):
Ok, now i See what the problem was, I have chosen wrong nuget version.
So I've tested
EMPTY_RESPONSE, and RANDOM_DATA_THEN_CLOSE and it works good (tested with 'curl')
but for FaultType.MALFORMED_RESPONSE_CHUNK
when request GET
I got:
Status code: 500Internal Server Error
and body
I guess this is intended ?
Also what about 'most interesting' fault type , which is CONNECTION_RESET_BY_PEER ? There was no enum value for it.
Apart from that, everything is great :)
@StefH commented on GitHub (Oct 23, 2019):
About malformed response , this should not throw a 500.
Can you provide your code or mapping json?
@StefH commented on GitHub (Oct 24, 2019):
I found the issue. Please try MyGet : WireMock.Net.1.0.32-ci-12060
@grzegorz-wolszczak commented on GitHub (Oct 24, 2019):
The code I used was (simplified version I found on your's project wiki):
I've used nuget version: WireMock.Net.1.0.32-ci-12002.nupkg
@StefH commented on GitHub (Oct 24, 2019):
Thanks.
Can you retry WireMock.Net.1.0.32-ci-12060?
@grzegorz-wolszczak commented on GitHub (Oct 24, 2019):
WireMock.Net.1.0.32-ci-12060 works.
Although I could not spot the difference between MALFORMED_RESPONSE_CHUNK and RANDOM_DATA_THEN_CLOSE.
Both respond with 200 OK and some random body.
From what I can understand in http://wiremock.org/docs/simulating-faults/ in 'Bad responses' section.
RANDOM_DATA_THEN_CLOSE does not send 200 OK header (it does not send any header at all)
@StefH commented on GitHub (Oct 24, 2019):
1] There is a difference.
In case you have a body defined, the MALFORMED_RESPONSE_CHUNK returns half of that body and the rest is random.
2] RANDOM_DATA_THEN_CLOSE should not write any header. However, maybe the default header is 200.
The other two errors will take your original defined header.
@StefH commented on GitHub (Oct 25, 2019):
@grzegorz-wolszczak Does my comment make sense?
@grzegorz-wolszczak commented on GitHub (Oct 25, 2019):
With MALFORMED_RESPONSE_CHUNK it makes sense.
But when it comes to RANDOM_DATA_THEN_CLOSE i believe that the sole purpose of it was exactly that, 'random data' which means that response does not conform to any valid HTTP response from the protocol standpoint. So it is more a random TCP packet than HTTP message (with valid headers, status line and so on).
@StefH commented on GitHub (Oct 25, 2019):
With the current code and setup, I don't think I can really generate random data (TCP packet) instead of an HTTP message. But I will investigate.
@grzegorz-wolszczak commented on GitHub (Oct 25, 2019):
I understand that this might be very difficult or event impossible. Probably Kestrel does not allow of such low-level packet manipulation. If so I would remove the RANDOM_DATA_THEN_CLOSE from the solution utill you figure out how to achieve it. Apart from that , the rest of your code brings new value to WireMock library so I would merge it.
@StefH commented on GitHub (Oct 26, 2019):
Merged to master and a new NuGet will be released shortly.