v0.11.1

hoverctl targets

We've made a big change to how hoverctl works. "Targets" make it easier to work with multiple Hoverfly instances - this is especially useful if you want to use hoverctl to manage both local and remote instances.

A target stores the configuration for a Hoverfly instance, so you can easily specify which instance to use when executing hoverctl commands by setting the -t / --target flag. If you do not specify a target, hoverctl will use the "default" target. Targets can be viewed using hoverctl targets and can be created using hoverctl targets create my-target.

More information on hoverctl targets

A hoverctl targets tutorial

hoverctl login

We have added a new command for logging into an instance of Hoverfly. As part of this change, we've moved the username and password out of the config file. Instead, when using the hoverctl login command, you will be now prompted to enter a username and password.

More information on hoverctl login

hoverctl start --auth

With the introduction of the new hoverctl login command, we have also added the --auth flag to hoverctl start. Using this flag will prompt you to set a username and password which will be used to log in to the Hoverfly instance.

More information on starting Hoverfly with authentication

hoverctl middleware

Based on feedback, we have shortened the output of the hoverctl middleware command. Before, it would print out the full middleware script. Now, it will print the first five lines so that you can confirm that a script has been set. If you want to see the full script, this can be done by using the verbose -v flag.

More information on middleware

hoverctl errors to stdout

It was noticed that hoverctl was not writing errors to the standard error stream. This bug has been fixed in v0.11.1.

More information on hoverctl

v0.11.0

Its been a month in the making. v0.11.0 is here with a bevy of improvements, building on already existing functionality.

Request matchers (including support for XML and JSON matching, XPATH, JSONPATH and regex)

Originally, Hoverfly only supported "recordings". An incoming request had to exactly match a stored request for a response to be returned.

Since the introduction of templates, it was clear that the way we match requests in Hoverfly needed to improve. v0.11.0 brings the first phase of those improvements.

Recordings are now treated like templates, meaning it is even easier and simpler to modify a captured request and turn it into a looser fitting template.

Instead of defining request field values exactly, we have introduced a new set of matchers. Each request field (except headers) will now take an object of matchers. These matchers have allowed us to add new ways of matching data. For example, it is now possible to match a request body based on an XPath expression.

This change has resulted in the Hoverfly schema being updated to v2. When importing an older v1 schemaVersion simulation, Hoverfly will automatically upgrade it to v2.

More information on request matchers

Caching requests

Previous versions of Hoverfly used a cache to store request recordings. The issue with this was you could not cache request templates, meaning a slower response time than with recording.

v0.11.0 has changed the way the cache works. Now, responses are stored against incoming requests meaning Hoverfly should now perform consistently regardless of how "loose" your simulation is.

The cache will be reloaded from your simulation every time you enter simulate mode. We have also added API endpoints for both viewing the state of the cache as well as flushing it.

More information on the logs API

Capture mode and headers

We've changed capture mode so now by default, when you capture requests, request headers ill not be captured. This is due to the way the cache works with hashes of the request. Now, if you want to capture headers, you will need to specify them when setting capture mode.

In hoverctl, we have added two new flags to hoverctl mode which are

hoverctl mode capture --headers "User-Agent,Content-Type,Authorization"
hoverctl mode capture --all-headers

More information on hoverctl

If you are using HTTPS/TLS traffic and have not seen our last release, v0.10.3, we strongly advise looking as it provides instructions on how to replace the expired certificate.

v0.10.3

Greetings, its been a while. We've been very busy preparing v0.11.0 of Hoverfly, which will be coming very soon.

This is an important release for those using HTTPS/SSL traffic with Hoverfly

Updating core/cert.pem

Today (24th March, 2017), the certificate that ships with Hoverfly for HTTPS/SSL traffic expired. This has prompted a new certificate which now has a 5 year expiry.

As a result of this, from v0.10.3 onwards, you will need to remove the current certificate from your certificate truststore and add the new one.

If you cannot or do not want to update your version of Hoverfly, you can work around this by generating new certificates with Hoverfly and setting them manually when starting Hoverfly.

For more information on HTTPS/SSL

hoverctl version

We have updated hoverctl version so it will now report the versions of both hoverfly and hoverctl binaries

For more information on hoverctl commands.

v0.10.2

Its time for a small Hoverfly update. Over the past week, we've been fixing bugs and adding features.

hoverctl errors

With the change to using spf13/cobra, we introduced a bug where "index out of range" errors would be printed when parameters were missing from certain hoverctl commands. This has been fixed to print a nicer error message.

For more information on hoverctl

Authentication on the proxy

We have expanded authentication within Hoverfly. Originally, turning on authentication would only take affect on the API, requiring a JWT token to communicate with Hoverfly. v0.10.2 now introduces authentication to the Hoverfly proxy.

For more information on authentication

Authentication for in-memory Hoverfly

As part of the changes to authentication, we have also enabled the ability to use authentication with an in-memory database. Previously you were restricted to only being able to enable authentication when using BoltDB.

For more information on authentication

Advanced tutorials

With this release, we have created a new section in the documentation for "advanced tutorials". This section includes guides that show how to use Hoverfly in more complex situations. If you have any issues or misunderstandings around the documentation, feel free to raise issues. We are always striving to improve our docs!

For more information on advanced tutorials

v0.10.1

Its been a month since the last release so we've got v0.10.1 ready for you. Since the last release, we've been busy improving the functional tests around Hoverfly and hoverctl, moving hoverctl over to use Cobra as well as fixing a few bugs and adding a new feature.

Query parameter ordering using templates

In v0.10.0, we fixed a bug which meant that query parameters were being compared based on order, meaning that rearranging query parameters would cause matching to fail. Sadly, this fix was only to request recordings. This has now been applied to both templates and recordings, fixing the issue permanently.

For more information on templates

Request bodies on POST and PUT requests

During the refactor of v0.10.0 a bug was introduced that caused the request bodies on POST and PUT requests to be unreadable due to the preparation of bytes before being attached to a HTTP request. This has now been resolved.

Upstream proxy

Thanks to the work of @Bruno-DaSilva, we now have the ability to run Hoverfly behind of another proxy. This opens up the possibility of using Hoverfly in environments where using a proxy is required to communicate outside of your network. Currently, this upstream proxy feature only works with unauthenticated proxies, though we are looking to address this soon.

For more information on setting an upstream proxy

Hoverctl rework

Having moved over to Cobra, we have reorganized the codebase, removed irrelevant commands (delays and templates) and produced more descriptive help text for each of the hoverctl commands.

For more information on hoverctl commands

v0.10.0

It's a new year, so here's a new version of Hoverfly! This version has been in the works longer than expected but as a result, this release is even better than we initially intended.

We had the opportunity to rewrite several parts of the codebase. Some of this time has been spent on refactoring and some has been spent on improvements. Because of this, we've bumped the version number up to v0.10.0.

Alongside the new release, we have rewritten the Hoverfly documentation and are now publishing it to ReadTheDocs. We hope that these changes will make it easier to get up to speed with Hoverfly quickly.

Stick around and let me tell you about the changes.

Middleware API change

We had the opportunity to look into middleware and how its managed within Hoverfly. One of the initial limitations was that the middleware had to be on the host which Hoverfly was running.

This was okay for local development work but as soon as you tried to use a remote Hoverfly instance or even the Hoverfly docker image, setting middleware became difficult.

We have addressed this by changing how you set middleware. Instead of specifying a command, the API now accepts three values: "binary", "script" and "remote". "Binary" is the binary process Hoverfly should run. This should be located on the host machine. As for "script", rather than sending a path to a file, Hoverfly will now accept the contents of the script. Once the script has been received, Hoverfly will write it into the temporary directory, deleting it when it is no longer needed. The "remote" field is for supplying a URL for middleware which can be accessed via HTTP.

This change in API has been reflected in hoverctl. When setting middleware with hoverctl, you are now expected to use the new middleware flags, --binary, --script, --remote.

hoverctl middleware --binary python --script my_middleware.py

For more information on setting middleware: Using middleware to simulate network latency

Changing database default and new hoverctl flag

For a while, there has been an inconsistency between Hoverfly and hoverctl. Starting Hoverfly as a process would default to writing data to the BoltDB request.db file. Starting a Hoverfly process with hoverctl would set Hoverfly to use an in-memory database. This caused confusion for some users. By default, both Hoverfly and hoverctl will now start Hoverfly processes with an in-memory database.

In conjunction with this change, we have also introduced a new --database flag to hoverctl for the times when you do need to persist data with BoltDB.

For more information on hoverctl: hoverctl commands

Consistent HTTP errors from Hoverfly

Through the refactoring, we have standardised the HTTP errors returned by Hoverfly. Previously, when using Hoverfly as a proxy, there were several different style errors that could occur. Now, whenever Hoverfly throws an error, it will return a response with a 512 error code and a nice description of the error. Each error that Hoverfly returns will also be logged, which will be either in the standard out of the Hoverfly process, or captured by hoverctl so they can be viewed with hoverctl logs.

Ordering HTTP request queries

We noticed a bug regarding recorded requests with query parameters. When the HTTP request was being converted in to an internal Request object, there was no sorting on the query parameters. As a result of this, it was possible to record the same request multiple times by changing the order of the query parameters. This version of Hoverfly fixes this by always sorting the query parameters into alphabetical order when converting a HTTP request to a Request object.

For more information on capturing requests and responses Creating and exporting a simulation

v0.9.2

I remember v0.9.1, it felt like it was less than a week ago.

It was, but we have another new version of Hoverfly already! This new version contains a few usability fixes as well as a fix to a bug.

Locked in memory cache bug

This week, we discovered a bug. This bug was only noticeable when running Hoverfly with the in memory database. The problem was, if you made a request to the cache and it failed, the cache would remain locked, making it impossible to ever read or write from the cache without resetting Hoverfly. This has been fixed up now and the in memory cache should not get stuck in a locked state any more.

Pretty JSON

When exporting data to a JSON file with hoverctl, the file it would write would always have the simulation JSON on one line, making it hard to read. Now, hoverctl will write JSON in a more formatted way, making it easier to read your simulations.

For more information on exporting simulations Exporting captured data

Invalid simulation parsing

With v0.9.0, we introduced a new schema for the simulation. This schema is slightly more complicated than the previous. One of the issues we found was that when creating your own simulation files, Hoverfly gave no validation on this schema. Now, when importing a simulation file, if it doesn't match the expected schema, it will now report the error.

For more information on simulations Managing simulation data

hoverctl start reports ports

Another small piece of feedback we had was that it wasn't always clear which ports Hoverfly had started on when using the hoverctl tool. We've updated hoverctl to now log the admin and proxy ports when starting an instance of Hoverfly.

For more information on hoverctl Hoverctl reference

v0.9.1

What better way to celebrate Cyber Monday with the Cyber Monday Hoverfly Deal! Download Hoverfly, and get hoverctl, absolutely free!

Its been two weeks since the release of Hoverfly v0.9.0 and we are ready for the next release. This version features many smaller changes to hoverctl to make it easier to use.

hoverctl destination

We've introduced the destination command to hoverctl. This will return the destination being used by the running Hoverfly instance. Much like the other hoverctl commands, you can also use this to set the destination. Also, Hoverfly will now match the destination against full URLs, both destination and path.

hoverctl destination '<regex>'

For more information on setting the destination Filtering destination

hoverctl support for custom certificate and key files

Previously, if you wanted to use a certificate and key which were different than the defaults, you would have to launch Hoverfly manually. With this version, we've introduced the --certificate and --key flags to hoverctl.

hoverctl start --certificate /path/to/certificate.pem --key /path/to/key.pem

For more information on new flags Hoverctl flags

hoverctl can disable TLS

Much like the certificate and key values, if you wanted to disable TLS verification on Hoverfly, this could only be done by providing a flag to the Hoverfly binary. Hoverctl now supports this functionality when starting an instance of Hoverfly.

hoverctl start --disable-tls

For more information on new flags Hoverctl flags

New config for hoverctl config.yaml

All of these new flags introduced in this version of hoverctl have been included in the config.yaml. By default, hoverctl will always check the config.yaml and use any configuration to start Hoverfly. If for example, you always disable TLS verification, instead of providing the flag each time, you could just edit the config file to include hoverfly.tls.disable: true.

For more information on new flags Hoverctl configuration

New config command

If you are unsure of the configuration that hoverctl is using, we've added a new command to find out. Calling the config command in hoverctl will now report the location of the config.yaml that it is using as well as printing the configuration that is being used.

hoverctl config

For more information on new command Hoverctl config

v0.9.0

Its been a while but we are back! Hello! There have been some big changes to Hoverfly. A lot of the past month has been spent implementing the groundwork needed for us to continue to develop and evolve Hoverfly with more confidence of backwards compatibility.

With this release, we are deprecating the old API. We believe the new V2 API covers all of the required functionality. The old API is still accessible, but it will be removed at some point in the future.

With this release out of the way, we plan to go back to smaller, more regular releases in the future.

Revised schema

Over time, the input files required for Hoverfly have grown. Initially, there was a records file containing requests and responses. We then introduced templates and then delays. v0.9.0 simplifies all of this and now has a new schema for simulations. This schema contains all everything Hoverfly needs. The simulation schema now has the recorded requests and respones, the templates and the delays. In the future, any new forms of data we support in Hoverfly will be delivered via this schema.

For more information on the new schema: Managing simulation data

V2 API

We've been hard at work on building out a new RESTful API for Hoverfly. This new API is versioned, which should allow us to make changes more easily without breaking backwards compatibility. As part of the new API, we've created a new endpoint for getting simulations with the new schema.

For more information on the new API: API reference

v0.8.2

Happy National Ampersand Day! What better way to celebrate today by showing your appreciation for the ampersand & checking out the latest release of Hoverfly. Its a small release today with a new feature and a bug fix. But before that, I would like to warn you about upcoming changes.

Recently we've been adding features and expanding the functionality of Hoverfly. This has been fantastic but as a result, we've slowly made it more complicated to use with different sets of data required with their own import and export steps. We've been starting to work on v0.9.0 which plans to change this and simplify both request templates and delays. To make these changes, we're are going to be making breaking changes and creating a new version of the API, v2. I'm keeping a wiki page for breaking changes so that we can clearly communicate these breaking changes ahead of time

For more information on these breaking changes: Upcoming breaking changes

Wildcards in request templates

The introduction of request templates was a great feature. It allowed for more flexible simulations. We have now expanded upon this to allow you to make your new simulations even more flexible. Instead of specifying a complete string to match against, its now possible to include an asterisk to substitute characters, similar to using a UNIX command line. This can be used in any of the fields available in a request template.

For more information on wildcards in request templates: Managing simulation data

Saving redirects

A bug was found when trying to create a simulation of an OAuth2 log in. When the log in occurred, we spotted that the redirects were not being stored. Further investigation found that Hoverfly was executing the redirects and then returning a response as if the redirect never happened. This bug has been fixed, and now Hoverfly will return a redirect without executing it.