Fix-up js_recvline() based on infinite error/log message report from Nelgin:
term 0087 TLS ERROR 'Unexpected <Unknown type> (24) packet, expected application_data (23)' (-1) popping data message repeated 492 times: [ term 0087 TLS ERROR 'Unexpected <Unknown type> (24) packet, expected application_data (23)' (-1) popping data] When using TLS with a JS Socket object, if there was any kind of data error, the recvline() method would return a blank string rather than null/undefined. nntpservice.js just loops when it receives a blank string, so this caused an infinite loop (with disk-filling error log messages). First change: if no data has been received (i == 0) and there's any kind of receive error or timeout or disconnection, just return null. And not undefined, but null (!) like in v3.15 (before the great JS engine update of 2000-mumble). Also, there appeared to be a JS_RESUMEREQUEST call missing in the TLS error return case - so that's another bug fixed. Commented on the magic return values for js_sock_read_check() and js_socket_recv(). Simplified js_sock_read_check() return value a tad: let the caller decide if they want to do something special based on the value of 'i'. Added some comments to make this code more readable. We are now no longer treating the different error return values (0 and -1) from js_socket_recv() special in this function, but we dont' treat them special in any of the other calls in this file/object either, so that seems to be the norm.
Showing with 25 additions and 24 deletions