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>
The client spams the server with mirror protocol content
and then closes the connection. However the server wants to
send that content back to all the mirror protocol
connections, including the one that closed.
The result is during the send back phase we usually see an
error trying to send to the close client connection. Because
we don't return -1, we don't close it on server side and the
error repeats a lot before finally closing. This is a side-
effect of a recent patch to drain pending input before
really closing a dead connection.
This patch just changes it to return -1 on the failed send
attempt assertively closing the connection.
Signed-off-by: Andy Green <andy.green@linaro.org>
This adds a demonstration of how to use the http nonblocking
send action to the test server.
If you ask for /leaf.jpg from the test server, it will send
"by hand" a 2.4MB jpeg in HTTP, including the headers. See
the test server sources to see how it is done.
Although it's a file, and a jpeg image, actually the exact
same scheme will work for any data or mime type.
Signed-off-by: Andy Green <andy.green@linaro.org>
This now exercises the code for dealing with rx that spills over
the rx buffer. Single fraggle uses the default rx buffer size
of 4096, it also now exercises code around that.
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>
Seems like it would be a good idea to try to mess with the
server at least before someone else does it for us
Just run the script
$ test-server/attack.sh
it will spawn a test server and fire things at it. If you
see the end result
---- survived
then you should be OK.
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>
