This gets rid of all the platform-dependent #ifdef stuff and
migrates it into the new lws-plat-xxx.c files.
These are then included in a one-time test in libwebsockets.c
according basically to Windows or not.
The idea is from now on, all Windows-specific code should go in
lws-plat-win.c, where any kind of Windows perversion like DWORD
is fine.
Any new functions going in there should be named lws_plat_...
and be defined in all the lws-plat-xxx.c file (currently just
win32 and unix platforms are supported).
Signed-off-by: Andy Green <andy.green@linaro.org>
merged by andy@warmcat.com via https://github.com/gaby64/libwebsockets-libev
To use, you need to both
- cmake ---> -DLWS_USE_LIBEV=1
- info->options must have LWS_SERVER_OPTION_LIBEV set when creating the context
this is so a single library can be built for distros to support apps that use
normal polling and apps that use libev polling.
Also change from looking at wsi->truncated_send_malloc to see if we are in the middle of
dealing with a truncated send to looking for nonzero wsi->truncated_send_len
Signed-off-by: Andy Green <andy.green@linaro.org>
Add a special implementation with CreateFile(), ReadFile() and CloseFile()
for serving HTTP file request to allow compilation on all Windows platforms.
Add a new function to get the current time in microseconds, since gettimeofday() does not exist on Windows.
Keep the current implementation for the test applications.
To enable this code you need to force LWS_HAS_PPOLL to de defined.
#defining it at the top of libwebsockets.c is enough.
Signed-off-by: Andy Green <andy.green@linaro.org>
This provides a single place for pollfd event changing,
external locking for that and extpoll management.
It saves about 85 lines of duplication and simplifies the callers.
Signed-off-by: Andy Green <andy.green@linaro.org>
If enabled one listening socket will accept both SSL and plain HTTP connections.
Do not enable if you regard SSL handshake as some kind of security, eg, use
client-side certs to restrict access.
AG: changed flag names, added extra comments, changelog, add -a in test server
Signed-off-by: James Devine <fxmulder@gmail.com>
Signed-off-by: Andy Green <andy@warmcat.com>
This patch deploys the truncated send work to buffer output in case
either send() or the SSL send return a temporary "unable to send"
condition even though they signalled as writeable.
I added a by-default #if 0 test jig which enforces only half of what
you want to send is sendable, this is working when enabled.
One subtle change is that the pipe reports choked if there is any
pending remaining truncated send. Otherwise it should be transparent.
Hopefully...
Signed-off-by: Andy Green <andy.green@linaro.org>
If the URI coming from the client contains '?' then
- the URI part is terminated with a '\0'
- the remainder of the URI goes in a new header WSI_TOKEN_HTTP_URI_ARGS
- the remainder of the URI is not subject to path sanitization measures (it
still has %xx processing done on it)
In the test server, http requests now also dump header information to stderr.
The attack.sh script is simplified and can now parse the test server header dumps.
Signed-off-by: Andy Green <andy.green@linaro.org>
This translates %xx in the GET uri and removes /.. and /... type sequences along with
translating // or /// etc to /.
Since the result is hopefully secure, it also changes the test server to actually use
the uri path pasted on a resource directory without whitelisting.
Signed-off-by: Andy Green <andy.green@linaro.org>
I don't see a wsockcompat.h anywhere in MSVC9 or MSVC8 and their
corresponding sdk's. It does not seem like this is a standard windows
header, so better drop that and add the compat-defines to the same
place that already has other WSA compat defines.
Using Windows 7 64 bit, cloned repo on 20130926. Using Qt creator and Microsoft Visual C++ Compiler 9.0 (x86).
Result (errors from compile output): D:\Projects\CDPStudioAPI\libwebsockets_orig\lib\client-handshake.c:87: error: C2065: 'EALREADY' : undeclared identifier
D:\Projects\CDPStudioAPI\libwebsockets_orig\lib\client-handshake.c:87: error: C2065: 'EINPROGRESS' : undeclared identifier
Possible solution is to use wsockcompat.h (compatibility header for using EALREADY, EINPROGRESS etc in older versions of Windows SDK). Compiled fine when I #included wsockcompat.h into client-handshake.c
Reported-by: mart22n via Trac 41
Signed-off-by: Andy Green <andy.green@linaro.org>
Subject: [PATCH] We can ran into situation (at least on iOS) when with openssl
nonblocking BIO and http proxy we don't perform ssl_connect straight away so
we need to retry until we finish ssl_connect. If we don't do that we will
fail in LWS_CONNMODE_WS_CLIENT_WAITING_PROXY_REPLY when testing for "HTTP/1.0
200" successful connection.
Signed-off-by: shys <shyswork@zoho.com>
This patch adds code to handle the situation that a prepared user buffer could not all be sent on the
socket at once. There are two kinds of situation to handle
1) User code handles it: The connection only has extensions active that do not rewrite the buffer.
In this case, the patch caused libwebsocket_write() to simply return the amount of user buffer that
was consumed (this is specifically the amount of user buffer used in sending what was accepted,
nothing else). So user code can just advance its buffer that much and resume sending when the socket
is writable again. This continues the frame rather than starting a new one or new fragment.
2) The connections has extensions active which actually send something quite different than what the
user buffer contains, for example a compression extension. In this case, libwebsockets will dynamically
malloc a buffer to contain a copy of the remaining unsent data, request notifiction when writeable again,
and automatically spill and free this buffer with the highest priority before passing on the writable
notification to anything else. For this situation, the call to write will return that it used the
whole user buffer, even though part is still rebuffered.
This patch should enable libwebsockets to detect the two cases and take the appropriate action.
There are also two choices for user code to deal with partial sends.
1) Leave the no_buffer_all_partial_tx member in the protocol struct at zero. The library will dyamically
buffer anything you send that did not get completely written to the socket, and automatically spill it next
time the socket is writable. You can use this method if your sent frames are relatvely small and unlikely to get
truncated anyway.
2) Set the no_buffer_all_partial_tx member in the protocol struct. User code now needs to take care of the
return value from libwebsocket_write() and deal with resending the remainder if not all of the requested amount
got sent. You should use this method if you are sending large messages and want to maximize throughput and efficiency.
Since the new member no_buffer_all_partial_tx will be zero by default, this patch will auto-rebuffer any
partial sends by default. That's good for most cases but if you attempt to send large blocks, make sure you
follow option 2) above.
Signed-off-by: Andy Green <andy.green@linaro.org>
As spotted by JM on Trac#40
http://libwebsockets.org/trac/libwebsockets/ticket/40
client connect didn't do anything about being truly nonblocking. This patch
should hopefully solve that.
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>
- 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.
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>
