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.

v0.11.4

Logs in hoverctl

We have updated and improved the hoverctl logs command. Using hoverctl logs will now print out plain text logs. To get the logs in a JSON format like before, you can now use the new --json flag. We have renamed --follow-logs to --follow. We have also updated the way we retrieve logs. Before, we were writing the logs to disk and this was created while starting a Hoverfly process. Now, we are using the logs API from Hoverfly. This means hoverctl logs will now work with both local and remote instances of Hoverfly.

Windows bugs in hoverctl

Two bugs were found in previous versions of hoverctl that only occurred on Windows. The first bug occurred when prompted to enter a password, hoverctl would error and terminate. The other bug found was that hoverctl would not update the config file. Both of these bugs have now been fixed.

Default target in hoverctl

The hoverctl targets command has been updated to include a default target indicator in the table of targets. We have also changed the way the default target works. Now, when it points to a target that does not exist, the default target will be changed to the local target.

v0.11.3

Previous version binary size increase

As a result of updating the Hoverfly UI for v0.11.2, the Hoverfly binary increased in size. This has been fixed and the Hoverfly is now back to its original file size.

hoverctl config subcommands

To make hoverctl easier to use, we have extended the config command with four new subcommands. It is now possible to retrieve either the host, admin port, proxy port or the auth token.

hoverctl config host
hoverctl config admin-port
hoverctl config proxy-port
hoverctl config auth-token

These commands can be used to get information about specific targets. For example:

hoverctl -t target-name config host

More information on hoverctl commands

Remote Hoverfly instances and X-HOVERFLY-AUTHORIZATION

When connecting to Hoverfly, regardless if you are proxying HTTP or HTTPS requests, you still need to make an HTTP request to Hoverfly. This can be a security problem when running Hoverfly in non-local environments with authentication enabled. You may be exposing your authorization credentials or your authorization token.

To solve this problem, when starting a Hoverfly instance on a remote host, we recommend using the new -proxy-auth Hoverfly flag with the value header-auth.

This flag will disable the default security mechanisms for the proxy. Instead, Hoverfly will expect a custom security header X-HOVERFLY-AUTHORIZATION. The reason for this that depending on your HTTP client, the default Proxy-Authorization header may be included in the insecure initial request. Using a custom header will make sure the authorization token is not included in that first request.

hoverfly -auth -username bench -password password123 -proxy-auth=header-auth

Setting -proxy-auth=header-auth will enable https-only by default

v0.11.2

Proxy-Authorization header

When authentication is enabled, you can now use a Proxy-Authorization header on the requests you are sending to the proxy. This header accepts both Basic authentication with base64 encoded value and also accepts Bearer authentication with a JWT token value. In combination with this work, we've also added the ability for disabling Basic authentication with the Hoverfly flag -disable-basic-auth.

More information on proxy authentication

--https-only

We have added a new flag to both Hoverfly and hoverctl. This flag is --https-only and will set the Hoverfly proxy to only accept HTTPS requests. Any non HTTPS requests will result in 502 Bad Gateway responses.

More information on hoverctl commands

Timeout after failed authentication attempts

In an effort to keep Hoverfly secure when authentication is enabled, we have added a timeout that is triggered after three unsuccessful login attempts. After the three attempts, logging in result in a 429 Too Many Requests and you will have to wait 10 minutes.

More information on proxy authentication

Version bug

Due to the ongoing work to tidy up the public API of the Hoverfly library, a bug was introduced causing our mechanism to update the version number in the library to not correctly up date the version of Hoverfly. This has now been fixed with this release meaning the version number will now be consistent across Hoverfly.

More information on hoverctl commands