{ "fruits": [ "Apple", "Lemon", "Strawberry" ] }

By the spec, the JSONPath query $.fruits[0] should return a list of one element ["Apple"]. As the result list has only one single element, Hurl JSONPath query returns the string “Apple”. So we’re able to write this Hurl file:

GET https://example.org/captures-json HTTP 200 [Asserts] jsonpath "$.fruits[0]" isString jsonpath "$.fruits[0]" == "Apple"

We’ve been doing this coercion since the very first Hurl version but some people prefer not having this (to have similar results as https://jsonpath.com). We’ve heard you! So, in Hurl 8.1.0, we’ve added a --no-jsonpath-coercion option. It can be set in the new Hurl configuration file, on command line or using the env variable HURL_NO_JSONPATH_COERCION=true, or per request in an [Options] section. Using this option, JSONPath queries always return a list:

GET https://example.org/captures-json [Options] no-jsonpath-coercion: true HTTP 200 [Asserts] jsonpath "$.fruits[0]" isList jsonpath "$.fruits[0]" count == 1 jsonpath "$.fruits[0]" nth 0 == "Apple"

Other New Options

Hurl 8.1.0 adds some new options:

Let’s say you don’t want any User-Agent nor Accept HTTP header request, you can use --no-header option:

$ hurl --no-header user-agent --no-header Accept foo.hurl

It also works on a specific request:

This request will send a default User-Agent header

GET https://example.org

This request will NOT send a User-Agent header

GET https://example.org [Options] no-header: User-Agent HTTP 200

And can be configured with environment variable HURL_NO_HEADER:

$ export HURL_NO_HEADER="user-agent|Accept" $ hurl foo.hurl

--fail-with-body to get HTTP response even with errors

By default, Hurl outputs the last response body only when the run succeeds; when there are errors (HTTP runtimes or asserts errors), Hurl doesn’t output any response. But sometimes the response body is necessary to explain failures. In Hurl previous versions, you can use --very-verbose or --output combined with --no-assert.

In Hurl 8.1.0, we add --fail-with-body option: this option changes Hurl’s default behavior when there are errors and output the HTTP response regardless of asserts / HTTP runtime errors. Like many other options, this option can be used as a command line option (hurl --fail-with-body foo.hurl), with environment variable (export HURL_FAIL_WITH_BODY=true), with Hurl configuration file, or per request with [Options] section.

$ hurl --fail-with-body foo.hurl { "slideshow": { "author": "Yours Truly", "date": "date of publication", "slides": [ { "title": "Wake up to WonderWidgets!", "type": "all" } ], "title": "Sample Slide Show" } } error: Assert failure --> foo.hurl:4:0 | | GET https://httpbin.org/json | ... 4 | jsonpath "$.slideshow.author" == "Someone" | actual: string <Yours Truly> | expected: string <Someone> |

--tls-min / --tls-max

--tls-min and --tls-max set the minimum and maximum allowed TLS version. Used together,, you can pin a given TLS version:

$ hurl --tls-min 1.3 --tls-max 1.3 tlscert.hurl

Fixed Bugs and Security Issues

Apart from these enhancements, we have received an unusual amount of security advisories from various contributors, over the last 6 months. It goes from parsing issues in JSONPath expression to malicious debug curl command and finally to our first official CVE!

Simply said, Hurl 8.1.0 is the Hurl version that has the largest number of bugs/CVEs fixed since the first public version. While analyzing and fixing them, we’ve reclassified some reports to “bugs”.

It’s rather obvious than the vast majority of these issues were written partly (if not totally) by LLM agents. Each issue takes time to digest, analyzing the automated prose is time-consuming, but we’ve found very few false positives. Almost all issues reported were indeed a defect in Hurl in some way or another. Sometimes CVEs were here and well reproducible but the reproduction sample didn’t even compile. Other times, a very super clear repro step was provided with a good source code analysis and possible fixes. Many reporters were first-time GitHub users!

We’re not at all in the same league as curl or the Linux Kernel, but still feel the raise and impact of automation by AI, like these projects. For security and bugs, we find it a big plus. For maintainers’ time, that’s another story...