More flexible this way... NULL for the new member means use
the ssl library default set of ciphers, so as long as your info
struct is zerod by bss or memset, you don't need to do anything
about this change unless you want to set the cipher list.
Signed-off-by: Andy Green <andy.green@linaro.org>
While looking at http://libwebsockets.org/trac/ticket/18
noticed the flow for timeout in service_fd will do bad things
if the fd we came to service has timed out. It gets freed and
then "serviced'.
Reported-by: Joakim Soderberg <joakim.soderberg@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
The function has a logical problem when the size of the requested
allocation is 0, it will return NULL which is overloaded as
failure.
Actually the whole function is evil as an api, this patch moves
it out of the public API space and fixes it to return 0 for
success or 1 for fail. Private code does not need to to return
wsi->user_space and public code should only get that from the
callback as discussed on trac recently.
Thanks to Edwin for debugging the problem.
Reported-by: Edwin van den Oetelaar <oetelaar.automatisering@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
The header name buffer and its max length handling has actually
been unused since the minilex parser was introduced. We hold
parsing state in the lex-type parts and don't need to store or
worry about max length, since the parser will let us know as
soon as it can't be a match for the valid header names.
This strips it out reducing the per-connection allocation for
x86_64 with default configure from 224 to 160.
Signed-off-by: Andy Green <andy.green@linaro.org>
There's no proper transition to http union state until now.
It only becomes apparant there's a problem when you try to
return -1 from the HTTP callback, during the close action
it will try to close() a nonsense, nonzero fd pointer in
the uninitialized u.http union member.
This patch takes a copy of the allocated headers struct from
the u.hdr union state, transitions to u.http clearing down u
and then calls the HTTP callback with URI args pointing to
the still-in-scope ah allocation. After the call, the copy ah
is freed.
That makes sure we are in the correct union state while still
giving the HTTP callback access to the URI without having to
copy it around.
Reported-by: Edwin can den Oetelaar <oetelaar.automatisering@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
This fixes
http://libwebsockets.org/trac/ticket/13
When using the default rx protocol buffer, the check is
performed against 0 not the default length. That's the
case both in client and server code...
There's no problem if you actually give a max frame size
in the protocol definition.
Signed-off-by: Andy Green <andy.green@linaro.org>
- Define LWS_DLL and LWS_INTERNAL when websockets_shared is compiled.
- The websocket_shared target compiles to websocket.lib / websocket.dll
(websocket.lib contains the exported functions for websocket.dll, and is
the file that is linked to when a program wants to use the dll)
- The websocket target compiles to websocket_static.lib on windows.
- Replaced any "extern" with "LWS_EXTERN" on libwebsockets.h for proper
DLL function exports.
- Created a LIB_LIST with all the libwebsocket dependencies, instead of
multiple calls to target_link_libraries, only one call is made for both
the static and shared library version. This makes it easy to add other
variants if wanted in the future.
- Added ZLIB as a dependency for the libs, so that the build order will be
correct at all times.
- Added a dependency for the websockets lib to the test apps, so it is
built before them.
- Fixed the test-server-extpoll app to include the emulated_poll, and link
to winsock on Windows.
- Removed the global export of libwebsocket_internal_extensions, and added
a function libwebsocket_get_internal_extensions() that returns it
instead. Using the global would not work with the DLL export on Windows.
It's only workable on gcc 4.6+... and in fact it's only
going to be interesting typically to the maintainer, so it's
commented out in Makefile.am.
Currently the worst remaining ones for x86_64 are
libwebsockets.c:2250:6:_lws_log 496 static
libwebsockets.c:2203:13:lwsl_emit_stderr 352 static
client.c:700:1:libwebsockets_generate_client_handshake 320 static
server.c:42:1:libwebsockets_decode_ssl_error 288 static
server-handshake.c:31:1:handshake_0405 272 static
client.c:368:1:lws_client_interpret_server_handshake 272 static
libwebsockets.c:447:1:libwebsockets_get_peer_addresses 256 static
daemonize.c:93:1:lws_daemonize 240 static
output.c:536:5:libwebsockets_serve_http_file 224 static
sha-1.c:131:1:sha1_step 192 static
sha-1.c:316:1:SHA1 160 static
libwebsockets.c:1604:1:libwebsocket_create_context 160 static
The top two there are error assembly buffers, they could be made
static but then they won't be usable from threaded user code.
Reported-by: Anders Brander <anders@brander.dk>
Signed-off-by: Andy Green <andy.green@linaro.org>
Drop the connection during parsing for a few more cases that can't be legit.
Take care about trying to free rxflow_buffer only if we reached a connmode
where it exists
Change behaviour on setting unknown HTTP method to kill connection
Signed-off-by: Andy Green <andy.green@linaro.org>
The two cases where I introduced snprintf are either already
safe for buffer overflow or can be made so with one extra
statement, allowing sprintf.
Signed-off-by: Andy Green <andy.green@linaro.org>
If the SSL connection failed before the headers came, we were not
dealing with deallocating the header malloc. This takes care of it.
Using CyaSSL, we are then valgrind-clean for ssl client and server.
With OpenSSL, there is 88 bytes lost at init that never changes or
gets recovered. AFAIK there's nothing to do about that.
OpenSSL also blows these during operation
==1059== Conditional jump or move depends on uninitialised value(s)
==1059== at 0x4A0B131: bcmp (mc_replace_strmem.c:935)
==1059== by 0x3014CDDBA8: ??? (in /usr/lib64/libcrypto.so.1.0.1c)
==1059== by 0x3015430852: tls1_enc (in /usr/lib64/libssl.so.1.0.1c)
==1059== by 0x3015428CEC: ssl3_read_bytes (in /usr/lib64/libssl.so.1.0.1c)
==1059== by 0x30154264C5: ??? (in /usr/lib64/libssl.so.1.0.1c)
==1059== by 0x4C3C596: lws_server_socket_service (server.c:153)
==1059== by 0x4C32C1E: libwebsocket_service_fd (libwebsockets.c:927)
==1059== by 0x4C33270: libwebsocket_service (libwebsockets.c:1225)
==1059== by 0x401C84: main (in /usr/bin/libwebsockets-test-server)
However googling around
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/60021http://www.openssl.org/support/faq.html#PROG13
(also the next FAQ down)
it seems OpenSSL have a relaxed attitude to this and it's expected.
It's interesting CyaSSL works fine but doesn't have that problem...
Signed-off-by: Andy Green <andy.green@linaro.org>
CyaSSL blows (symptomless?) uninitialized memory accesses in
valgrind when using SSL_get_version()... don't need to do it...
Signed-off-by: Andy Green <andy.green@linaro.org>
This brings the library sources into compliance with checkpatch
style except for three or four exceptions like WIN32 related stuff
and one long string constant I don't want to break into multiple
sprintf calls.
There should be no functional or compilability change from all
this (hopefully).
Signed-off-by: Andy Green <andy.green@linaro.org>
OpenSSL doesn't seem to have a way to close out three allocations
it creates during SSL library init.
Even after doing the magic incantations suggested on the openssl list, we're
left with these. Well, 88 bytes from ssl init is probably not critical,
but it's annoying
==15206== HEAP SUMMARY:
==15206== in use at exit: 88 bytes in 3 blocks
==15206== total heap usage: 13,566 allocs, 13,563 frees, 5,933,134 bytes allocated
==15206==
==15206== 24 bytes in 1 blocks are still reachable in loss record 1 of 3
==15206== at 0x4A06409: malloc (vg_replace_malloc.c:270)
==15206== by 0x3014C612B2: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3015441B38: ??? (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x3015443A78: SSL_COMP_get_compression_methods (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x301544932B: SSL_library_init (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x4C340D4: libwebsocket_create_context (libwebsockets.c:1796)
==15206== by 0x401C08: main (in /usr/bin/libwebsockets-test-server)
==15206==
==15206== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==15206== at 0x4A06409: malloc (vg_replace_malloc.c:270)
==15206== by 0x3014C612B2: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3014CC91BE: sk_new (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3015441AF9: ??? (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x3015443A78: SSL_COMP_get_compression_methods (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x301544932B: SSL_library_init (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x4C340D4: libwebsocket_create_context (libwebsockets.c:1796)
==15206== by 0x401C08: main (in /usr/bin/libwebsockets-test-server)
==15206==
==15206== 32 bytes in 1 blocks are still reachable in loss record 3 of 3
==15206== at 0x4A06409: malloc (vg_replace_malloc.c:270)
==15206== by 0x3014C612B2: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3014CC91DC: sk_new (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3015441AF9: ??? (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x3015443A78: SSL_COMP_get_compression_methods (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x301544932B: SSL_library_init (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x4C340D4: libwebsocket_create_context (libwebsockets.c:1796)
==15206== by 0x401C08: main (in /usr/bin/libwebsockets-test-server)
==15206==
==15206== LEAK SUMMARY:
==15206== definitely lost: 0 bytes in 0 blocks
==15206== indirectly lost: 0 bytes in 0 blocks
==15206== possibly lost: 0 bytes in 0 blocks
==15206== still reachable: 88 bytes in 3 blocks
==15206== suppressed: 0 bytes in 0 blocks
Signed-off-by: Andy Green <andy.green@linaro.org>
This removes all the direct wsi members specific to clients,
most of them are moved to being fake headers in the next 3-layer
header scheme, c_port moves to being a member of the u.hdr
unionized struct.
It gets rid of a lot of fiddly mallocs and frees(), despite it
adds a small internal API to create the fake headers, actually
the patch deletes more than it adds...
Signed-off-by: Andy Green <andy.green@linaro.org>
This seems to be enough to get a clean valgrind run for the
test server with 1 x chrome and 1 x libwebsockets-test-client
session being run for 10s
lwsts[19767]: libwebsockets-test-server exited cleanly
==19767==
==19767== HEAP SUMMARY:
==19767== in use at exit: 0 bytes in 0 blocks
==19767== total heap usage: 41,071 allocs, 41,071 frees, 27,464,834 bytes allocated
==19767==
==19767== All heap blocks were freed -- no leaks are possible
==19767==
==19767== For counts of detected and suppressed errors, rerun with: -v
==19767== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
test client is another story...
Signed-off-by: Andy Green <andy.green@linaro.org>
To get a clean bill of health from valgrind, we have to have a way to
inform the user code that we're going down and it should free everything
it is holding that was malloc'd.
This patch introduces LWS_CALLBACK_PROTOCOL_DESTROY which each protocol
gets when the context is being destroyed and no more activity will come
after that call. They can get rid of everything there.
To match it, LWS_CALLBACK_PROTOCOL_INIT is introduced which would allow
one-time init per protocol too.
Signed-off-by: Andy Green <andy.green@linaro.org>
