Would be able to solve #43

Thanks @silvershadowcc

btw there will be likely still few more changes needed so that the token actually gets posted and not sent through a URL query parameter.

Thanks @silvershadowcc

btw there will be likely still few more changes needed so that the token actually gets posted and not sent through a URL query parameter.

Sorry, I assumed that the parameters would actually be posted haha. Changed it, this works.
Perhaps the variable/method names should be changed and I don't know if this structure is acceptable?

As stated in the commit:
The request method is now set to POST as boolean, instead of a string, since the method should remain defaulted to GET and there is no need to be able to set it to GET.

URL is spliced in URL and parameters which are now fed to the POST payload for both cURL and stream.

The namings are all good @silvershadowcc 👍

The request method is now set to POST as boolean, instead of a string, since the method should remain defaulted to GET and there is no need to be able to set it to GET.

I wonder if any one would use any other kind of request methods like PUT or HEAD. I suppose that's not the case. Might be more flexible to force users to specify eg POST.

I'll try to test this in the next days @silvershadowcc looking only at the code it looks good.

The next step after this would be to see if we can somehow make POST the default for the token_auth only and send other URL parameters still via GET. Why? This way it's still possible to reply requests using our log importer. What happens is then that in eg apache or nginx log the requests will be found like

IP ... GET matomo.php?action_name=foo&idsite=1&rec=1 ...

and someone else can then replay these actions. Vs with a POST of all parameters we would only see POST matomo.php. People use log analytics to replay requests if there was a downtime, if they are performing a long lasting upgrade, or in general always. Eg it's a lot faster to not process any of the tracking requests in real time but rather once a day or a few times a day reply all tracking requests from the logs at once. It's not too important but wanted to provide a bit of background. We don't have to do this as part of this PR but as a next step as part of #43 .

We would already POST the token by default. However, we can do this only once we make sure redirected URLs get the value posted as well.

Went back to the previous selection of POST as string. Currently no other methods would be supported since they may require different input for cURL and stream. Converted snake to camel casing and added the warning. Thanks for the background. Making sure that redirected URLs get the POST values might be as easy as using curl -L --post301 --post302, right?

The next step after this would be to see if we can somehow make POST the default for the token_auth only and send other URL parameters still via GET.

Do you mean sending a POST request with the token_auth as payload, but everything else still as GET? If so, it would be just as easy to implement it that way now (and fixing the potential redirect problem). The preferred method for this would be to use a GET request with HTTP Authorization header though, which would bring us back to #matomo-org/matomo#7349

If after merging this you are keen on giving #72 a try feel free to go ahead.

Tomorrow :) But I can't test bulk. I added that only POST and GET are supported for docs in the latest commit.

Thanks @silvershadowcc