It's going to be much easier to transition to lwsws
if the example config exactly matches what used to be
seen from the default test server.
# mkdir -p /etc/lwsws/conf.d /var/log/lwsws
# cp ./lwsws/etc-lwsws-conf-EXAMPLE /etc/lwsws/conf
# cp ./lwsws/etc-lwsws-conf.d-localhost-EXAMPLE /etc/lwsws/conf.d/test-server
# sudo lwsws
Signed-off-by: Andy Green <andy@warmcat.com>
Valgrind caught http/1.1 pipelining using dead user agent alloc
for logging... NULL it when we free it since the wsi can be
reused with keepalive
==16208== Invalid free() / delete / delete[] / realloc()
==16208== at 0x4847ACC: free (vg_replace_malloc.c:530)
==16208== by 0x4888DC3: _realloc (alloc.c:8)
==16208== by 0x4888DFF: lws_realloc (alloc.c:16)
==16208== by 0x487DBCB: lws_access_log (libwebsockets.c:2352)
==16208== by 0x48956DF: lws_http_transaction_completed (server.c:1245)
==16208== by 0x4893757: lws_http_serve (server.c:340)
==16208== by 0x48946EF: lws_http_action (server.c:748)
==16208== by 0x4894CEF: lws_handshake_server (server.c:900)
==16208== by 0x48786BF: lws_read (handshake.c:120)
==16208== by 0x4896103: lws_server_socket_service (server.c:1580)
==16208== by 0x487FB6B: lws_service_fd_tsi (service.c:779)
==16208== by 0x48803B7: lws_service_fd (service.c:1079)
==16208== Address 0x552e5f8 is 0 bytes inside a block of size 86 free'd
==16208== at 0x4847ACC: free (vg_replace_malloc.c:530)
==16208== by 0x4888DC3: _realloc (alloc.c:8)
==16208== by 0x4888DFF: lws_realloc (alloc.c:16)
==16208== by 0x487DBCB: lws_access_log (libwebsockets.c:2352)
==16208== by 0x48956DF: lws_http_transaction_completed (server.c:1245)
==16208== by 0x4893757: lws_http_serve (server.c:340)
==16208== by 0x48946EF: lws_http_action (server.c:748)
==16208== by 0x4894CEF: lws_handshake_server (server.c:900)
==16208== by 0x48786BF: lws_read (handshake.c:120)
==16208== by 0x4896103: lws_server_socket_service (server.c:1580)
==16208== by 0x487FB6B: lws_service_fd_tsi (service.c:779)
==16208== by 0x48803B7: lws_service_fd (service.c:1079)
==16208== Block was alloc'd at
==16208== at 0x4846498: malloc (vg_replace_malloc.c:298)
==16208== by 0x4848D57: realloc (vg_replace_malloc.c:785)
==16208== by 0x4888DA7: _realloc (alloc.c:6)
==16208== by 0x4888DFF: lws_realloc (alloc.c:16)
==16208== by 0x4893EAF: lws_http_action (server.c:565)
==16208== by 0x4894CEF: lws_handshake_server (server.c:900)
==16208== by 0x48786BF: lws_read (handshake.c:120)
==16208== by 0x4896103: lws_server_socket_service (server.c:1580)
==16208== by 0x487FB6B: lws_service_fd_tsi (service.c:779)
==16208== by 0x48803B7: lws_service_fd (service.c:1079)
==16208== by 0x48994B7: lws_io_cb (libuv.c:101)
==16208== by 0x4AE7B1F: ??? (in /usr/lib/libuv.so.1.0.0)
Signed-off-by: Andy Green <andy@warmcat.com>
https://github.com/warmcat/libwebsockets/issues/526
On master, cleanups and refactor mean the last two problems already
don't exist (array is gone from main.c and http.c is deleted)
Signed-off-by: Andy Green <andy@warmcat.com>
This is used to confirm that SSL client connections can coexist with
a vhost doing serving.
To set it up,
/*
* This is a bit fiddly...
*
* 0) If you want the wss:// test to work, make sure the vhost is marked with
* enable-client-ssl if using lwsws, or call lws_init_vhost_client_ssl() on
* the vhost if you're doing it by hand.
*
* 1) enable the protocol on a vhost
*
* "ws-protocols": [{
* "client-loopback-test": {
* "status": "ok"
* }, ...
*
* the vhost should listen on 80 (ws://) or 443 (wss://)
*
* 2) mount the http part of the test one level down on the same vhost, eg
* {
* "mountpoint": "/c",
* "origin": "callback://client-loopback-test"
* }
*
* 3) Use a browser to visit the mountpoint with a URI attached for looping
* back, eg, if testing on localhost
*
* http://localhost/c/ws://localhost
* https://localhost/c/wss://localhost
*
* 4) The HTTP part of this test protocol will try to do the requested
* ws client connection, to the same test protocol on the same
* server.
*/
Results should look like this
lwsws[29938]: client connection to localhost:443 with ssl: 1 started
lwsws[29938]: server part: LWS_CALLBACK_ESTABLISHED
lwsws[29938]: checking client ext permessage-deflate
lwsws[29938]: instantiating client ext permessage-deflate
lwsws[29938]: Client connection established
lwsws[29938]: Client connection received 7 from server 'Made it'
Signed-off-by: Andy Green <andy@warmcat.com>
Also add lwsws "enable-client-ssl": "1" vhost option to match.
Client cert iclient ssl is not supported in lwsws, if someone wants it, it can be added.
Signed-off-by: Andy Green <andy@warmcat.com>
Actually lwsws doesn't need his own protocol handler even for http
any more. The default http handler in lws should do everything.
Move the cgi routing into lws default http protocol handler, and
delete lwsws one. Remove all protocols from lwsws so the lws
default one gets used.
With this, and the earlier move of lejp into lws, lwsws itself
becomes 15.5KB of x86_64 (mainly conf parsing).
Signed-off-by: Andy Green <andy@warmcat.com>
lejp is already in lws as part of lwsws. However it's too generally useful
to just put directly in lwsws, it will lead to multiple copies of the source
in differet subprojects.
This moves it directly into lws, lwsws now gets it from there.
Like lwsws, by default at cmake it is disabled. Selecting LWS_WITH_LWSWS now
selects LWS_WITH_LEJP and you can set that at cmake individually as well.
Signed-off-by: Andy Green <andy@warmcat.com>
Until now lws has finished the HTTP transaction when the POST body was
completely received.
However that needlessly makes it impossible to send a HTTP 200 and a
response without a redirect.
This changes lws behaviour after sending the LWS_CALLBACK_HTTP_BODY_COMPLETION
callback to no longer terminate the HTTP transaction.
If you want the old behaviour, you can terminate the transaction with
lws_http_transaction_completed() in the LWS_CALLBACK_HTTP_BODY_COMPLETION
callback.
Otherwise it's now possible to call lws_callback_on_writable() from
LWS_CALLBACK_HTTP_BODY_COMPLETION.
Signed-off-by: Andy Green <andy@warmcat.com>
- libuv socket init binding was missing for client
- failures like no ws protocol match are deferred until the
ah is bound. Check for these failures and make sure we
tell the guy trying to set up the client connection the
wsi is NULL if it has already failed and closed.
- pfd.events was not initialized for the client init path
With this general client function is more robust but also
client connections work properly with libuv.
Signed-off-by: Andy Green <andy@warmcat.com>
If for some reason we exit before the protocol init action
(which is delayed for libuv) we should not send the protocol
destroy messages
Signed-off-by: Andy Green <andy@warmcat.com>
While checking with ab, I found
commit 30cdb3ac8f
Author: Justin Chen <justinchen00@github.invalid.com>
Date: Thu Apr 14 21:40:53 2016 +0800
recv treat zero return as error
https://github.com/warmcat/libwebsockets/issues/475
turned ab performance to crap, reverting it made everything fast again.
recv manpage says there is three ways to get zero returned
1) When a stream socket peer has performed an orderly shutdown, the return value will be 0 (the traditional "end-of-file"
return).
2) Datagram sockets in various domains (e.g., the UNIX and Internet domains) permit zero-length datagrams. When such a
datagram is received, the return value is 0.
3) The value 0 may also be returned if the requested number of bytes to receive from a stream socket was 0.
we can't just assume it means the peer shut down.
If the peer shut down, then the event loop should get an event on the socket like POLLHUP and deal with it that way.
So the patch mentioned above is simply reverted here.
Signed-off-by: Andy Green <andy@warmcat.com>
