Entry

Definition

A Hurl file is a list of entries, each entry being a mandatory request, optionally followed by a response.

Responses are not mandatory, a Hurl file consisting only of requests is perfectly valid. To sum up, responses can be used to capture values to perform subsequent requests, or add asserts to HTTP responses.

Example

# First, test home title.
GET https://acmecorp.net

HTTP/1.1 200
[Asserts]
xpath "normalize-space(//head/title)" == "Hello world!"

# Get some news, response description is optional
GET https://acmecorp.net/news

# Do a POST request without csrf token and check
# that status code is Forbidden 403
POST https://acmecorp.net/contact
[FormParams]
default: false
email: john.doe@rookie.org
number: 33611223344

HTTP/1.1 403

Description

Options

Options specified on the command line apply to every entry in an Hurl file. For instance, with --location option, every entry of a given file will follow redirection:

$ hurl --location foo.hurl

You can use an [[Options] section] to use option only for a specified option. For instance, in this Hurl file:

GET https://google.fr
HTTP/* 301

GET https://google.fr
[Options]
location: true
HTTP/* 200

GET https://google.fr
HTTP/* 301

The second entry will follow location (and so we can test the status code to be 200 instead of 301).

You can use it to logs a specific entry:

# ... previous entries

GET https://api.example.org
[Options]
very-verbose: true

HTTP/* 200

# ... next entries

Requests in the same Hurl file share the cookie storage, enabling, for example, session based scenario.

Redirects

By default, Hurl doesn't follow redirection. To effectively run a redirection, entries should describe each step of the redirection, allowing insertion of asserts in each response.

# First entry, test the redirection (status code and
# Location header)
GET https://google.fr

HTTP/1.1 301
Location: https://www.google.fr/

# Second entry, the 200 OK response
GET https://www.google.fr

HTTP/1.1 200

Alternatively, one can use --location option to force redirection to be followed. In this case, asserts are executed on the last received response. Optionally, the number of redirections can be limited with --max-redirs.

# Running hurl --location google.hurl
GET https://google.fr
HTTP/1.1 200

Finally, you can force redirection on a particular request with an [Options] section and the --location option:

GET https://google.fr
[Options]
location: true
HTTP/1.1 200

Retry

Every entry can be retried upon asserts, captures or runtime errors. Retries allow polling scenarios and effective runs under flaky conditions. Asserts can be explicit (with an [Asserts] section), or implicit (like headers or status code).

Retries can be set globally for every request (see --retry, --retry-interval and --retry-max-count options), or activated on a particular request with an [Options] section.

For example, in this Hurl file, first we create a new job, then we poll the new job until it's completed:

# Create a new job
POST http://api.example.org/jobs

HTTP/* 201
[Captures]
job_id: jsonpath "$.id"
[Asserts]
jsonpath "$.state" == "RUNNING"


# Pull job status until it is completed
GET http://api.example.org/jobs/{{job_id}}
[Options]
retry: true

HTTP/* 200
[Asserts]
jsonpath "$.state" == "COMPLETED"

4.1 KiB Raw Blame History