>> However, setting CURLOPT_NOBODY back to "false" does *not* reset the request
>> method back to GET. But because it is now "false", cURL will wait for
>> content if the response contains a content-length header.
>
> While I can agree with parts of your reactions, there's nothing in the libcurl
> documentation that says how it behaves when you pass a FALSE to
> CURLOPT_NOBODY. So perhaps the CURL binding should just not allow a FALSE
> there...
>
> Let me also mention that libcurl is now almost eight years old and you're the
> first person to point this out, so I don't consider this a major problem! ;-)
>
> I'll certainly consider making libcurl ignore CURLOPT_NOBODY set to FALSE.
>
>> From a usability standpoint, setting CURLOPT_NOBODY to "true" should NOT set
>> the request method to HEAD if it is not going to reset it back when it is
>> set to "false".
>
> I'd reverse the logic and say that the FALSE behavior is the bad one. Or at
> least the surprising one.
>
>> The only way to reset the state of the cURL session is to set CURLOPT_HTTPGET
>> to "true",
>
> No. You can "reset" it several ways but if you want to use GET then
> CURLOPT_HTTPGET is the way.

I understand that there are several ways to "reset" the behavior of
CURLOPT_NOBODY, or change the request method to something else. I
should have said, "one way to change the state back to GET..."

One of my (mistaken) beliefs was that the PHP/CURL boolean options
behave like switches on the state of cURL. Setting an option to true
results in the exact reverse of the false behavior. I think this is a
reasonable assumption for a casual user to make, because it is the
simplest concept to grasp. But now that I think about it, this could
not hold for all the boolean PHP/CURL options.

The reason I suggested to change the "true" behavior was to make
the option more like an "on/off" switch, which only affects how cURL
handles body content. However, that would both break existing code and
not optimize the HTTP request to get a header only. Therefore, it is
probably better to, as you said, make the "false" behavior have no
effect. That would keep with the convention of other options, such as
CURLOPT_HTTPGET, whose 'false' behavior is similar. At the very least,
one might document the 'false' behavior that is there now.

Thanks for listening to my two cents.

_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-php
Received on 2008-04-07