Haxx ad

curl's project page on


cURL > Mailing List > Monthly Index > Single Mail

curl-tracker mailing list Archives

[ curl-Bugs-1480821 ] gnutls can return GNUTLS_E_AGAIN -28, Curl_write checks -1

From: <>
Date: Wed, 03 May 2006 23:02:32 -0700

Bugs item #1480821, was opened at 2006-05-03 06:11
Message generated for change (Comment added) made by bagder
You can respond by visiting:

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: https
Group: wrong behaviour
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Mark Eichin (eichin)
Assigned to: Daniel Stenberg (bagder)
Summary: gnutls can return GNUTLS_E_AGAIN -28, Curl_write checks -1

Initial Comment:
High level bug: a pycurl app using gssapi auth to
upload images as
attachments was corrupting the images, very slightly
(band of pixels
from the right appeared over on the left.)

Analysis of the corruption revealed that there were
28-byte chunks inserted, somewhat near 16k boundaries.)
analysis revealed that these were 28-byte repeats of data.

Tracing the python code revealed no inaccuracy.
fprintf's in pycurl, likewise.
Finally, fprintf's in libcurl got me as far as
Curl_write, and the
bytes_written = Curl_ssl_send(conn, num, mem, len);
expression... which would return -28, causing length to
Further tracing revealed this to be due to
returning -28:

CURL_SSL_SEND: len=16384, written=-28
CURL_WRITE: result=0, present=16384, written=-28
CURL_SSL_SEND: len=16412, written=16384
CURL_WRITE: result=0, present=16412, written=16384
CURL_SSL_SEND: len=28, written=28

and a bit of googling turned up the fact that
and that the "new" (at least a year old?) non-blocking
support in
GNUTLS causes it to return that in some cases.

No idea if this should be hidden in lib/gtls.c, though
I *would*
suggest that perhaps lib/sendf.c:Curl_write's test of
  if(-1 == bytes_written) {
be made a bit more strict... given the errno checks
that follow, it
looks like it might be more correct to fix the gtls
layer, though.

Found this via debian testing, curl version 7.15.3; I
didn't catch
anything that matched in the Changelog and buglist for
7.15.4, but I
haven't read diffs yet...
                        _Mark_ <>


>Comment By: Daniel Stenberg (bagder)
Date: 2006-05-04 08:02

Logged In: YES

Thanks a lot for verifying, this fix has now been committed
to CVS. Closing this report.


Comment By: Mark Eichin (eichin)
Date: 2006-05-04 01:27

Logged In: YES

Excellent, thanks. I've applied it to a fresh 7.15.3, and
done 50 iterations of upload/download/compare/delete, and
have not seen the manifestation at all (or the secondary
manifestation of "missing cgi arguments" which would have
happened when the overlap collided with other form/multipart
fields instead of with the image itself.) So I'm
satisfied... thanks again.


Comment By: Daniel Stenberg (bagder)
Date: 2006-05-03 12:45

Logged In: YES

Many thanks for splended research and an accurate bug report.

I believe the only sensible thing to do is to let the
Curl_ssl_function() return 0 in EWOULDBLOCK case to make
them work like the normal send() case works. Uh, it seems we
already do this for the OpenSSL case. How about a patch like

diff -u -r1.11 gtls.c
--- lib/gtls.c 13 Nov 2005 23:04:28 -0000 1.11
+++ lib/gtls.c 3 May 2006 10:44:52 -0000
@@ -458,6 +458,12 @@
   int rc;
   rc = gnutls_record_send(conn->ssl[sockindex].session,
mem, len);

+ if(rc < 0 ) {
+ if(rc == GNUTLS_E_AGAIN)
+ return 0; /* EWOULDBLOCK equivalent */
+ rc = -1; /* generic error code for send failure */
+ }
   return rc;


You can respond by visiting:
Received on 2006-05-04

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET