cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

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: SourceForge.net <noreply_at_sourceforge.net>
Date: Wed, 03 May 2006 03:45:58 -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:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1480821&group_id=976

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: Open
Resolution: None
>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
intermittent
28-byte chunks inserted, somewhat near 16k boundaries.)
 Further
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
increase.
Further tracing revealed this to be due to
gnutls_record_send
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
GNUTLS_E_AGAIN is -28,
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_ <eichin_at_gmail.com>
                        <eichin_at_metacarta.com>

----------------------------------------------------------------------

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

Message:
Logged In: YES
user_id=1110

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
this:

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:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1480821&group_id=976
Received on 2006-05-03

These mail archives are generated by hypermail.

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

File upload with ASP.NET