3 ms·

could also just do the request in javascript instead of needing a (presumably hosted) sandbox

• ultrafez 1y ago
  There are many types of request that cannot be made with client-side JS alone, but for those that can, the ability to send those requests client-side would be handy.
  • markerz 1y ago
    I think that 99.9% of CURL commands are copied from Chrome/Firefox's network inspector and are the simple "client-side JS" types. I also think it's weird to be so willing to let people run arbitrary CURL commands from your platform, without any billing or account verification. It feels ripe for abuse.
    • jasir 1y ago
      Even for commands that use the subset of cURL features that fetch supports, most requests to other domains (cross origin requests) wouldn't work anyway because the responses won't have the CORS[0] headers to allow being accessed from arbitrary websites. So running it client side would be infeasible for most requests. [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
      • darubramha 1y ago
        Exactly — this was one of the core constraints I ran into early on. CORS was a blocker for client side requests, I have a separate branch where this is integrated, maybe will add it alongside server side execution to let the person creating the curl decide whether they can execute on browser or server side.
• TheDong 1y ago
  curl supports many things javascript doesn't. Like http proxies, tls versions, and half the other flags