hoverfly

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.

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.

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

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

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

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.

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.

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

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

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

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

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

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

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.

Greetings one and all. It’s Friday and Monday is a public holiday in the UK. The weather is looking good and Hoverfly is looking better. Here is v0.8.1 and the changes it introduces.

“RequestResponsePairs” and “RequestTemplateResponsePairs”

For this release we have focused on refactoring, specifically around how Hoverfly simulation data is managed. In the past, we have referred to this data with different names - this hasn't always been clear.

From v0.8.1 we have defined a new standard for naming. Gone are the days of generic “payloads”. Requests and responses are now formed together to become RequestResponsePairs. We plan on updating the documentation to make sure that we always refer to simulation data now as pairs.

Along with this change, we have been refactoring data importing and exporting. Previously, if you wanted to make use of request templates or delays, you would have to create new files. We feel that this is unnecessary and that all data pertaining to a simulation should live in one file. This release allows request templates to be added to your normal simulation recordings.

For more information on request response pairs: Managing simulation data

Headers in webserver mode

A bug was discovered in webserver mode in which headers would not be included in the response. We have patched this up and written tests around it.

For more information on webserver mode: Server type

Matching on body with request templates

Another bug was discovered while using request templates. Despite being an option, you could not match on the request template body. This has been fixed in this version, again with tests around it.

For more information on request templates: Matching requests

It's that time where we make a Hoverfly release! It's my favourite time as I get to review all the exciting work we've put into Hoverfly.

Partial matching with request templates

Before v0.8.0, matching within Hoverfly on requests was very strict and a bit brittle. You couldn't match a request just on the destination and a header - such as the Authorization header. Before, you had to capture every request that you wanted to match against using the same destination and header. v.0.8.0 changes that. We've introduced the ability to match on certain key elements of the request. You want to match on any POST request? Now you can. You want to match any request for the favicon regardless of destination? Now you can.

This is a powerful feature that can help make simulations more flexible. We are very excited about this feature and has helped us already.

For more information on request templates: Matching requests

Changing middleware via hoverctl

In our continuous effort to move towards making hoverctl the wrapper for managing Hoverfly processes, we introduced the ability to set middleware via hoverctl. This now means that is no longer necessary to start Hoverfly with middleware. Using the hoverctl, you can now set it during run time, making it easier than ever to swap out middleware as and when you need it.

For more information on setting middleware via hoverctl: Hoverctl

Remote execution of middleware

As part of the middleware change, we've been curious as to how you could set middleware on remote machines running Hoverfly, especially without needing SSH access to the box. Our solution was to introduce the ability to run middleware as a web service. Instead of providing Hoverfly a command and a file to execute, you can now provide a URL instead. Building remote middleware is incredibly easily and using serverless technology like AWS Lambda makes working with middleware even easier.

For more information on remote execution of middleware: Using middleware

Its been less than a week but its time for another release! Since the last release, we've been listening to feedback and implemented some changes to make Hoverfly just that little bit better than it already was.

URL and HTTP Method Matching on Response Delays

In v0.7.0 we introduced response delays, a great way to introduce delays into your simulations. With v0.7.1, we've expanded the functionality of response delays. Originally, you could only apply delays based on host. We've expanded it. You can now apply delays based on the full URL path and HTTP methods. This change allows for your response delays to be much more flexible.

This change means that the "hostPattern" field in your response delays will now need to be "urlPattern". Response delays will no longer work with "hostPattern"

For more information on response delays: Simulating service latency

Logging in Hoverctl

Another big feature of v0.7.0 was the introduction of hoverctl, the command line tool for interacting with both Hoverfly and your simulation data inside it. One of the biggest drawbacks to using hoverctl was that if you started an instance of Hoverfly using it, you lost access to the logs. This is no longer the case. We've added logs to hoverctl. You can how call hoverctl logs and get access to the Hoverfly logs. Need to tail the logs and follow them in real time? Not a problem, use the --follow flag.

For more information on hoverctl: hoverctl reference

--version

Both Hoverfly and hoverctl did not have --version flags, making them noncompliant with POSIX guidelines. v0.7.1 adds the --version flag to both Hoverfly and hoverctl.

For more information on hoverctl: hoverctl reference

For more information on Hoverfly flags: Hoverfly flags and environment variables

Hoverfly on Homebrew

Its been a requested feature for a while. Hoverfly is now available using Homebrew. This formula includes both Hoverfly and hoverctl. It is currently not available on homebrew-core and instead, resides in its own SpectoLabs tap.

If you want to install Hoverfly via Homebrew, please run brew install SpectoLabs/tap/hoverfly

Greetings!

We've been busy adding new features to Hoverfly, as well as developing tools to support the use of Hoverfly.

Hoverctl

We have created a new command line interface for Hoverfly. This allows for the management of local and remote Hoverfly instances. Using hoverctl, you can start and stop instances of Hoverfly, and manage Hoverfly data. You can export your simulations and then share them on SpectoLab, an API simulation repository for sharing and retrieving simulations. SpectoLab is currently in private beta, but you can request access. Hoverctl will still work with Hoverfly, even if you don't have access to SpectoLab.

For more information on hoverctl: hoverctl reference

Install script

Run the following command to install and set up Hoverfly and hoverctl:

curl -o install.sh https://storage.googleapis.com/specto-binaries/install.sh && bash install.sh

Add response delays (without using middleware)

We noticed that a common usage of middleware was to introduce response delays to simulations, so we've added the ability to set response delays in Hoverfly without the need for middleware. Hoverfly uses a regex to match against a request, opening up the opportunity to add different delays to different hosts.

For more information on response delays: Simulating service latency

Run Hoverfly as a webserver

We also got feedback that running Hoverfly as a proxy was not always desirable (or even possible), especially when simulations have been recorded previously and all you need is simulate mode. Now Hoverfly can run as a webserver, allowing you to point your application directly at Hoverfly without having to configure a proxy. Currently this only works via HTTP.

For more information on running Hoverfly as a webserver: Server type

Other stuff

Also, this release introduces a new repository structure. This was mainly due to the introduction of hoverctl. The end result is a much tidier repository that makes it easy to run different suites of functional tests.

Its time for a new minor version of Hoverfly.

Why have we gone from v0.5.17 to v0.6.0?

We made a slight change to the structure of payloads. We added a new field to indicate whether or not the body needs to be base64-encoded. The reason being that during the export and import process, any binary body data in a response would get lost due to being parsed to Unicode characters.

You can find out more about this change here. If you are trying to read or write binary data to the response body in your middleware, find out more here.

In this release, we have also introduced Ginkgo and Gomega to help us functionally test Hoverfly, which in turn has enabled us to start to modularize the codebase.

Next version of UI and improved documentation