Radar Agent Changelog

The following are released versions of the BlazeMeter API Monitoring Radar Agent:

Version Release Date
1.26 (current, latest) Oct 28, 2024
1.25 Oct 17, 2024
1.24 Sep 26, 2024
1.22 Jun 1, 2024
1.21 May 23, 2024
1.20 Apr 9, 2024
1.18 Sep 14, 2023
1.17 Aug 31, 2023
1.16 Jul 19, 2023
1.15 Jun 28, 2023
1.13 May 3, 2023
1.11 Jan 30, 2023
1.10 Nov 3, 2022
1.9 Oct 21, 2022
1.8rc Jun 13, 2022
1.6rc Jan 18, 2022
1.5rc Jan 5, 2022
1.4rc Dec 21, 2021
1.3rc Nov 11, 2021
1.2rc Oct 5, 2021
1.1rc Sep 30, 2021
1.0rc Sep 28, 2021

What's New in 1.26

Allow Radar Agents to Be Hidden from Other Users

A new --private flag has been added to the Radar agent so that it is only visible to the user that created it. This defaults to false, meaning that it is visible to every user in the team that the Radar agent is associated with.

For more information, see Command Line Flags / Configuration File Reference in Radar Agent Overview.

What's New in 1.25

Custom Proxy support in BlazeMeter

With the new custom proxy setup in Test Settings, you can now route requests through a designated proxy server. This feature allows you to test APIs from various environments, supporting both HTTP and HTTPS endpoints, and provides greater flexibility for running secure, network-routed tests.

For more information, see Managing Configuration with Environments.

What's New in 1.24

GraphQL support

BlazeMeter now supports GraphQL-based API testing and monitoring.

What's New in 1.22

Bug fix

Fixed a defect with the Radar Agent not reporting failures in a timely manner (TT-4108).

What's New in 1.21

Built using Golang 1.21.10

The Radar Agent is now compiled using Golang 1.21.10. This release of Golang fixes several vulnerabilities and addresses a regression related to HTTP/2 client performance.

What's New in 1.20

Radar Agent as a Container

A Docker image is now available for the Radar Agent so that it can be run as a container. Additionally, a Helm chart is available to help deploy your Radar Agent to a Kubernetes environment. For more information, see Running the Radar Agent as a Container.

Use system/OS-level provided certificates by default for HTTPS authentication

Starting with version 1.20, the Radar Agent now defaults to using system/OS-level provided certificates for HTTPS authentication. This behavior is identical to the use-system-certs command line flag or config file option being set to true.

Previously, the default value of the use-system-certs command line flag or config file option was false, which forced the Radar agent to download and use a certificate authority bundle from https://mkcert.org/generate for HTTPS authentication.

If you do not want to use certificates provided by your system/OS and would prefer for the Radar Agent to download and use a certificate authority bundle from https://mkcert.org/generate for HTTPS authentication, set the use-system-certs command line flag or config file option to false. For more information, see "Command Line Flags/Configuration File Reference" in Radar Agent Overview.

What's New in 1.18

Universal macOS binary of the Radar agent

You can now use a universal macOS binary to run on Intel or ARM processors.

Removal of 32-bit Windows and Linux Radar agents

The latest Radar agent supports 64-bit versions of Windows and Linux.

Standardized error handling for AWS S3 binary and multipart files

Fixed an issue to handle binary file S3 errors in the same way as multipart file S3 errors.

What's New in 1.17

Improved AWS S3 connection for binary file upload

Fixed an issue with connecting to AWS S3 services when performing a binary file upload from a test step.

What's New in 1.16

Support for binary file uploads and request chaining

We implemented a fix to support adding binary files and passing the decoded data to another request. For more information, see File Uploads and Multipart Requests.

Improved efficiency of HTTP connections

We addressed issues to improve speed and efficiency of HTTP connections with API Monitoring services.

What's New in 1.15

Local client authentication configuration options

To allow locally hosted certificate and key files to be used for client authentication in a two-way HTTP authentication setup (mTLS), we added several new command line flag or config file options:

  • cert - Client certificate file (PEM-encoded) for two-way HTTPS authentication

  • key - Client key file (PEM-encoded) for two-way HTTPS authentication

  • pass - Passphrase for client key file

Local client authentication configuration options will only be used if there is no client authentication enabled on the environment or request. If client authentication has been enabled on the environment or request, it will override any local client authentication configuration options. Refer to Environment Headers and Authentication for more information.

For more information, see Command Line Flags / Configuration File Reference in Radar Agent Overview.

Use system/OS-level provided certificates for HTTPS authentication

By default, the Radar agent will attempt to download and use a certificate authority bundle from https://mkcert.org/generate for HTTP authentication. If you need to use certificates provided by your system/OS, the use-system-certs command line flag or config file option is available.

For more information, see Command Line Flags / Configuration File Reference in Radar Agent Overview.


What's New in 1.13

Improved logging for configuration of trusted root certificates

Radar agent 1.13 adds improved logging for the configuration of trusted SSL/TLS root certificates.

  • If the cafile option is used, the Radar agent will validate and log the path of the CA bundle file

  • If the cafile option is not used, the Radar agent will log the progress of downloading the CA bundle file from https://mkcert.org/generate

  • If https://mkcert.org/generate can not be accessed, the Radar agent will use an embedded CA bundle file (as of April 10, 2023)

For more information, see Command Line Flags / Configuration File Reference in Radar Agent Overview.


What's New in 1.11

HTTP/2 Support

Radar agents starting with version 1.11 support the use of HTTP/2 when performing test requests. The HTTP version used when performing a test request can be configured in the environment behavior settings associated with your test. By default, HTTP/1 only is enabled.

For more details, see API Monitoring Test Behaviors.

Force h2c (HTTP/2 over cleartext)

Radar agents starting with version 1.11 support forcing the use of HTTP/2 over cleartext, also known as h2c. This is useful for test requests that use URLs with the HTTP scheme to access servers that expect HTTP/2 traffic. This can be configured in the environment behavior settings associated with your test. By default, this is disabled.

For more details, see API Monitoring Test Behaviors.


What's New in 1.10

Use of Hostname in HTTP/S Proxy Connection

When connecting through a HTTP/S proxy, the hostname of a test request URL is now properly used, instead of the IP address of the hostname resolved through DNS.


What's New in 1.9

Radar Agent Version Shown for Each Location

You can now view the radar agent version running on each of your locations, as shown in the following example:

radar agent version

To view the version of your radar agent, navigate to test Steps > Request.

Option to Disable DNS Pre-Check

You have the option to disable DNS pre-checks by using the disable-dns-lookup command line flag or config file option. See Radar Agent Overview and Radar Agent Connection Errors.

Built Using Golang 1.19.1

Radar agents are now compiled using Golang 1.19.1 to support security and infrastructure upgrades.

Removed Support for HTTPS Common Name field in X509 Certificates

The HTTPS Common Name (CN) field is no longer supported as of 1.9rc. For more information and how to work around the issue, see Radar Agent Support for HTTPS Common Name in X509 Certificates.


What's New in 1.8rcblob id

Support for TLS 1.3

The Radar agent now supports TLS versions 1.0 through 1.3.

Built Using Golang 1.16.15

In order to support TLS 1.3, Radar agents are now compiled using Golang 1.16.15.

Limitation of older X509 Certificates (1.8rc only)
Starting with Golang 1.15, support for X509 certificates that use a legacy CN (common name) field without a SAN extension entry (Subject Alternative Name) has been removed.
If the Radar agent encounters a HTTPS server that uses this type of X509 certificate, the following error will occur:
x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

You can allow X509 certificates without a SAN entry to be trusted by adding the value x509ignoreCN=0 to the GODEBUG environment variable and restart your Radar agent:
export GODEBUG=x509ignoreCN=0
.