The proxy doesn't modify the SNI request, so we need to pass the name of
the host we're trying to reach instead of the proxy we're reaching it
through.
- Got rid of ifdef _WIN32 stuff adn moved to plat_ files instead.
- Also, check all calls to lws_zalloc, was potential failure on WIN32
- Made context destory enable to destroy a half inited context as well. This way I got get rid of some of the error handling complexity in libwebsocket_create_context
- Added TODOs for some potential problems I see where things might be leaking and such
The SSL code should not do lws_free(new_wsi) here. The caller should clean up the wsi in libwebsocket_close_and_free_session. Instead this can potentially cause a crash during that call.
Also if we fail to create the SSL for hte listener we should indicate failure to the caller.
is no problem on a unix system with sys/types.h
However on Windows it will result in a #undef pid_t ... When libwebsockets is used with pthreads32 which typedefs pid_t itself, it will fail to build with some weird errors.
Also since we're exporitng these macros to the entire world via libwebsockets.h we should not define a VERSION macro. Which is defined improperly anyway.
Since we include lws_config.h in the public headers, at least our HAVE_ macros should be kind of unique, so that we don't get redefinitions when used with other libraries using config files as well.
This patch lets libwebsockets use the lastest version of wolfSSL (the new name for CyaSSL).
The reason for the patch is that allthough wolfSSL provides compatibility headers for (old) projects using CyaSSL,
these are incomplete and do not work for libwebsockets.
The patch also fixes a typo in CMakeLists.txt where CYASSL_LIBRARIES was added to include_directories() instead of CYASSL_INCLUDE_DIRS.
Signed-off-by: ABruines <alexander.bruines@gmail.com>
Read the full incoming TLS/SSL record at once in libwebsocket_service_fd().
SSL_read() is called until no more pending data for the current record is buffered in SSL.
SSL_read() is never requested more than the pending data size for the current record
to ensure that the fd is not read again for new data, which would be copied in the SSL buffer otherwise.
AG: added changelog and documentation comment
Signed-off-by: Gadkari Mugdha <mugdha.gadkari@siemens.com>
Reviewed-by: Roger Meier <r.meier@siemens.com>
HTTP reject error code returned by server during HTTP handshake is extracted and sent to the client application.
With this fix, the Connection error callback will include the HTTP reject status code and response frame received from server. This string passed in Connection error callback can be read or ignored by client application based on client application requirement
See: https://msdn.microsoft.com/en-us/library/windows/desktop/ms737625(v=vs.85).aspx
Specifically the section reading:
"Until the connection attempt completes on a nonblocking socket, all subsequent calls to connect on the same socket will fail with the error code WSAEALREADY, and WSAEISCONN when the connection completes successfully. Due to ambiguities in version 1.1 of the Windows Sockets specification, error codes returned from connect while a connection is already pending may vary among implementations. As a result, it is not recommended that applications use multiple calls to connect to detect connection completion. If they do, they must be prepared to handle WSAEINVAL and WSAEWOULDBLOCK error values the same way that they handle WSAEALREADY, to assure robust operation."
Noticed by Andrey Pokrovskiy
Close processing reused ping processing to save and send the payload,
and sets a flag to know it's close, but forgot to change the control
packet accordingly.
Signed-off-by: Andy Green <andy.green@linaro.org>
