On Wed, 3 Apr 2002, Juan wrote:

> I'm using curl version 7.9.5 and the operating system is Linux. I'm running
> curl from one linux server where my php file resides and the imap server is
> configed on another linux server in the same LAN.
>
> I tried -vi and I got the following error message:
> * Connected to mirror.oz.com (203.31.31.49) port 80
> > POST /functions/preprocess.php HTTP/1.1
> User-Agent: curl/7.9.5 (i586-pc-linux-gnu) libcurl 7.9.5 (ipv6 enabled)
> Host: webmail.oz.com.oz
> Pragma: no-cache
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
> Content-Length: 38
> Content-Type: application/x-www-form-urlencoded
> Connection #0 left intact
> curl: (52) Empty reply from Server
> * Closing connection #0

This shows the entire request is getting sent to the server, and for some
reason it disconnects the connection immediately ("Connection #0 left
intact"), before curl has read a single byte of data from the stream.

What does your web server's log say when this happens?

Using 'strace' or a network analyzer you can of course check in greater
detail exactly what's happening. Perhaps even gdb'ing this would bring more
light on the issue.

I can't explain this behavior. :-(

> I can't force it to happen. It just sometimes works and sometimes fails.
> In my PHP file, I check whether there is new mail in my mailbox, if there
> is, then I do some email filter stuff which interacts a lot with IMAP
> server. If there is NO new mail in my mailbox, that is to say the email
> filter part is not executed, curl always works. When there is new mail in
> my mailbox, sometimes curl fails with error code 52 and sometimes it
> succeeds.

This sounds like an issue with how the server communicates the result from
your php code back to the client.

> However I tried to run the same script from another Linux server with curl
> version 7.9.2 and so far it works fine.

Well, this certainly indicates a problem in 7.9.5 then. Do you think you can
run a debugger and set a break-point in Curl_read() (in sendf.c) to see what
kind of return codes you get on the sread() line?

That would help a lot.

> I somehow feel V7.9.2 works slower than V7.9.5.

I can't put my finger on any major differences in speed between these two
versions. We've undergone a pretty serious internal re-arrange between them
though, as we've converted to using non-blocking sockets all over, which we
didn't back in 7.9.2.

> I doubt it has sth to do with network speed or network connection. But I
> just can't get the solution.

No, I don't think it is a speed thing.

> I can't be certain if there's any potential problem if I use curl 7.9.2?

Certain? Noooo. There are no guarantees what so ever when using curl. You can
never be sure there aren't any problems! Checking the changelogs since 7.9.2
also points out a rather large list of bugs we've fixed since then...

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/