Possibility to specify a POST payload?
Hi, (Please let me know if there is a better way to make feature requests.) It would be great if it was possible to specify a payload for an HTTP POST when putting together an experiment. Thanks, Lars
Hi Lars, As you probably know, we really only do HTTP against anchors. Where would this feature come handy? Cheers, Robert On Wed, Sep 3, 2025 at 3:09 PM Lars Eggert <lars@eggert.org> wrote:
Hi,
(Please let me know if there is a better way to make feature requests.)
It would be great if it was possible to specify a payload for an HTTP POST when putting together an experiment.
Thanks, Lars
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi, On Sep 4, 2025, at 10:45, Robert Kisteleki <robert@ripe.net> wrote:
As you probably know, we really only do HTTP against anchors. Where would this feature come handy?
I was hoping to use Atlas to monitor reachability of TRR DoH servers (https://wiki.mozilla.org/Security/DOH-resolver-policy). I didn't know HTTP was limited to anchors; that would of course then not work. Thanks, Lars
You talking about DoH, that's https. https can partly covered by ssl-tests, they are possible to any target. Pur http tests to anchors are a little bot anachronistic .
Hi, On Sep 4, 2025, at 14:22, Thomas Schäfer <tschaefer@t-online.de> wrote:
You talking about DoH, that's https.
yeah. I'm probably showing my ignorance about Atlas here; it's been more than a decade since I did this last :-) I had assumed HTTP included HTTPS, because, well, it's 2025.
https can partly covered by ssl-tests, they are possible to any target.
I don't see "ssl-tests" in the web UI? (There is "TLS", but that has very few options.) Thanks, Lars
Hello, I think at the scale that RIPE Atlas operates, allowing HTTP(S) POST to any destination would be a recipe for abuse and exploitation. We probably don't want this. Lukas
Hi, On Sep 4, 2025, at 15:17, Lukas Tribus <lukas@ltri.eu> wrote:
allowing HTTP(S) POST to any destination would be a recipe for abuse and exploitation.
sure. Also note I didn't actually ask for "any destination". What about destinations you control, via an ACME-like proof-of-control? What about if you needed, say, 100M credits in your account to show a history of Atlas involvement. There's a bunch of ways in which risks can be mitigated. Thanks, Lars
Hi, The question of "free HTTP(S)" came up a few times before, I'm sure the archive has the details :-) There's also https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/ But in the big scheme of things "both sides" need assurances: the targets that they are not DDoSed, plus the hosts that their probes will not connect to, and fetch content from, questionable sites. The combination puts severe limitations on what we can do. Cheers, Robert On Thu, Sep 4, 2025 at 12:30 PM Lars Eggert <lars@eggert.org> wrote:
Hi,
On Sep 4, 2025, at 15:17, Lukas Tribus <lukas@ltri.eu> wrote:
allowing HTTP(S) POST to any destination would be a recipe for abuse and exploitation.
sure. Also note I didn't actually ask for "any destination". What about destinations you control, via an ACME-like proof-of-control? What about if you needed, say, 100M credits in your account to show a history of Atlas involvement. There's a bunch of ways in which risks can be mitigated.
Thanks, Lars
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
The main reason for this limitation is to protect probe hosts from prosecution in places that like to look at traffic of the population. Anchors are also less likely to be in people’s homes. Daniel On Thu 4. Sep 2025 at 14:54, Robert Kisteleki <robert@ripe.net> wrote:
Hi,
The question of "free HTTP(S)" came up a few times before, I'm sure the archive has the details :-) There's also https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/
But in the big scheme of things "both sides" need assurances: the targets that they are not DDoSed, plus the hosts that their probes will not connect to, and fetch content from, questionable sites. The combination puts severe limitations on what we can do.
Cheers, Robert
On Thu, Sep 4, 2025 at 12:30 PM Lars Eggert <lars@eggert.org> wrote:
Hi,
On Sep 4, 2025, at 15:17, Lukas Tribus <lukas@ltri.eu> wrote:
allowing HTTP(S) POST to any destination would be a recipe for abuse and exploitation.
sure. Also note I didn't actually ask for "any destination". What about destinations you control, via an ACME-like proof-of-control? What about if you needed, say, 100M credits in your account to show a history of Atlas involvement. There's a bunch of ways in which risks can be mitigated.
Thanks, Lars
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
participants (5)
-
Daniel Karrenberg -
Lars Eggert -
Lukas Tribus -
Robert Kisteleki -
Thomas Schäfer