So I added a check, wether this is an array actually, else I use the port as intended as int. I would assume, that that array check is needless altogether but maybe old PHP versions needed that?
I think the current usage of CURLOPT_CUSTOMREQUEST is wrong. As far as I can tell CURLOPT_CUSTOMREQUEST = Method::POST is not the same thing as CURLOPT_POST = true.
I struggled for hours with POSTed data not being accepted by IIS. First IIS threw an HTTP 411 due to curl not sending a Content-Length header. That is solved by replacing CURLOPT_CUSTOMREQUEST with CURLOPT_POST in the case of actual POSTs. Also, IIS in my case returns an HTTP 301 redirect, which I need Unirest to follow, so I set the CURLOPT_POSTREDIR = 3 in order to let the POST follow on redirect via 301 or 302.
Notice this: https://curl.haxx.se/libcurl/c/CURLOPT_CUSTOMREQUEST.html - "Many people have wrongly used this option to replace the entire request with their own, including multiple headers and POST contents. While that might work in many cases, it will cause libcurl to send invalid requests and it could possibly confuse the remote server badly. Use CURLOPT_POST and CURLOPT_POSTFIELDS to set POST data. Use CURLOPT_HTTPHEADER to replace or extend the set of headers sent by libcurl. Use CURLOPT_HTTP_VERSION to change HTTP version."
In any case, I know that the CURLOPT_POSTREDIR option probably shouldn't go here and should be client configurable, but I can't find a good place for it. It would be nice to have one-shot $curlOpts passed in with the send method, or curlOpts() that otherwise live for only one curl_exec().
libcurl's CURLOPT_SSL_VERIFYHOST option accepts only values 0 and 2. This fix is fail-secure in that SSL host verification will be enabled regardless of what a caller passes to Request::verifyHost($bool) unless $bool === false.
Grischa Brockhaus
thenetexpertsandAhmad Nassri
İrfan EvrensandAhmad Nassri
Jesse Skrivseth
Kairat Jenishev
Igor Rusinov
Ahmad Nassri
Tomasz Sawicki
frankdee
Gabriel
cristianp6
thibaultCha