Randomized data in HTTP requests

[artemmukhin]

Hello, and thank you for providing such a useful tool!

It has been working perfectly for me when I need to monitor a service using HTTP requests predefined in my .upptimerc.yml configuration. Now, I'm trying to set up a more complex logic for making HTTP requests with randomized data. I'm wondering if there's a way to achieve this, perhaps through scripted requests or special YAML commands?

[AnandChowdhary]

Unfortunately this is currently unsupported, but it sounds really interesting to me. Can you give me an example use case? Is it like ?cachebuster={date} or something more complex?

[artemmukhin]

Thank you for your prompt response! I appreciate your interest in exploring this feature further.

I have a few scenarios in mind where it can be helpful. For instance, randomized keywords could help simulate user searches, like GET /api/search?query={random_keyword}. Similarly, randomized numbers could simulate ID lookup, like GET /api/resource?id={random_number}. It would be valuable if the feature could potentially allow us to restrict the set of possible values to predefined values or ranges.

[artemmukhin]

@AnandChowdhary Could you possibly have a workaround in mind?

[AnandChowdhary]

Sorry for the delayed response! Unfortunately, nothing off the top of my head except for having a different scheduled workflow that updates your GitHub repository secrets and then using an environment variable as the URL with the randomized data, but I think it's better if we work on officially supporting it with some default variables, like you suggested random number, string, UUID, current timestamp, etc.

For example, the easiest would be to set it up so that any URL with a certain variable will add this data, like if you enter https://example.com/?ts=$DYNAMIC_RANDOM_NUMBER, we'll change it to https://example.com/?ts=42789289181.

Happy to accept a PR! You just have to add this support in https://github.com/upptime/uptime-monitor/blob/master/src/helpers/environment.ts#L1 and it should work if I'm not mistaken.

[artemmukhin]

Thank you for the explanation. I've opened a PR: upptime/uptime-monitor#226. I look forward to receiving further feedback!