Skip to main content

Would it be useful if #curl provided a default random variable?

Exploring this little idea here. Good? Bad?

github.com/curl/curl/pull/1381…


curl: offer a default 'random' variable by bagder · Pull Request #13813 · curl/curl

... and two new output functions: uuid and hex The variable holds a 128 bit semi-random value. Output it like {{random:hex}} to get it all as a 32 byte hex sequuence {{random:uuid}} shows it as a ...
GitHub
#curl
in reply to daniel:// stenberg://

Dr. Quadragon ❌
Dr. Quadragon ❌
• •

What's wrong with this?

```
uuid=$(uuidgen)
curl -x POST -h "$uuid" example.com
```

Example Domain

example.com
in reply to daniel:// stenberg://

iliazeus
iliazeus
• •
@drq as far as I understood, the original request's reasoning was something like automated testing of HTTP APIs. And in this use case, I think, we can assume that the user can install any missing utility they need.
@Dr. Quadragon ❌
in reply to daniel:// stenberg://

tokudan
tokudan
• •
That could be useful for avoiding frontend caches by adding a random parameter to the url. however generating a request-uuid in curl seems to be a mis-use to me, since the application needs to keep track of the uuid and curl shouldn't generate a new one if the request is repeated.
Or am I misunderstanding this part?
in reply to tokudan

daniel:// stenberg://
daniel:// stenberg://
• •
@tokudan I guess you then presume a particular use case for it, which might be right. I'm just brain-storming this based on someone's earlier questions. I don't really know what you would use it for... 😃
@tokudan
in reply to daniel:// stenberg://

tokudan
tokudan
• •
well, I read your linked discussion, which is about that exact use case.
in reply to daniel:// stenberg://

Stefan Eissing
Stefan Eissing
• •

@tokudan In the test cases, I use a url query param for request id using url globbing. That works fine in a test server, as it only has one client.

To correlate against a real server, you‘d need a more unique id, as it may serve many clients, either parallel or over time. (for parallel, timestamps in logs are of little help)

The proposed random would help when used together with the XFER_ID to make a likely globally unique request id.

@tokudan
in reply to daniel:// stenberg://

iliazeus
iliazeus
• •

I think that there either should be proper variable support a la Postman or other tools, or none at all.

Like, the next thing a user would probably want is to use two _different_ random variables (so no "holds fixed content"), but use both twice (so just returning different values each time won't satisfy this either).

Or a user (assuming the same HTTP API testing use case) would probably want to preserve these values in a sort-of session - to send several requests with the same random user id, for example.

in reply to iliazeus

daniel:// stenberg://
daniel:// stenberg://
• •
@iliazeus I don't know what "proper variable support" means, but curl supports variables properly.
@iliazeus
in reply to daniel:// stenberg://

iliazeus
iliazeus
• •

oof, sorry, should've read the man page before posting. In my defense, curl does _a lot_ of thing, and I don't know most of it.

I would still argue against the "holds fixed content" part - as far as I understood, you will be able to do --variable 'id={{random}}' to achieve that, and supporting several different random values in a request is still a useful thing.

in reply to iliazeus

daniel:// stenberg://
daniel:// stenberg://
• •
@iliazeus yeah, this is just a first shot to brainstorm and extract comments and thoughts. I don't think I've nailed the perfect implementation of it yet.
@iliazeus
in reply to daniel:// stenberg://

iliazeus
iliazeus
• •
or, seeing as the original issue was essentially about request ids, you can probably explicitly call it `request_id`? Then it would make sense that it holds fixed content, and can probably better explain the intention behind this feature.
This entry was edited (5 months ago)
⇧