Hello, I have certificates generated by letsencrypt to point to my domain which I'm using for secure websocket connections.
I'm using the tls context as such

uS::TLS::Context tls = uS::TLS::createContext("cert.pem", "key.pem");
if (h.listen(7070,tls)) {
h.run();
}
But when I run my websocket client code:

ws = new WebSocket("wss://domain.pw:8080");

Chrome gives me this error:
failed: Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR

Unfortunately uWebSockets does not give any indication of whether the certificate and key were available or read properly.

The certificate could be a problem because it seems there's two certificates in cert file.

-----BEGIN CERTIFICATE-----
.....
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

And I'm not sure which one to remove or keep or use both. But when I try visiting the ip address of the domain directly over https while the server is running, I can view the certificate in the browser and the certificate is valid. Which leads me to believe that uWebSockets is loading the certificate but for some reason wss connections can't be made.

You should never need GBs of backpressure but performance is nevertheless horrible in these cases.

substr for every sent chunk is a very bad strategy and should prefer keeping large buffers intact instead.

Only substr smaller backpressure, keep large buffers as is.

How to post bug reports

Strict policy: chat in open issues, do not open issues to chat.

• This is not a place for Q&A. Do not open new issues to chat about stuff and ask questions.
• No free support, do not ask for help.
• If there's already an open issue you may chat about that issue, in that issue.
• If there's not an issue open for your topic, do not open a new one just to chat or ask questions.
• New issues need to be strictly bug reports.

What is a bug report?

• Do not post anything tied to build systems, building errors, linker errors, compilation errors.
• Anything closed stays closed. No comments needed.
• Invalid issues are closed with no comments.
• If you cannot show an easy to reproduce problem it gets closed.
• "It crashes" is not a valid bug report.

Do not assume, demand or require anything. You are not in position to demand anything and any such behavior is instantly and permanently banned without any comments. You are invited to my home and I will toss you head first out if you act like a clown.

Sliding and non-sliding window like in v0.14

We could simply store all routes in a vector of pairs, then at some final moment sort them by length (number of segments) and build the route tree with shorter routes added before longer ones.

This would solve many matching surprises.

When responding to a req and the data is null or an empty string, the server takes a very long time to timeout (9 seconds or so). I was wondering if there is a way to set a timeout or maybe res.end() does not behave as intended.

Most requests are GET, and GET have negligible size, making them suitable to buffer, rather than introduce complex buffering of the response (which can be huge).

It's also very simple to implement when you just buffer up the input, we already have a buffer for that.

Otherwise complex and inefficient hierarchy of HttpSocket -> HttpResponse(s) need to be built. And all browsers disable pipelining anyways, it's more of an edge case.

Buffering up the input is easy to track, if it reaches more than say 8kb just terminate the connection.

Simple, and you can completely disable pipelining without any buffering by just terminating the connection if you get a new request before having responded to the previous (a sane behavior in modern day).

It should not trigger double-free after being copied, etc. Probably should have some kind of simple reference counting or maybe not be copyable at all:

auto app = uWS::App(...

Above code breaks due to double-free.

App.h

Do you have multithreading example for new version on Windows platform?

Hi
How can I prevent this error in https connection in Safari.

WebSocket - Safari - Invalid UTF-8 sequence in header value

as option to context

If a "websocket route" is not a websocket connection, it should be caught by the next .get handler.

In a sense, the router needs to be able to continue to the next get route from the one picked if needed.

Minor thing

Apologies if I missed it, but I can't find a way to read the request body (the data after the headers) in HttpRequest.

This would be needed in handling POST/PUT/... requests.

Thanks in advance

When I want to create more than one instance of app. So I need include App.h in more than one xxx.cpp,
But that cause ExtensionsParser::ExtensionsParser(...) redefined, and I find class ExtensionsParser's member function declare and definition are both in WebSocketExtensions.h file. Does that because of new branch was designed for head only library, so do like this ?

I download 0.15.x release and decompression it, but the uSockets folder in the 0.15.x is empty. Would you download it or use git clone --recursive first and pack it later?

Current WebSocketContext behavior is not correct and needs to be thoroughly fixed.

It seems Http parsing is completely broken, passing request in parts does not work. The Http parser itself works, but somehow the fallback buffer does not persist across data events.

Something is clearing the buffer every request.

Hi all,

I want to compile the uWebSockets and use it in mobile platform (iOS, Android) and macOS.
And I change the uWebSockets to :

main:
	clang -flto -DLIBUS_NO_SSL -DLIBUS_USE_LIBUV -luv -c -IuSockets/src uSockets/src/*.c uSockets/src/eventing/*.c
	clang++ -flto -luv -DLIBUS_NO_SSL -DLIBUS_USE_LIBUV -c -std=c++11 -Isrc -IuSockets/src misc/main.cpp
	clang++ -flto -luv -DLIBUS_NO_SSL -DLIBUS_USE_LIBUV *.o -o Main -lssl -lcrypto -lpthread -lz
	rm *.o

then run make main:

In file included from misc/main.cpp:1:
In file included from src/App.h:24:
In file included from src/HttpContext.h:23:
In file included from src/Loop.h:23:
In file included from src/LoopData.h:28:
src/f2/function2.hpp:235:11: error: 'auto' return without trailing return type; deduced return types are a C++14 extension
constexpr auto overload(T&&... callables) {
          ^
src/f2/function2.hpp:236:29: error: no template named 'decay_t' in namespace 'std'; did you mean 'decay'?
  return overload_impl<std::decay_t<T>...>{std::forward<T>(callables)...};
                       ~~~~~^~~~~~~
                            decay
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1351:29: note: 'decay' declared here
struct _LIBCPP_TEMPLATE_VIS decay
                            ^
In file included from misc/main.cpp:1:
In file included from src/App.h:24:
In file included from src/HttpContext.h:23:
In file included from src/Loop.h:23:
In file included from src/LoopData.h:28:
src/f2/function2.hpp:265:30: error: no template named 'enable_if_t' in namespace 'std'; did you mean 'enable_if'?
struct address_taker<T, std::enable_if_t<std::is_pointer<T>::value>> {
                        ~~~~~^~~~~~~~~~~
                             enable_if
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:435:63: note: 'enable_if' declared here
template <bool, class _Tp = void> struct _LIBCPP_TEMPLATE_VIS enable_if {};
                                                              ^
In file included from misc/main.cpp:1:
In file included from src/App.h:24:
In file included from src/HttpContext.h:23:
In file included from src/Loop.h:23:
In file included from src/LoopData.h:28:
src/f2/function2.hpp:315:43: error: no template named 'decay_t' in namespace 'std'; did you mean 'decay'?
      typename std::allocator_traits<std::decay_t<Allocator>>::
                                     ~~~~~^~~~~~~
                                          decay
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1351:29: note: 'decay' declared here
struct _LIBCPP_TEMPLATE_VIS decay
                            ^
In file included from misc/main.cpp:1:
In file included from src/App.h:24:
In file included from src/HttpContext.h:23:
In file included from src/Loop.h:23:
In file included from src/LoopData.h:28:
src/f2/function2.hpp:338:52: error: no template named 'decay_t' in namespace 'std'; did you mean 'decay'?
          typename Allocator = std::allocator<std::decay_t<T>>>
                                              ~~~~~^~~~~~~
                                                   decay
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1351:29: note: 'decay' declared here
struct _LIBCPP_TEMPLATE_VIS decay
                            ^
In file included from misc/main.cpp:1:
In file included from src/App.h:24:
In file included from src/HttpContext.h:23:
In file included from src/Loop.h:23:
In file included from src/LoopData.h:28:
src/f2/function2.hpp:339:1: error: 'auto' return without trailing return type; deduced return types are a C++14 extension
auto make_box(std::integral_constant<bool, IsCopyable>, T&& value,
^
src/f2/function2.hpp:341:31: error: no template named 'decay_t' in namespace 'std'; did you mean 'decay'?
  return box<IsCopyable, std::decay_t<T>, std::decay_t<Allocator>>{
                         ~~~~~^~~~~~~
                              decay
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1351:29: note: 'decay' declared here
struct _LIBCPP_TEMPLATE_VIS decay
                            ^
In file included from misc/main.cpp:1:
In file included from src/App.h:24:
In file included from src/HttpContext.h:23:
In file included from src/Loop.h:23:
In file included from src/LoopData.h:28:
src/f2/function2.hpp:341:48: error: no template named 'decay_t' in namespace 'std'; did you mean 'decay'?
  return box<IsCopyable, std::decay_t<T>, std::decay_t<Allocator>>{
                                          ~~~~~^~~~~~~
                                               decay
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1351:29: note: 'decay' declared here
struct _LIBCPP_TEMPLATE_VIS decay
                            ^
In file included from misc/main.cpp:1:
In file included from src/App.h:24:
In file included from src/HttpContext.h:23:
In file included from src/Loop.h:23:
In file included from src/LoopData.h:28:

Would you like to support compiling uWebSockets with c++11 ?
Thanks,

keepAliveTimeout should be low 10 seconds
streamTineout should be high 300 seconds

They should be settable in App constructor

onData streaming should have timeout and should always end with isLast immediately if there is no data

I hope that there is a golang library exported. Any plan to make a go wrapper for this library that is ready to deploy and no need to do CGO.

Seems to be part of the uWS.js (windows) binaries v0.0.8 and is currently logging on every websocket disconnect.

When I try to use uWS14.xx with one uS::Async object by define MACRO USE_LIBUV, program crashed in uS::Async::start(...) function, with stack info is:
Program received signal SIGSEGV, Segmentation fault.
0x00005555556bf49f in uv_async_init (loop=0x5555559872e0, handle=0x7fffffffdd30,
async_cb=0x555555582b1d <<lambda(uS::Async*)>::_FUN(uS::Async )>)
at /root/source/vcpkg/buildtrees/libuv/src/v1.25.0-b119df65cf/src/unix/async.c:48
48 uv__handle_init(loop, (uv_handle_t)handle, UV_ASYNC);
(gdb) bt
#0 0x00005555556bf49f in uv_async_init (loop=0x5555559872e0, handle=0x7fffffffdd30,
async_cb=0x555555582b1d <<lambda(uS::Async*)>::_FUN(uS::Async )>)
at /root/source/vcpkg/buildtrees/libuv/src/v1.25.0-b119df65cf/src/unix/async.c:48
#1 0x00005555555834fd in uS::Async::start (this=0x7fffffffdd30,
cb=0x555555582b1d <<lambda(uS::Async)>::_FUN(uS::Async *)>)
at /root/source/vcpkg/installed/x64-linux/include/uWS/Libuv.h:41

libuv version is 1.25.0

ok and hasResponded,

You need to check hasResponded and treat that as "done event".

is it possible to add some priority to existing websocket so if a few messages got packets the ones with priority will get handled first ?

std functions are incorrect

Look for releases here on GitHub (releases are git tags). There you can determine what version to use.

Master branch can at times be completely broken (not even compile). This should not be the case for releases.

WebSocket send should probably work like Http streams by returning true/false and then have a separate drain event.

Apparently libuv expects you to wait for all handles to finish and not have any data left before destruction. Otherwise it will assert in uv_loop_close(). The Loop class doesn't do that, so I'm hitting the asserts on server teardown.

(We have to use libuv on iOS and macOS as epoll doesn't exist there -- which is why it took us a while to notice)

We're currently doing the following on libuv platforms:

auto loop = hub_.getLoop();

uv_stop(loop);

while (uv_run(loop, UV_RUN_DEFAULT) != 0) {
       ;
}

assert(!uv_loop_alive(loop));

Any chance of getting that added to the libuv uWS::Loop destructor?

Note: This may not be 100% correct, TSAN complains that this code is happening in the wrong thread for me right now, so you may have to have the actual uv_run() happen in another thread and just have the destructor wait on that.

How does this compare to the Techempower Benchmark? It's kinda hard to believe the benchmarks you have provided - the source code is incomplete (it lacks code for other HTTP libs).

It needs to be configurable and overall fixed up.

Adopting a socket should not change any uSockets polling state.

If backpressure, move that to adopted socket.

Deconstruct HttpResponseData.

v0.14. A multithreaded call to close crashes. Review code, webSocket list has no locks, timer has no locks, close() do not support multithreading. How do I resolve a multithreaded call to close?Use uS::Async close()?

Zlib should be optional and never required to build the project
OpenSSL should also be optional and not required to build the project

Removing or adding any of them should work, with limited features as follows

server code is written by c++11, can you provide a library support c++11

Should be added in µSockets and hooked up here.

Alignment of websocket user data is given by LIBUS_EXT_ALIGNMENT, which is 16 by default.

Using user data with stricter alignment requirements is not going to be properly honored.

Maybe it makes sense to swap away from passing a user data type, to just passing a size. That way users can't be fooled by ignored alignment requirements.

Most of the time, this will never be an issue though, and you can easily use user data with a pointer to aligned memory if needed, or just recompile uSockets with changed alignments.

Some memory leaks are left, needs fixing. Should exit gracefully with no ASAN leaks after Autobahn and tons of various testing.

App destructor should clean everything up, except for some things attached to the Loop which should destruct in Loop destructor

I'm wondering if it would make sense to transfer ownership to ASF:

• Apache 2.0 is permissive enough, even for a fork.
• I cannot sign it away via bad contracts - nobody can say "hey, we own this because this and that".
• ASF have legal powers to sue people who act like assholes.
• I'm getting bored with web dev..?

In the scenario where we need to:

1. Receive a request
2. Do some work
3. Redirect that request somewhere else

I'm seeing very sluggish performance (some seconds in fact)

I suspect it's my own fault. On a NodeJS Http (or Polka) server I normally do:

res.writeHead(302, {'Location', 'http://some-other-url'})

and the performance is acceptable. On UWebSockets.js I'm trying as follows:

res.writeStatus('302')
res.writeHeader('location', ''http://some-other-url')
res.end()

but the delay is palpable. Is there a better approach?

I've had stubborn issue reports stating this server is slow at making SSL connections. It was later clarified that issue reporter had compared a 2048 bit key with the default 4096 key from this repo. Here's a graph showing the major difference in CPU load per SSL handshake per key length:

If you're going to compare things, compare apples to apples please.

I understand via #801 that you aren't too keen on using server-side ping/pong as a keep-alive and prefer client-side keep alive. That approach makes sense, and I buy the argument completely.

The problem is that pong appears to be completely disabled after v0.14 for some reason. This prevents systems that do rely on the spec's ping-pong control packets from working properly with uWebSockets.

In my particular case, I want to test swapping in uWebSockets instead of one of the competing libraries that is in your benchmark graph. I am using ping/pong, and I have a million+ shipped clients that cannot be quickly ported to client-side keep-alive.

Any good reason why pong is disabled? It would be better to be compliant to the RFC. I'm happy to enabled it, but I won't send a PR if you have a reason.