gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data

[Wilmer van der Gaast]

Hello,

/* My ref: http://bugs.bitlbee.org/bitlbee/ticket/938 */

I seem to have a problem with GnuTLS 3.0.x, from what I can see this is 
a bug (but please correct me if I'm wrong).

I have a function that receives data from a HTTPS server. This is all 
done with async and non-blocking I/O. Before returning from the read 
event handler, gnutls_record_check_pending() is called to check if 
there's any more unencrypted data waiting.

When trying to query some servers (in this case MSN Messenger HTTPS 
servers), gnutls_record_check_pending() will return a non-0 number (goes 
all the way up to 8KB at times), but when I try to read this data I get 
-28 which seems to be GNUTLS_E_AGAIN.

 From what I know, that error code means "I would block but this is a 
non-blocking socket, so come back later".

This seems to be a violation of what is promised in the manpage of 
gnutls_record_check_pending():

DESCRIPTION
        This  function checks if there are unread data in the gnutls
        buffers. If the return value is non-zero the next call to
        gnutls_record_recv() is guarranteed not to block.

Is this a known issue? Am I using it the wrong way/do I need to set a 
new flag from GnuTLS 3.x to get the behaviour I want? I could work 
around this by not even calling check_pending() if I was just returrned 
E_AGAIN because it seems that this condition fixes itself when more data 
comes in, but this seems like a risky assumption to me as well (and it 
doesn't work all the time, possibly):

pending = 5792
gnutls_record_recv = -28
pending = 5792
gnutls_record_recv = -28
pending = 8688
gnutls_record_recv = -28
pending = 8688
...
gnutls_record_recv = -28
pending = 8688
gnutls_record_recv = 2048
pending = 8758
gnutls_record_recv = 2048
pending = 6710
gnutls_record_recv = 2048
pending = 4662
gnutls_record_recv = 2048
pending = 2614
gnutls_record_recv = 2048
pending = 566
gnutls_record_recv = 566
pending = 0
gnutls_record_recv = -9

In fact, looking at these numbers it's not really clear to me at all why 
I suddenly can read data even though the number of pending bytes didn't 
change, but I suppose that's because some control frame came in that 
didn't deliver any useful data for my stream.


Cheers,

Wilmer van der Gaast.

-- 
+-------- .''`.     - -- ---+  +        - -- --- ---- ----- ------+
| wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
| lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
+--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +