Open k2tzumi opened 1 year ago
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.
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
.
Perhaps it would be better to make urlhostname() or url.Parse() a builtin-function.
The url
function was incorporated and implemented.
https://github.com/k1LoW/runn/pull/556#discussion_r1264607087
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
.
The url function was incorporated and implemented. https://github.com/k1LoW/runn/pull/556#discussion_r1264607087
👍 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 Runneropenapi3
of HTTP Runnerkey
of gRPC Runnerprotos
of gRPC RunnerI 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.
For example, it allows access to
We would like to use it in a use case that identifies the domain of the cookie object