curl-library
Re: php curl_exec won't return any data, libcurl-7.21.3.0, php 5.3.4, WampServer2.1d-x64.exe
Date: Fri, 11 Feb 2011 13:17:46 +0100
On Fri, Feb 11, 2011 at 9:32 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Fri, 11 Feb 2011, Tolas Anon wrote:
>.........
>> curl and libcurl on windows should support this option in a way that
>> works, by default.
>
> We've discussed that in the past and we've decided not to. Keep-alive is not
> only a feature, it also changes the behavior in ways TCP isn't necessarily
> meant to work. TCP handles a broken and repaired connection just fine
> without keep-alive.
>
> It is also very easy for an application to enable the options as I've shown.
Just not for the platforms i use, apparently.. :(
>
> The flaky support in various operating systems of course makes it
> "interesting" too.
That could be a good reason not enable it by default..
But at least allow it to be enabled from windows libcurl/php with
curl_setopt()...?
>> as it stands, i'm left completely in the dark for something that i don't
>> consider an unreasonable use-case.
>
> Perhaps, but that's not libcurl's fault I claim.
>
>> i'm open to any solution you can think of, aside from switching to linux,
>> because that doesn't support my 3-monitor setup..
>
> I already suggested a way. Although I'm not sure what control Windows allows
> on the TCP keep-alive timers etc.
Yes, me neither. i was educated in the basics of tcp/ip about 15 years
ago, and then moved on..
> But then I've not seen you actually having verified that our suspicions are
> the real reasons for the no data case.
What can i do to prove them?
>
>> and how come i can send a byte back on the text/html level every 25
>> seconds, yet curl and libcurl
>> a) just ignore them until the connection is completely closed
>
> That's not what libcurl does. If that was indeed what you tried to do, then
> I believe your test was flawed. libcurl simply reads the data that arrives
> over the TCP connection as soon as it arrives.
Hm.. yes, it could be that the sending end for this is at fault.
I'm now running that run.php test in the browser, with a
<html><head></head><body> before the
wait-loop-with-1-byte-every-25-seconds, and it also doesn't display
slowly increasing data.
No reply to that mail about ob_flush() to the php-general mailinglist
yet, so i'll look into it further today myself.
>
>> b) don't see them as keep-alive traffic on the shortests of real internet
>> paths?
>
> libcurl doesn't see anything as "keep-alive traffic", that's not libcurl's
> business to care about.
It's for the lower layers of the connection, and the equipment that
handles those, right?
>
> If something is killing your idle connections it is not libcurl so it's not
> libcurl you have to convince the connection is still alive.
>
No, i don't think it's libcurl either, it's gotta be one of the
components along the way, most likely my adsl router.
I had just hoped it would be easy to enable something in libcurl/curl
that would fix this situation..
But apparently I got a challenge here. ;)
>......
> I can sympathize with your problem, but I think you can do a lot better to
> actually proceed. By for example figuring out exactly what's happening and
> by trying to address the keep-alive issue in the correct place.
I've tried all access points to enable keep-alive that I could find via google.
But i'm going to investigate further.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-02-11