Update on this issue: it seems like a real bug in PHP/CURL binding that
occurs when you use the CURLOPT_INFILESIZE option and the value you set (the
length) is "just right".

Bug reported in the php bug system. For details see
http://bugs.php.net/?id=49531 <http://bugs.php.net/?id=49531&edit=2>

Regards
Gilad
__________________
Gilad Parann-Nissany
http://www.parann.net/

On Fri, Sep 11, 2009 at 00:02, Gilad Parann-Nissany <gilad_at_parann.net>wrote:

> Based on Daniel's analysis this is a curl-and-PHP issue (and thanks to
> Daniel for the input). Does anyone on this curl-and-php mailing list have an
> insight to what is going on?
>
> To recap and restate the issue based on Daniel's feedback:
>
> I am working with PHP 5.2.10 and libcurl 7.19.4 in Apache 2.2.11 on Win32
> (XP).
>
> I am using the following options to make an HTTP call
>
> CURLOPT_PUT => true,
> CURLOPT_INFILESIZE => content_length,
> CURLOPT_READFUNCTION => 'mycallback'
>
> (other options truncated for brevity)
>
> This PUTs a file and the request body is processed through the 'mycallback'
> function. This works fine *most of the time* but not all the time.
>
> If the data is large > 100K, and even then only SOME of the time
> (intermittently), I get a message:
>
> CURLPROTO_FILE cannot be activated when in safe_mode or an open_basedir is
> set
>
> Now I have set in PHP "open_basedir" to limit the directories that my code
> can use; this is a deliberate security measure to make life hard for hackers
> so they cannot access just anywhere on the disk. So that is *not *my
> question.
>
> It seems that PHP thinks that it needs to use the file protocol
> (CURLPROTO_FILE). Why? I have only used HTTP and most of the time that
> works.
>
> My questions are:
>
> 1. why does PHP/CURL *sometimes* make an attempt to use the filesystem
> somehow? Is it trying to cache the data I am streaming? Or something else?
> 2. Is there any way to control this behavior?
>
> Note I prefer not to switch off "open_basedir" because it has a security
> benefit.
>
> Regards
> Gilad
> __________________
> Gilad Parann-Nissany
> http://www.parann.net/
>
>
>
> On Thu, Sep 10, 2009 at 23:40, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
>> On Thu, 10 Sep 2009, Gilad Parann-Nissany wrote:
>>
>> CURLPROTO_FILE cannot be activated when in safe_mode or an open_basedir
>>> is
>>> set
>>>
>>
>> ...
>>
>> However this implies that some of the time (intermittently) the libcurl
>>> code
>>> tries to create some kind of file on my disk; maybe a temp file to cache
>>> the
>>> data I am streaming? And then it hits my deliberate security limitation.
>>>
>>
>> No, that's not what it implies. It implies that the PHP/CURL code somehow
>> detects something that it prevents you from doing and it tells you about it.
>> If libcurl itself would do it the PHP/CURL layer would have no idea and
>> wouldn't be able to tell you.
>>
>> I have not asked it to do so - the 'callback' is actually *implementing a
>>> streaming approach* and so all the request is supposed to be in memory. I
>>> chose streaming like this to avoid needing too much memory and to avoid
>>> the
>>> overhead of reading/writing anything to disk.
>>>
>>> So I am a bit concerned that cURL seems to be writing/reading to disk
>>> under
>>> the hood.
>>>
>>
>> I can tell you that libcurl does no such thing. I cannot tell you if there
>> are situation when the PHP CURL extension might do so - as I don't know.
>>
>> 1. am I correct in the analysis - does libcurl indeed have code that
>>> might
>>> write buffers to the disk sometimes (but not all the time) when using the
>>> callback mechanism?
>>>
>>
>> Nope, it doesn't.
>>
>> 2. can you explain the conditions where this may happen and why?
>>>
>>
>> No, I can't.
>>
>> 3. is there any way to configure cURL to control this behavior?
>>>
>>
>> This is not a "cURL" issue, this is a PHP/CURL issue - as in the libcurl
>> binding for PHP. libcurl doesn't have this behavior.
>>
>> --
>>
>> / daniel.haxx.se
>>
>
>

_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-php
Received on 2009-09-11