CURLOPT_PROXY, CURLOPT_SSL_VERIFYHOST, CURLOPT_SSL_VERIFYPEER support

[nowackipawel]

No description provided.

[MGatner]

It looks good to me but we’ll need some tests.

[nowackipawel]

Could someone help me with this, @MGatner ? ;-) I needed it in my project so I wrote it and it is working as expected - but I will not find time for tests :(.

[MGatner]

I’ll give it a shot, probably next week though.

[nowackipawel]

@MGatner: that's gr8. Thank you.

[MGatner]

Looking at the current tests, there isn't really a way to verify proxy & SSL behavior beyond making sure they are set and passed to CURL correctly. SSL tests already exist for the verify parameter, but I added a basic proxy one. I think this will suffice, as we don't need to test CURL itself, just the framework's interface with it.

[MGatner]

Dig some digging after my test failed, and I think this actually isn't implemented correctly. All options should be applied during setCURLOptions() rather than in send(), and secure-peer has redundant value with the verify config option and should either be removed or merged with existing functionality. secure-host seems to be new content but I'm unclear on if SSL host verification is necessary apart from CURLOPT_SSL_VERIFYPEER.

[lonnieezell]

@MGatner I agree - it should be handled in setCURLOptions(). I don't believe Host verification is necessary, though, I'm not 100% sure. It's definitely redundant functionality. I would say remove for now.

Is this something you want to tackle still?

[MGatner]

I like the idea, especially since it doesn't look like we have a way to do this otherwise which would leave developers extending the library if they needed these. @nowackipawel Are you able to rework this a bit given the feedback above?

[MGatner]

@lonnieezell If @nowackipawel is MIA I think this should be closed out. Barring his continuation, I think an implementation of these features would merit a fresh start.

[lonnieezell]

@MGatner agreed. Closing.