Stuck in below problem where Hoverlfy should return only the specific value (not the whole) passed inside query or parameter in response body. I tried below but it’s returning the whole parameter but not just one of the value required.
This is the request (POST):
http://localhost:8500/ServiceDetails?filter={"condition":{"a1":"x1","a2":"x2","a3":"x3","a4":"x4"}}
- Value of a4 (ie. x4) inside filter needs to be passed in response ie values
I used below method to capture:
"{{ Request.QueryParam.filter “jsonpath” “$.condition.a4” }}"
Could you tell me why hoverfly adds the HTTP header "Req/ Resp"?
I think this header is probably for confirmation that hoverfly alive, however, some tests will be failed if the application under test can only accept expected request headers.
Implementation of some kind of the bool flag for default HTTP headers might be useful...?
(I intend to create pull requests for this issue sometime.)
3 replies
Is there a known issue with using the verificationData within a verify() ? I'm seeing that when I try to retrieve the journal entries from the verificationData it is only available intermittently, even when the verify passes.
For example,
hoverfly.verify(
service("someservice")
.post("someendpoint")
.anyBody()
,(((request, verificationData) -> {
if (verificationData.getJournal().getEntries().size() > 0) {
JournalEntry journalEntry = verificationData.getJournal().getEntries().get(0);
String requestBody = journalEntry.getRequest().getBody();
}
}))
The journal entries sometimes are empty and sometimes have the expected values??
7 replies
- Our OCP platform only allows Https. I am not sure if running in Proxy mode even possible with the HTTPS is the the only possible option.
- How to run Hoverfly in debug mode ?
- I am trying to capture Payloads from Https traffic. When running in Proxy mode - Https terminates at the network level - since it terminates at the edge , i do not think it will need certificates. Can someone advise if my understanding is correct ?
Unless I'm missing something in the docs, it seems like there's currently no way to get Hoverfly to recognize two multipart/form-data requests with the same payloads as identical... e.g. curl localhost -F foo=bar; !!, because the request body contains random/nondeterministic form data boundary strings per the HTTP spec.
Is there a good way to work around that, or would this need to be requested as a new feature?
2 replies
31 replies
16 replies
capture while making a call to target service in postman to create simulation with proxyHost as localhost and proxyPort as 8500. Getting the following errorHoverfly Error!
There was an error when forwarding the request to the intended destination
Got error: Post https://url :EOF
8 replies
1 reply
https://github.com/agilepathway/hoverfly-github-action
Bonjour, j’utilise le mode simulate pour l’appel web service, donc je suis les étapes suivante :
hoverctl mode capture
hoverctl import simulationOLD.json
hoverctl mode Simulate
puis je lance la requête : curl --proxy http://localhost:8500 http://localhost:9091/xxxxxxxxxx
Le problème j'arrive pas a suitchi entre Hoverfly et les vrai backend , pouvez vous m'aidé svp?
Hello, I am using hoverfly simulation mode for the web service call, so I am following a steps:
hoverctl mode capture
hoverctl import simulation.json
hoverctl mode Simulate
then I run the request: curl --proxy http: // localhost: 8500 http: // localhost: 9091 / xxxxxxxxxx
The problem that I don't have to switch between Hoverfly simulation and the real backend, can you help me please?
Hi! I'm experiencing the absolute weirdest bug with Hoverfly for some reason not passing the on the correct HTTP request to the actual server. This might be related to this:
32 replies
Hi, I'm using hoverfly simulation mode for test and I have a small problem.
When I use this setting:
"data": {
"pairs": [
{
"request": {
...
"response": {
"status": 200,
"body": "{\"sampleResponse\":\"This is Sample.\"}\n",
"encodedBody": false,
"headers": {
"TestResponseHeader": [
"test"
]
},
...then the response contains headers:
"Testresponseheader" : "test"The header TestResponseHeader is changed to lower-case Testresponseheader.
Do you have any solutions for this problem?
4 replies
{
"data": {
"pairs": [
{
"request": {
"path": {
"exactMatch": "/api/back_office/accounts/"
},
"method": {
"exactMatch": "GET"
},
"destination": {
"exactMatch": "domain.com"
},
"scheme": {
"exactMatch": "http"
},
"query": {
"account_numbers": [
{
"matcher": "exact",
"value": "J6Y000339"
}
]
}
},
"response": {
"status": 200,
"body": "{ \"existing_account_numbers\": [] }",
"encodedBody": false,
"headers": {
"Cache-Control": [
"private"
],
"Content-Type": [
"application/json; charset=UTF-8"
],
"Date": [
"Thu, 31 Aug 2017 11:25:17 GMT"
]
},
"templated": false
}
},
{
"request": {
"path": {
"exactMatch": "/api/back_office/accounts/"
},
"method": {
"exactMatch": "GET"
},
"destination": {
"exactMatch": "domain.com"
},
"scheme": {
"exactMatch": "http"
},
"query": {
"account_number": [
{
"matcher": "exact",
"value": "J6Y000123;J6Y000456"
}
]
}
},
"response": {
"status": 200,
"body": "{ \"existing_account_numbers\": [\"J6Y000123\", \"J6Y000456\"] }",
"encodedBody": false,
"headers": {
"Cache-Control": [
"private"
],
"Content-Type": [
"application/json; charset=UTF-8"
],
"Date": [
"Thu, 31 Aug 2017 11:25:18 GMT"
]
}
}
}
],
"globalActions": {
"delays": []
}
},
"meta": {
"schemaVersion": "v4",
"hoverflyVersion": "v0.14.0",
"timeExported": "2017-08-31T12:24:18+01:00"
}
}WARNING: data.pairs[1] is not added due to a conflict with the existing simulation
6 replies
Hello Folks,
I am using hoverfly in capture mode to make Downstream calls so that I can use the simulated data later. When trying to call the downstream application from a java application which are HTTPS(443) endpoints
and having proxy setup in between, I am seeing "General SSLEngine problem" error being returned.
(All the requests and parameters used for testing are correct as they work if the proxy is not used.)
I have tried to use the "-tls-verification=false", "disableTlsVerification = true" as well as "--client-authentication-ca-cert <cert>" options, none of them seem to fix the issue.
Also tried to running hoverfly in simulation mode and using "curl --proxy http://localhost:8500 <destinationUrl>" to capture the simulation, but this failed too.
All of them return the same error on the console as stated below:
"[003] WARN: Cannot handshake client <ClientUrl:443> remote error: tls: unknown certificate"
Command used for running hoverfly:
"hoverfly -listen-on-host 0.0.0.0 --pp 8500 -plain-http-tunneling &"
Hoverfly version:
"v1.1.2"
5 replies
Hi all — I’m trying to migrate a springboot app from web to webflux, but am finding hoverfly isn’t capturing webclient requests.
I’ve read through these:
But I’m not quite clear on the simplest config that will make this work. Any further pointers (including sample projects) welcome. Thanks!
So can we walk through this?
- junit 5 + webtestclient => controller => service using webclient calling external non-local service.
Is something like this required? What should it be?
@Configuration
class WebClientConfig {
@Bean
WebClient.Builder defaultJsonWebClient(ClientHttpConnector clientHttpConnector) {
return WebClient.builder()
.clientConnector(clientHttpConnector)
.defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE);
}
@Bean
ClientHttpConnector clientHttpConnector() {
return new ReactorClientHttpConnector();
}
}
@TestConfiguration
class TestConfig {
@Bean
@Primary
ClientHttpConnector clientHttpConnector() {
HttpClient httpClient = HttpClient.create()
.tcpConfiguration(???) // FIXME
return new ReactorClientHttpConnector(httpClient);
}
}
This is a proxy server. Does not respond to non-proxy requests. is this expected/ correct behavior? because I remember it used to be able to relay to my local
Hi. Quick question on the different types of request matchers - is their any documentation on the ranking/order/priority of matcher types? - i.e. is "exact" matcher stronger than "regex" matcher, even if both expressions evaluate to true when the inbound request is parsed and compared against each matcher?
Would appreciate if anyone is able to confirm this behaviour around the strongest matcher types or if there is none as such?
Hi. Quick question on the different types of request matchers - is their any documentation on the ranking/order/priority of matcher types? - i.e. is "exact" matcher stronger than "regex" matcher, even if both expressions evaluate to true when the inbound request is parsed and compared against each matcher?
Would appreciate if anyone is able to confirm this behaviour around the strongest matcher types or if there is none as such?
just a note... i have tested this multiple times and it does seem like "exact" matcher is stronger than "regex" match, however would like to confirm from the Hoverfly docs if this is indeed the intended/correct/expected behaviour or not?
2 replies