CURLRequest - supplied argument is not a valid File-Handle resource #Windows x64

[jbotka]

Describe the bug
Using CURLReqguest class produce error:
CRITICAL - 2019-09-09 21:04:32 --> curl_setopt_array(): supplied argument is not a valid File-Handle resource

CodeIgniter 4 version
CI4 - RC1

Affected module(s)
CURLRequest

Expected behaviour, and steps to reproduce if appropriate
Any attempt where is not set debug option will produce this error since Class initialize $config['debug'] = false and later check if via isset() and not via standard condition (true/false) directly from the option so every time this will pass, and it will pass empty option to CURL options that will produce error.

Context

• OS: Windows 8.1
• Web server Apache
• PHP version 7.3.8

[MGatner]

Sort of a duplicate of #2049, which should probably be reopened. This is partly underway (see #2168) but needs an actual PR.

[jbotka]

I fixed first part, simple by changing condition but anyway after allowing debug it will throw this error:

CRITICAL - 2019-09-10 07:52:14 --> curl_setopt_array(): cannot represent a stream of type Output as a STDIO FILE*

[michalsn]

You can try this fix #2204

[jbotka]

You can try this fix #2204

Sorry didn't see your pull request :/ I did it a bit another way.

[michalsn]

Well... from what I see, you removed the CURLOPT_STDERR part so it won't work.
According to the documentation, we should have the ability to write the output to a file or just "echo" it when the debug option is enabled.

[jbotka]

Well... from what I see, you removed the CURLOPT_STDERR part so it won't work.
According to the documentation, we should have the ability to write the output to a file or just "echo" it when the debug option is enabled.

Yeah, I just realize it :) You are right...

[michalsn]

@xbotkaj this should be fixed by #2168

Please, give it a try if you find a moment.

[jbotka]

@xbotkaj this should be fixed by #2168

Please, give it a try if you find a moment.

Sorry I was few days off... I will look into it more in the next days.

[jbotka]

Update to this issue. It is confirmed windows related problem. Uploaded to LINUX server and it works fine with php://output.

I tried to update CURL program in XAMPP without change. Maybe is problem in PHP curl extension for windows.

Similar issue in original guzzle -> guzzle/guzzle#1413

[khuderm]

I am experiencing this on Ubuntu 18.04.3 running php7 and apache2

[jbotka]

I am experiencing this on Ubuntu 18.04.3 running php7 and apache2

Can you please write specific php build and full version of Apache? Maybe we can track it down. If it is possible please check curl extension version.

[michalsn]

Finally, I had time to get my hands dirty with a windows machine.

I was able to reproduce this problem and also I have a possible solution.

Tested on machines/environments:

• Win7 - spark with php 7.3.9 and xampp (apache 2.4.41 + php 7.3.9)
• MacOS - spark with php 7.3.9
• Ubuntu - nginx 1.13.3 + php 7.2.11

[MGatner]

@michalsn Is the problem that php://output isn't supported on Windows? I can't find any documentation on this, and the PHP site states it as though it is a standard stream, always available. There are a lot of users reporting issues with it though. I personally don't think stderr is the most logical destination for the debug output, but it might be the low-hanging fruit right now.

[michalsn]

@MGatner I couldn't find much about php://output for Windows but apparently, it doesn't work as expected. Technical reasons are unclear for me.

From what I understand php://stderr can be actually what we want. When running a built-in server via spark serve it will be outputted to the console screen. In the other case, it will write to the server error log.

It would be nice if someone could check if that referenced PR solves the problem in his case. Also - any other suggestions/ideas will be appreciated.

[MGatner]

I understand the solution, and I agree with you - I was just noting that stderr feels like the wrong place to be sending debug output, even if it has the desired effect for our scenarios. But I think it is what we've got for now, and I'll be very glad to close this one out. Thank you for the troubleshooting and research - I'll give those with the issue a chance to test this solution before we merge but IMO this is ready.

[michalsn]

Yes, I definitely agree with you that using php://stderr seems a "little" wrong but for now I have no other ideas.

[lonnieezell]

I can live with this solution for now, though I agree it doesn't feel perfect. As long as there's a note in the docs about this caveat I think we can close it out and get this feature working for people again.

Thanks for your work on this @michalsn