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

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