[Mavvie]

This is pretty interesting. It's not like HTTP needs an intermediate representation, but since cURL is so ubiquitous, it ends up functioning as one. cURL is popular so people write tools that can export requests as cURL, and it's popular so people write tools that can import it.

[everforward]

The benefit of curl over raw HTTP is the ability to strip away things that dont matter.

Eg an HTTP request should have a client header, but they're typically not relevant to what you're trying to do.

curl is like an HTTP request that specifies only the parts you care about. It's brief, and having access to bash makes it easy to express something like "set this field to a timestamp".

[1vuio0pswjnm7]

Actually "Copy as cURL" adds much that is not required. In some cases this can be useful. However if all one cares about is what is actually needed to succesfully request a resource using HTTP, then "Copy as cURL" always includes too much. It includes "things that dont matter".

HTTP is more flexible than "Copy as cURL". There are things that can be done with HTTP that cannot be done with cURL.

[rootkea]

> There are things that can be done with HTTP that cannot be done with cURL.

Such as?

[1vuio0pswjnm7]

HTTP/1.1 pipelining.

(NB. I am not a developer. I am not writing software for other people. I do not profit from online advertising. I use a text-only browser with no auto-loading of resources and no Javascript engine; I never see ads. Been using HTTP/1.1 pipelining, which all major httpds support, outside the browser, daily, for many years. It works really well for me; I rely on it. As such, I am not the appropriate person with which to debate the relative merits of HTTP protocols for developers who profit from online ads served via "modern" web browsers.)

[incorrecthorse]

HTTP requests don't need to have any specific headers, and, if anything, curl will only add ones for you.

[everforward]

> if anything, curl will only add ones for you.

That's kind of what I mean. E.g. I believe curl will add a Content-Length header, which is good to have, but I don't need every example HTTP call to show me that.

To me a curl call is kind of shorthand for "these are the parts unique to this request, do the appropriate thing for general-use headers". If I see a raw HTTP request missing a Content-Length header (assuming it could use one), I don't know whether to assume that I do the normal thing, or whether the server ignores Content-Length, or perhaps if the server specifically errors out when it's set.

Vice-versa, if a raw HTTP request does have a Content-Length header, I'm not sure if that means it's required or just supported.

If I see a curl call specifying Content-Length, it sets off the "something weird is going on" bells in my head. Nobody specifies that in curl, so it's presence is odd and worth looking at.

[ricardo81]

But specific HTTP requests might. Like cookies, an accept header, or anything.

[Mavvie]

Thank you, I hadn't considered that aspect.

[tracker1]

I've used a similar tool as part of API logging, filtering out the signature on the bearer token... It's useful with request id for dealing with error reporting.