In
https://stackoverflow.com/questions/6180162/echo-curl-request-header-body-without-sending-it and
https://stackoverflow.com/a/47694977/1118719
https://stackoverflow.com/a/36016711/1118719
we see users needing to make connections (even if just to localhost) to see what curl is actually sending. Imagine that, the only way to see what I am about to send is to send something. But then I already sent it. (OK, first 'send it into some sort of _condom_', and then examine what is in that _condom_. But must it be that way?)
But one day one might only get only one chance to send exactly the right
request(s) to a certain site. Any mistakes might make the difference of
downloading the Pentagon Papers vs. getting the authorities knocking
on one's door. (And no, "Just adjust the site name when you are finally
happy with the _condom_'s contents" doesn't give one full confidence.)
That's why curl needs simple concepts like:
WWW::Mechanize::Cookbook(3pm)
See what will be sent without actually sending anything
$mech->add_handler("request_send", sub { shift->dump; exit; });
$mech->get("http://www.example.com");
(in the same spirit of:)
apt-get --print-uris --simulate --just-print --dry-run --no-act
and
rsync --dry-run #but alas no --just-print, --print-uris
Well, at least add it to https://curl.haxx.se/docs/todo.html . Thanks.
I can fully understand you and would give a yes vote on this concept. I'm just a bit curious on how this should be handled on the technical point of view. Keep in mind that curl is just a tool which gets the best out of libcurl, which does the magic behind the stuff. My idea would be too add a new CURLOPT to libcurl and write all the following output to the write function (where usually the site content comes). For people who might work on this, my idea would be to edit the sendf.h functions to check for the OPT
I think it is great that you are working on this. All I know is "please give the (command line) user a way to see what would be sent (headers, URIs, or both) without sending anything."
If anyone would like to work on an implementation, I would recommend using CURLOPT_OPENSOCKETFUNCTION to setup a "private" socket, possibly a socketpair/pipe and return CURL_SOCKOPT_ALREADY_CONNECTED from the callback. Then libcurl won't have to be touched to provide this feature.
Most helpful comment
If anyone would like to work on an implementation, I would recommend using
CURLOPT_OPENSOCKETFUNCTIONto setup a "private" socket, possibly a socketpair/pipe and returnCURL_SOCKOPT_ALREADY_CONNECTEDfrom the callback. Then libcurl won't have to be touched to provide this feature.