v0.15.0

Spy mode

Thanks to @3sunnysideup, Hoverfly has a new spy mode. When it is set, Hoverfly will only simulate the APIs that you have defined, and call real APIs for anything else. It is deemed useful if the service under test has different external dependencies, and you want to spy on particular endpoints only. To use this new feature, simply set:

$ hoverctl mode spy

Plain HTTP tunneling

This setting allows Hoverfly to handle CONNECT requests for non-TLS tunnelling, making it possible to use Hoverly with Netty-based HTTP client such as reactor-netty.

$ hoverfly -plain-http-tunneling

Network interface binding

Hoverfly now binds to loopback interface by default and prevents firewall alerts being triggered when running on Windows machine. If you still need Hoverfly to listen on all the network interfaces, you can do so by setting:

$ hoverfly -listen-on-host 0.0.0.0

Other minor improvements

• hoverctl statusis now showing if Hoverfly is running on proxy or webserver mode
• You can now pass command line arguments when running Hoverfly Docker image, eg. $ docker run -d -p 8888:8888 -p 8500:8500 spectolabs/hoverfly -webserver

v0.14.2

Templating

• Added helper methods to use current data time for templating.
• State keys can now be used in the template.
  More information on templating is available here.

Hoverctl auto completion

Thanks to @joostvanwollingen, you can now add bash completion file for hoverctl by running:
hoverctl completion

v0.14.1

In this minor release, we fixed a few bugs:

• Fix escaping bug in query params
• Fix hoverctl middleware bug, thanks for the PR from @ooktay
• Always sending original query to the target server in CAPTURE mode

There are some improvements including:

• A new hoverctl status command which prints the status of Hoverfly
• Support for TLS renegotiation

v0.14.0

State

The big addition to v0.14.0 is the introduction of state. Hoverfly stores state as a key value map, allowing for multiple states to be stored at any given time. This state can then be used as a matching requirement for requests and can be modified with successful responses served.

More information on state is available here.

Bug fixes

• Journal latency is now recorded as a float
• Journal startTime is now formatted to include milliseconds
• Requests with encoded characters in the path will now be respected and proxied on in their intended format

v0.13.0

Response templates

Hoverfly finally has the ability to produce dynamic responses with the new templating feature. This feature allows for values from the original request being included in the response body through the use of template tags.

For more information on Templating

v3 Simulation

With the introduction of templating, we have bumped the simulation schema version up to v3. The two changes between v2 and v3 are that the request query field no longer requires character escaping and a new boolean template field on the response to enable templating on a per request response pair basis.

Webserver journal bugfix

It was noticed that the journal was no working when using Hoverfly as a webserver. This has been fixed and should now behave the same regardless if using Hoverfly as a webserver or a proxy.

v0.12.3

requestType field in journal API responses

In the last release, we added the journal API. This API could be used for seeing the requests and responses being served by Hoverfly. There was an old, unused field being used in the request object. This field has now been removed.

Error when importing unrecognised version

In preparation for the next big release of Hoverfly, we noticed a bug. When importing simulations, Hoverfly did not provide a useful error when importing a simulation using an unsupported schema version. This has now been fixed.

v0.12.2

Journal

To give more visibility as to what Hoverfly is up to, we have introduced a record of all requests and responses being served by Hoverfly. This can be found via the new admin API endpoint /api/v2/journal. Along with the requests and responses, metadata for each request is also recorded. This includes latency observed by Hoverfly and the mode it was in. By default, the journal will store the last 1000 requests and responses. The size of the journal is modifiable via a new -journal-size flag.

Hoverctl log files

With the introduction of the logs API several releases ago, and then the updating of the hoverctl logs command to use the API, we have now stopped hoverctl from writing logs to disk. If there are any .log files left you in your .hoverfly/ directory, they can now be deleted as they are no longer used by hoverctl.

Caching bug

We have fixed an issue involving caching. Hoverfly will cache each request/response it serves in an attempt to speed up matching, including failures to match. This bug occurred when
trying to match using specific header values, something that the cache cannot do due to how we hash each request.

v0.12.1

Plaintext logs from Hoverfly

With this small release of Hoverfly, we have updated the logs. Previously, Hoverfly would log out to standard out using JSON formatting. This has been updated to now use the plaintext format. If you depend on JSON formatted logs in standard out, there is now a -logs flag to set the format back to json. The logs API which can be found at /api/v2/logs will still output JSON formatted logs by default.

hoverfly -logs=json

Logs API date filter

We have expanded the logs API to now allow the ability to filter logs based on a UNIX timestamp. This can now be done by providing the from query parameter with a UNIX timestamp value. All logs returned will be after this point in time, making it easier to follow logs and only request new log entries.

Content-Type bug in Hoverfly API

With the introduction of plaintext log formatting to the logs API, a bug was noticed regarding the Content-Type header on responses from the Hoverfly API. Regardless of content, this header was always set to application/json. This has now been fixed so that the header is now correctly set regardless of response body content.

v0.12.0

After several releases of bug fixes, we are finally ready to release the next big update to Hoverfly.

Strongest match

Before v0.12.0, when matching a request in simulate mode, the first match would be returned. This could often be a problem if looser request response pairs were defined at the top of a simulation.

To get around this, we have implemented a scoring system. Each match within a request will be scored and every request response pair from a simulation will now be checked. This should result in more accurate and reliable simulations.

It is still possible to use the previous matching strategy by using the --matching-strategy=first flag when setting the mode with hoverctl.

For more information on Matching strategies

Closest match

With the introduction of scoring request response pairs to determine the most accurate match, Hoverfly can now report the closest request response pair when a request is unmatched. When this happens, an informative report of what happening during matching is now printed both to the logs as well as the HTTP error response body. This should make it much easier now to debug failing requests going through Hoverfly.

Hoverfly UI

The second update to Hoverfly comes in the form of the UI. The UI part of Hoverfly has been neglected for a long time and as a result, we have rebuilt using Angular. This new dashboard is now separate from the Hoverfly codebase in its own codebase.

For more information on Hoverfly UI

hoverfly -dev

With the change to Hoverfly UI being an external project for development, the -dev flag on Hoverfly has been updated to now enable CORS headers.

For more information on Hoverfly flags

v0.11.5

Hoverfly shutdown API

We have added a new endpoint to Hoverfly which will allow users to shutdown Hoverfly. A shutdown can be triggered by sending a DELETE HTTP request to /api/v2/shutdown. This will terminate the instance immediately.

Removed PIDs from hoverctl

With the introduction of the shutdown API on Hoverfly, hoverctl has now been updated to no longer keep track of PIDs. Instead, hoverctl will now rely only on being able to communicate with Hoverfly via the API. This should have no functional impact on how hoverctl is used.

jsonMatch ordering bug

A bug was noticed with the jsonMatch request field matcher. The bug was that the order of elements within the JSON provided was respected when matching, making this matcher more difficult to use. This should now be resolved.

Header key case bug

Another bug was spotted regarding headers served by Hoverfly. They noted that Hoverfly did not always respect the upper and lower case characters of the header keys from the simulation. This has been fixed and Hoverfly should now always send headers that match the headers from the simulation loaded.

TLS verification bug

Someone else pointed out that when setting TLS verification to false, they found Hoverfly was still applying TLS verification to proxied requests. It was promptly discovered that the TLS verification feature was working in reverse, meaning that TLS verification was disabled by default and specifying to disable it actually enabled it. This has been resolved.

WARNING if you are using Hoverfly with services in which you would like to TLS verification disabled, you will now need to set that with either hoverfly -tls-verification=false or hoverctl start --disable-tls.