Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70434
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
Date: Wed, 27 Nov 2013 16:29:26 +0800
Message-ID: <CAHMUw2HaoKFMWkU2Aw5X5d+eKddQHkv0ZHhb_dDb5YBDg=M+0Q@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2c7da1cbaa004ec2465ec
Subject: Fixes for curl_setopt() and nullable values
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--001a11c2c7da1cbaa004ec2465ec
Content-Type: text/plain; charset=ISO-8859-1

Hi,

A few weeks ago I stumbled upon the following question on stackoverflow:

http://stackoverflow.com/questions/4163865/how-to-reset-curlopt-customrequest

It involves the CURLOPT_CUSTOMREQUEST option, which according to the
libcurl documentation can be set to NULL to restore the previous behaviour
of passing the method name based on the type of request.

However, for string-based options the current code converts a NULL value
into an empty string, so it's impossible to revert the behaviour.

After doing a quick hack I realized that there are more options that are
nullable, so I've decided to refactor some of the code to isolate the
string assignment; this makes adding future nullable options easier.

This is the pull request: https://github.com/php/php-src/pull/531

It passes the test cases on my machine (couldn't test all of them because
file uploads aren't supported when you use internal web server), but I
would appreciate a second look.


-- 
--
Tjerk

--001a11c2c7da1cbaa004ec2465ec--