Commit 173e9c4e made LWS_SEND_BUFFER_SIZE a multiple of a certain
value returned by _LWS_PAD_SIZE macro. This macro expanded to
"sizeof(void *)" on non-x86_64 architectures, which made it
unsuitable to use LWS_SEND_BUFFER_SIZE in preprocessor #if
expressions in the library user code.
This patch preserves the padding logic since commit 173e9c4e but
makes it more preprocessor-friendly for applications using
libwebsockets by setting _LWS_PAD_SIZE to the size of "void *"
determined by cmake when libwebsockets is configured for the
target platform.
Signed-off-by: Alexander Lukichev <alexander.lukichev@gmail.com>
Since 0d89f3cbed added recently,
http1.1 keepalive tries to actually keep alive.
Some updates are needed to keepalive flow to solve problems coming from
changes that were hidden until now by keepalive basically closing until
recently. It's not very noticable since clients will retry as close is
the default 1.0 behaviour... anyway this lets me do
wget http://localhost:7681/test.htmlhttp://localhost:7681/test.html
using keepalive correctly on the test server.
Signed-off-by: Andy Green <andy.green@linaro.org>
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.
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>
