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-10