While errors on transmit seem to be handled well, errors on receive
do not, especially through js_recv_line() which has been seen to
trigger a large number (hundreds) of ECONNRESET errors.  To prevent
this, simply close the socket when an otherwise unhandled error
occurs.

Almost certainly fixes that issue, but the underlying cause is still
undetermined.  The calling script (imapservice.js) was checking
Socket.is_connected after each recv_line() call, so if the socket
was actually reset, it would be expected to only call it once.

An alternative would be to explicitly handle the error that is
seen (CRYPT_ERROR_PARAM1), but let's try a generic fix first and see
of anything breaks because of it.  Most likely issue would be an
inability to recv() data after calling shutdown(), but I don't think
many people do that except to move the TIME_WAIT to where they want
it.

The socket set allocated by xpms_create() was never freed. Found by Coverity.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

Only observed on Windows, the option value variable (val) was uninitialized so querying byte-sized options using WinSock getsockopt() would leave the MSB of the value as undefined (garbage), resulting in sockinfo.js output like this:
KEEPALIVE = -858993663
instead of this:
KEEPALIVE = 1

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

Insure Socket.connect() sets the "error" property to a representative error value when the connection fails.
Previously (on Windows), the "error" property would be set to 0 upon a connection failure.

  text description of last socket error that occurred

Instead, just return -1 from js_socket_recv().

function for external sockets.  However, service thrads that use TLS were
relying on the finalize function to clean up the TLS session.

Revert 1.242, and add a finalize parameter to do_js_close() which will only
avoid the shutdown() call rather than completely avoid do_js_close()
completely.

This fixes a TLS session leak that would eventually prevent any new
encrypted connections.

depend on a socket descriptor still won't work.

"At least two arguments required (interfaces, port, and protocol)"

These have a large number of optional parameters, so these are placed in
a separate argument as an object:

ie: var s = new ConnectedSocket("synchro.net", "finger", {type:SOCK_DGRAM});
ie: var s = new ListeningSocket(["::","0.0.0.0"], "printer", "spooler", {retry_count:15});

new Socket(true) // creates an IPv6 TCP socket
new Socket(SOCK_STREAM, true) // creates an IPv6 TCP socket
new Socket(SOCK_DGRAM, true) // creates an IPv6 UDP socket
new Socket("myprot", true) // creates an IPv6 TCP socket named "myprot"

support to the JS API.

This introduces a new request field send_content which indicates if the
content should be sent.  This covers various cases like HEAD responses
where there's an entity, but no content is sent as well as 204, 304, and 1xx
responses where there is not even an entity.

writebuf() will now enforce this, so there's no need for various checks
throughout the code to see if data should be sent or not.

Also, we now only set sent_headers after the headers are sent.

declaration

Use this in place of JS_GetPrivate() in native class methods that need the
class instance's private data pointer and will do bad things if that pointer
points to something other than what is expected. mcmlxxix (matt) discovered
that using Object.apply(), you can invoke class methods where the 'this'
instance is a different class. This would result in
"Internal Error: No Private Data." or a crash.
So now, gracefully detect this condition and report a meaningful error:
"'<class-name>' instance: No Private Data or Class Mismatch"

Also, important to note: if the method uses JS_THIS_OBJECT to get the JSObject*
to pass to JS_Get*Private, then it must do this *before* it calls JS_SET_RVAL.

From jsapi.h:
 * NB: there is an anti-dependency between JS_CALLEE and JS_SET_RVAL: native
 * methods that may inspect their callee must defer setting their return value
 * until after any such possible inspection. Otherwise the return value will be
 * inspected instead of the callee function object.

The js_crypt*.c files still need this treatment.

to a second thread before the first has the session set active.  Add calls
to lock/unlock the certificate to prevent this.

The better options is likely to have a function that adds the key and socket
and sets the session active in one call and handles the locking internally.

But I'm lazy, so we get the lock functions.

TCP connection actually failed. This bug only appeared to affect *nix
systems. This bug appears to be very old, introduced in rev 1.74 of
this file (Mar-2003) by yours truly.
From the Linux 'connect' man page:
EINPROGRESS
              The  socket  is  nonblocking  and the connection cannot be i
              completed immediately.  It is possible to select(2) or poll(2)
              for completion by selecting the socket for writing.  After
              select(2) indicates writability, use getsockopt(2) to read the
              SO_ERROR option at level SOL_SOCKET to determine whether
              connect() completed successfully (SO_ERROR is zero) or
              unsuccessfully (SO_ERROR is one of the usual error codes listed
              here, explaining the reason for the failure).

We weren't doing the 'getsockopt(SO_ERROR)' part.