Define an accessor to get the Host of the endPoint of HTTPRunner

[k2tzumi]

For example, it allows access to

httpRunners['req'].endpoint.Host

We would like to use it in a use case that identifies the domain of the cookie object

[k1LoW]

I have one question. Is this functionality necessary because the endpoint is set by environment variables, etc. and is not fixed to one?

In most cases, the endpoint should be known by the user executing the runn, so I am cautious about the need for this additional functionality.

---

I think httpRunners['req'].endpoint could be generalized as simply "allow access to the Runner's settings".

I am wondering if we should have access to the hostname in .Host or not.

Perhaps it would be better to make urlhostname() or url.Parse() a builtin-function.

[k1LoW]

I think httpRunners['req'].endpoint could be generalized as simply "allow access to the Runner's settings".

I think httpRunners['req'].endpoint would be easier to understand if it were a string entered by the user instead of *url.URL.

[k2tzumi]

Perhaps it would be better to make urlhostname() or url.Parse() a builtin-function.

The url function was incorporated and implemented.
#556 (comment)

Some redundancy remained in the area of including default values for environment variables.

I am wondering if we should have access to the hostname in .Host or not.

https://vscode.dev/github/k1LoW/runn/blob/vulnerability-check/http.go#L47

The current httpRunner was carrying it around as a url, so I was thinking of putting it directly into the store.

[k1LoW]

The url function was incorporated and implemented.
#556 (comment)

👍 Thank you!

Some redundancy remained in the area of including default values for environment variables.

I am wondering if this redundancy is acceptable.

The current httpRunner was carrying it around as a url, so I was thinking of putting it directly into the store.

I think that is fine if we only consider the endpoint 👍

However, if we were to add this functionality, I would want to raise the level of abstraction in the form of "access to Runner's settings".

At this point, it is debatable whether the parsed value should be set or not.

For example, we need to consider the following values.

• endpoint of HTTP Runner
• openapi3 of HTTP Runner
• key of gRPC Runner
• protos of gRPC Runner

[k2tzumi]

I am wondering if this redundancy is acceptable.

This use case is necessary when sending cookies, but if automatic cookie sending is supported as the next extension, the priority will be lowered.

However, if we were to add this functionality, I would want to raise the level of abstraction in the form of "access to Runner's settings".

Agreed.
As we see other use cases, let's consider interfaces that can be handled in a unified manner.