[Options] section options and command line options

[jcamiel]

[Options] section can be used to set an option on a particular request inside a Hurl file:

GET https://foo.com
[Options]
proxy: server-a
HTTP 200

GET https://foo.com
[Options]
proxy: server-b
HTTP 200

GET https://foo.com
HTTP 200

Question: what do you prefer to be the final value of the option when there is an option on the command line and in an [Options]section ?

With this file test.hurl

GET https://foo.com
[Options]
proxy: server-a
HTTP 200

GET https://foo.com
[Options]
proxy: server-b
HTTP 200

GET https://foo.com
HTTP 200

With this command line:

$ hurl --proxy server-c test.hurl

[jcamiel]

Don't hesitate to add comments!

[lambrospetrou]

In my opinion, it depends if we consider the Options in the Hurl file more prone to overrides.

What are the users using more often as override, the Options in the file, or the CLI argument.

For example, in the AWS CLI (see docs), the CLI arguments have the highest precedence, and local configuration files or env variables are lower. But, hardcoded credentials in any code using the AWS SDK also has higher precedence than any of these options.

To me, the Options in the hurl file is closer to the hardcoded credentials in the source code, so their precedence should probably be higher.

[fabricereix]

Here is an example for which the current behavior might not seem consistent.

Let's take the following Hurl file test.hurl

GET https://localhost:8001/hello

$ hurl test.hurl
error: HTTP connection
  --> test.hurl:1:5
   |
 1 | GET https://localhost:8001/hello
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (60) SSL certificate problem: self signed certificate in certificate chain
   |

We can also explicit set the insecure option to its default value in another Hurl file test2.hurl.

GET https://localhost:8001/hello
[Options]
insecure: false

It has exactly the same semantics, and therefore has the same behaviour.

$ hurl test2.hurl
error: HTTP connection
  --> test2.hurl:1:5
   |
 1 | GET https://localhost:8001/hello
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (60) SSL certificate problem: self signed certificate in certificate chain
   |

So far, so good.
Now, what about setting the CLI option --insecure so that the request can be run?

With the first Hurl file, it works but not with the second.

$ hurl --insecure test.hurl
Hello World!

$ hurl --insecure test2.hurl
error: HTTP connection
  --> test2.hurl:1:5
   |
 1 | GET https://localhost:8001/hello
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (60) SSL certificate problem: self signed certificate in certificate chain
   |

[lambrospetrou]

But this is correct behavior isn't it? At least it makes sense to me.

In the second case we explicitly say I don't want insecure connections. So, regardless of the CLI argument, it will use that. The fact that this specified value happens to be the default as well doesn't matter.

Maybe I misunderstood what you expected?

[fabricereix]

My mental model is not setting the option is the same as setting to its default value.
For example, the insecure option is either true or false.
In yours, it's like it has 3 values not set, true or false, which could also make sense.

[lambrospetrou]

Yes correct. "Not set" is an explicit option (the 3rd option you mention). It means use the default, or whatever value is provided in a lower priority mechanism.

Imagine that in an imaginary future there is another mechanism to provide options at the directory level.

Then you have:

1. Inline Options
2. Directory file options
3. CLI options
4. Default options

Any option iterates through this list until it finds a value.

[fabricereix]

We have even environment variables (HURL_xxx, 'http_proxy', ...) that we need to take into account

[lambrospetrou]

Exactly. I believe it's key to define a priority list of the mechanisms and then it's just a matter of picking the value of the mechanism with the highest priority.

[fabricereix]

I'm adding another example relating to the color.

If I want to run a bunch of Hurl files in my terminal w/o color, I would expect that I could use the environment variable NO_COLOR,
rather than modifying every entry that contains the color option (I assume we have one).

Also, when the error/output stream is redirected (this is probably always the case in a CI), the color is usually disabled (jq or Hurl default behavior).
I expect that whatever the input Hurl files.

[lepapareil]

Let's go back to the original example and apply it to a real-world example.
I have a Hurl file that tests:

• availability of https://hurl.dev needing a proxy
• availability of https://local.intranet not needing a proxy

Team's members/executors want to be able to run it on their workstations from different proxies:

• from company promises in Paris or Berlin on intranet = intranet-proxy
• from teleworking on vpn = vpn-proxy
• from supervisor jobs in Ci/Cd on private network = bot-proxy

I choose to define bot-proxy as the default proxy in commited file:

GET https://hurl.dev
[Options]
proxy: bot-proxy
HTTP 200

GET https://local.intranet
[Options]
HTTP 200

What is the best solution to achieve different human team members needs ?

• hard changing [Options] with the <proxy for hurl.dev>
• execute hurl file.hurl
• revert changes before commiting (we can not gitingore this file as it can be updated)

or

• execute hurl --proxy <proxy for hurl.dev> --noproxy local.intranet file.hurl

The second appears more natural and less complex to me.

We must differentiate between hurl file writer and hurl file executor. As the executor, if I intentionally use the --proxy or --noproxy, it's because I naturally expect it to override proxy value for this execution (have to comply with my exec env constraints), why else would I write it ?

In this example, if I had choosen the use vpn-proxy as default proxy, then i should have to script an infile sed before executing hurl with my automated supervisor instead of just executing hurl with --proxy and --noproxy option.

And to fully address the original problem, if I wanted to test another url that needs different proxy, still having default values, then I will probably choose to use a variable instead of hard coding proxy value for each request :

GET https://hurl.dev
[Options]
variable: proxy1=bot-proxy
proxy: {{proxy1}}
HTTP 200

GET https://local.dmz
[Options]
variable: proxy2=dmz-proxy
proxy: {{proxy2}}
HTTP 200

GET https://local.intranet
[Options]
HTTP 200

And then:

• execute hurl --variable proxy1=<proxy for hurl.dev> --variable proxy2=<proxy for local.dmz> --noproxy local.intranet file.hurl

Again, expecting the client variable to override the variable infile. The variable-based solution is even more preferable if there are not just 1 but several hurl files with this problem. Imagine having to replace inline hundreds of files, depending of the executor env ?

Finally, isn't the question = Do we want to be able to have default values and final values (default commited on file, final by execution) or just final values (final value commited on file and not overridable by cli) ?

[lambrospetrou]

I agree with this reasoning, but it seems that you consider the source file to be the "static input" and the CLI command to be the variable user-controlled input.

In my comment I mentioned this:

What are the users using more often as override, the Options in the file, or the CLI argument.

I guess it depends on the setup of each team. If the CLI command is the same across all their CI/CD pipelines and tooling, their "user-controlled input" is the source file, so the values in the file should have higher priority.

In the scenario you mentioned above, the CLI command is the user-controlled input, and as you pointed out you prefer to have that taking higher priority.

This can go both ways, and both are correct, depending on how you order these. Do you have data on how users use Hurl right now, maybe from discussions with them or GH issues?

I choose to define bot-proxy as the default proxy in commited file:

This is from your example above. You mention "default proxy" here, but in my opinion anything "explicitly" specified in the final source code is actually the value that I want to use, not the default.

Your variables example is actually nice. If there is a way to define "default variable" values and allow the CLI to provide overrides, then you can solve all use-cases.
But even then, how do you order variables having a default value in the file, and then set through the response of a request, but also having a CLI provided value.

It's back to the "precedence order" between the mechanisms to set values.

I actually believe having a way to define variable defaults, and making it possible to override them either dynamically or with the CLI (Dynamic value inferred at runtime > cli value > default in file), addresses most cases discussed so far.

[luolong]

Hello, just stumbled upon this discussion because I was trying to work with variables myself and it does not really matter which you consider "user controlled input" — they both are user controlled input and the difference is just the timing of "when" you apply your options.

In my case, I want to configure some parts of the URL path, so that I could test various different responses based on some identifier.

In the case of local development environment, I execute my hurl files from command line and in the simplest case scenario I might simply want to execute it without needing to specify any options on the command line at all.

This is the entry level definition and my hurl file should work out of the box in local environment without any additional mandatory arguments.

Then for example, I start up a local server and I want to override all requests to base url to localhost:8080. I define and environment variable for HURL_baseurl and keep executing the hurl file without any command line overrides.

Now, I want to override an identifier on the api path per request basis to test various combinations of my local dev environment, so now I add command line option --variable foo=bar and change it on each execution as I see fit.

For my CI script I might want to run those hurl file with a fixed set of variable values, so I create a variables file (and even commit ti to source control) and execute hurl scripts using --variables-file. Or maybe event with an environment specific .env file.

In the end, the whole point is to be able to parametrize the hurl command at execution time.
HURL already has all the tooling necessary to fix variable values for different environments, so there is no need to go inventing new ways to add complexity to the configuration. What hurl already has is just fine. Just give us ability to override defaults in the file and we are happy.

[lepapareil]

Using a mechanism like variable expansion could be a reasonable solution to meet all our needs:

• Keep hurl file the highest priority
• Allow to set variabilized default values (but not forced)
• Allow to override variabilized default values from cli (but not forced)

example, with this test.hurl file:

GET https://url1
[Options]
proxy: {{proxy1:=infile-proxy1}}
HTTP 200

GET https://url2
[Options]
proxy: {{proxy2:=infile-proxy2}}
HTTP 200

GET https://url3
[Options]
HTTP 200

will result on:

exec	result
hurl test.hurl	url1 -> infile-proxy1 url2 -> infile-proxy2 url3 -> no proxy
hurl test.hurl --proxy cli-proxy	url1 -> infile-proxy1 url2 -> infile-proxy2 url3 -> cli-proxy
hurl test.hurl --proxy cli-proxy --variable proxy1=cli-proxy1 --variable proxy2=cli-proxy2	url1 -> cli-proxy1 url2 -> cli-proxy2 url3 -> cli-proxy

[lambrospetrou]

Yeap, love this!