#44584 [Opn->Csd]: CURLOPT_NOBODY sets request method to HEAD

From: Date: Fri, 07 Nov 2008 10:26:46 +0000
Subject: #44584 [Opn->Csd]: CURLOPT_NOBODY sets request method to HEAD
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-1411@lists.php.net to get a copy of this message
ID: 44584 Updated by: vrana@php.net Reported By: humbads at alum dot mit dot edu -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: * PHP Version: Irrelevant New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. "Request method is then set to HEAD. Changing this to FALSE does not change it to GET." Previous Comments: ------------------------------------------------------------------------ [2008-03-31 16:06:24] humbads at alum dot mit dot edu Description: ------------ Setting CURLOPT_NOBODY to "true" with curl_setopt sets the request method to HEAD for HTTP(s) requests, and furthermore, cURL does not read any content even if a Content-Length header is found in the headers. 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. If CURLOPT_NOBODY is set to "true" and back to "false", curl_exec will appear to hang unexpectedly for a request. If the server times out the connection, then an curl will return an error like "transfer closed with 2523 bytes remaining to read". 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". Otherwise, the parameter is not truly "on/off", and has unknown, undocumented side-effects. Ideally, CURLOPT_NOBODY should only cause cURL to ignore the content-length headers and not read any content. The only way to reset the state of the cURL session is to set CURLOPT_HTTPGET to "true", which both sets the request method to GET and causes cURL to read content. This behavior is not mentioned the PHP documentation, so it would be nice to add something about it. Otherwise, reusing a curl handle causes unexpected behavior. PHP bug 40997 is a consequence of this behavior: http://bugs.php.net/bug.php?id=40997 So there are two documentation requests: 1. Mention that setting CURLOPT_NOBODY to "true" sets the request method to HEAD for HTTP(S) requests, and cURL ignores the content-length header. 2. Mention that setting CURLOPT_NOBODY to "false" causes cURL to wait for content if a content-length header is read, but it does *not* reset the request method back to GET. Reproduce code: --------------- $ch = curl_init(); curl_setopt($ch, CURLOPT_TIMEOUT, 3); // set execution timeout curl_setopt($ch, CURLOPT_URL, "http://static.php.net/www.php.net/images/php.gif"); // Changes request method to HEAD and ignore content curl_setopt($ch, CURLOPT_NOBODY, true); // cURL will wait for content, but not change the request method. // curl_exec will timeout waiting for the content curl_setopt($ch, CURLOPT_NOBODY, false); // Setting HTTPGET to true resets the request method back to GET // and cURL will read content. //curl_setopt($ch, CURLOPT_HTTPGET, true); var_dump(curl_exec($ch)); print curl_error($ch)."\n"; curl_close($ch); ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=44584&edit=1

« previous php.doc.bugs (#1411) next »