While going off of the VideoStreamer example to implement reading from a read stream, I'm hitting into a segfault. The example code alone is enough to cause this, so you should be able to repro on that alone. I've noticed that adding console.logs in a bunch of places (to try and figure out which call to any uWS function causes it, no luck) made the issue less common. Some kind of race condition perhaps...?

Is the VideoStreamer example still correct, or should reading from a large stream be implemented differently?

Exception thrown at 0x00000001402068F2 in node.exe: 0xC0000005: Access violation reading location 0x0000005F656C6309.

I'm running Node v16.14.2 on Windows, and uWS.js 20.8.0.

I'm trying to use the library in a worker thread, but I can't seem to do a graceful shutdown when the worker dies due to an uncaught exception. I've tried as many ways to handle this case as I could find, I'm not sure if this is a mistake on my end, maybe I'm missing something.

I'm using Node 15.10.0, and uWS.js 18.14.0 on Win10, here's the code:

const uWS = require('uWebSockets.js');
const { Worker, isMainThread, threadId, parentPort } = require('worker_threads');
const os = require('os');
const port = 9001;
if (isMainThread) {
    const workers = /* os.cpus() */[0].map(() => {
        return new Worker(__filename);
    });
    function cleanup() {
        workers.forEach((worker) => {
            worker.postMessage('cleanup'); // too late
        });
    };
    process.on('uncaughtException', cleanup);
} else {
    let listenSocket;
    const app = uWS.App({}).listen(port, (token) => {
        listenSocket = token;
        if (token) {
            console.info(`${threadId} listening on ${port}`);
            performance.now(); // this will throw
        } else {
            console.error(`${threadId} failed listening on ${port}`);
        }
    });
    parentPort.on('message', (value) => {
        if (value === 'cleanup') {
            shutdown();
            process.exit(0);
        }
    });
    function shutdown() {
        if (listenSocket) {
            uWS.us_listen_socket_close(listenSocket);
            listenSocket = null;
        }
    }
}

The call to performace.now() is not valid, because performance must be imported from perf_hook, so it will throw a ReferenceError. The uncaught exception is handled by cleanup, but at this point, the worker is already terminated, so it can't respond to the cleanup message.

Here's the output:

1 listening on 9001
uv loop at [0000007BD97FF798] has open handles:
[000001D2F1E59F90] poll (active)
        Close callback: 0000000000000000
        Data: 0000000000000000
uv loop at [0000007BD97FF798] has 1 open handles in total
C:\Program Files\PowerShell\7\pwsh.exe[5036]: c:\ws\src\debug_utils.cc:322: Assertion `0 && "uv_loop_close() while having open handles"' failed.
 1: 00007FF779D5066F public: static int __cdecl v8::internal::Isolate::ArchiveSpacePerThread(void)+4607
 2: 00007FF779CE4A46 SSL_get_quiet_shutdown+65190
 3: 00007FF779CE4DC1 SSL_get_quiet_shutdown+66081
 4: 00007FF779D50334 public: static int __cdecl v8::internal::Isolate::ArchiveSpacePerThread(void)+3780
 5: 00007FF779C2287D public: void __cdecl v8::internal::wasm::SignatureMap::Freeze(void) __ptr64+35901
 6: 00007FF779C1DCB8 public: void __cdecl v8::internal::wasm::SignatureMap::Freeze(void) __ptr64+16504
 7: 00007FF779D985FD uv_poll_stop+557
 8: 00007FF77ABBE0B0 public: class v8::internal::compiler::Operator const * __ptr64 __cdecl v8::internal::compiler::RepresentationChanger::Uint32OverflowOperatorFor(enum v8::internal::compiler::IrOpcode::Value) __ptr64+398416
 9: 00007FFCA3027034 BaseThreadInitThunk+20
10: 00007FFCA3C1D0D1 RtlUserThreadStart+33

I looked through the issues, and it is similar to #324. Could this be the same problem?

Hi. Please, correct me, if I am mistake. You are always trying to decode header to utf8 when getHeader() called. This is not quite correct and can lead to loose header value. According to the spec http headers can be us-ascii strings only. Some headers can be specially encoded and decoded by user. But application server must always return ascii strings. Look at example below, value of utf header is lost.

#!/usr/bin/env node

import http from "node:http";
import uws from "uWebSockets.js";

const app = uws.App().get( "/*", ( res, req ) => {
    console.log( "-- ascii:", req.getHeader( "ascii" ) );
    console.log( "-- utf:", req.getHeader( "utf" ) );

    res.end();
} );

await new Promise( resolve => app.listen( 80, resolve ) );

http.request( "http://127.0.0.1/",
    {
        "headers": {
            "ascii": "test",
            "utf": Buffer.from( "тест" ).toString( "binary" ),
        },
    },
    res => {
        process.exit();
    } ).end();

Is it possible to add autoPingTime work with idleTimeout in WebSocketBehavior config ? like this:

/** Maximum amount of seconds that may pass without sending or getting a message. Connection is closed if this timeout passes. Resolution (granularity) for timeouts are typically 4 seconds, rounded to closest.
     * Disable by leaving 0.
     */
idleTimeout: 250,
/** auto send ping to remote client interval time (seconds) 
     * the response pong will auto refresh idleTimeout, make sure remote client is alive
     * Disable by leaving 0.
     */
autoPingTime: 120,

This can make sure remote client is alive especially in mobile network.

Right now i'm recording all websocket, loop sending ping and handle pong at nodejs APP layer. If this feature can be add to uWebSockets core layer, maybe the performance will be better and APP layer will be easier.

uWebSockets works great. But the sever shuts down irregularly with the error below. Is there any clue for me to find out what can I do?

#                                                                                                       
# Fatal error in , line 0                                                                               
# Check failed: receiver.IsJSFunction().                                                                
#                                                                                                       
#                                                                                                       
#                                                                                                       
#FailureMessage Object: 000000EE276FDD50                                                                
 1: 00007FF6BA7B380F napi_wrap+128063                                                                   
 2: 00007FF6BA6FA4BF v8::internal::wasm::JSToWasmWrapperCompilationUnit::~JSToWasmWrapperCompilationUnit
8047                                                                                                    
 3: 00007FF6BB127254 V8_Fatal+212                                                                       
 4: 00007FF6BACC2A88 v8::internal::JSReceiver::GetCreationContext+360                                   
 5: 00007FF6BAF4F260 v8::Object::CreationContext+32                                                     
 6: 00007FF6BA7D0218 node::MakeCallback+40                                                              
 7: 00007FFF735345C8 us_poll_resize+5192                                                                
 8: 00007FFF7353F15F node_register_module_v72+40479                                                     
 9: 00007FFF7355675F node::ArrayBufferAllocator::operator=+4159                                         
10: 00007FFF735466C4 node_register_module_v72+70532                                                     
11: 00007FF6BAF1DDB0 v8::internal::Builtins::builtin_handle+323456                                      
12: 00007FF6BAF1D2F7 v8::internal::Builtins::builtin_handle+320711                                      
13: 00007FF6BAF1D638 v8::internal::Builtins::builtin_handle+321544                                      
14: 00007FF6BAF1D43E v8::internal::Builtins::builtin_handle+321038                                      
15: 00007FF6BB3B50AD v8::internal::SetupIsolateDelegate::SetupHeap+546893                               
16: 00007FF6BB339F5C v8::internal::SetupIsolateDelegate::SetupHeap+42748                                
17: 00007FF6BB337491 v8::internal::SetupIsolateDelegate::SetupHeap+31793                                
18: 00007FF6BB33707C v8::internal::SetupIsolateDelegate::SetupHeap+30748                                
19: 00007FF6BAE77E03 v8::internal::Execution::CallWasm+1395                                             
20: 00007FF6BAE77786 v8::internal::Execution::Call+182                                                  
21: 00007FF6BAF487FD v8::Function::Call+605                                                             
22: 00007FF6BA7CFDF8 node::CallbackScope::~CallbackScope+1448                                           
23: 00007FF6BA7D02B7 node::MakeCallback+199                                                             
24: 00007FFF735345C8 us_poll_resize+5192                                                                
25: 00007FFF7353F841 node_register_module_v72+42241                                                     
26: 00007FFF73561570 uWS::WebSocketProtocol<1,uWS::WebSocketContext<1,1> >::getOpCode+8864              
27: 00007FFF7353F212 node_register_module_v72+40658                                                     
28: 00007FFF73561149 uWS::WebSocketProtocol<1,uWS::WebSocketContext<1,1> >::getOpCode+7801              
29: 00007FFF7353CC64 node_register_module_v72+31012                                                     
30: 00007FFF7355BB45 uWS::WebSocketProtocol<1,uWS::WebSocketContext<0,1> >::consumeContinuation+901     
31: 00007FFF735565AC node::ArrayBufferAllocator::operator=+3724                                         
32: 00007FFF735340AE us_poll_resize+3886                                                                
33: 00007FFF73532370 us_loop_iteration_number+1280                                                      
34: 00007FF6BA7ED0C6 uv_spawn+2022                                                                      
35: 00007FF6BA7FC9CC uv_loop_init+1244                                                                  
36: 00007FF6BA7FCB74 uv_run+244                                                                         
37: 00007FF6BA71AF13 v8::internal::Scope::locals+31043                                                  
38: 00007FF6BA77A5A3 node::Start+275                                                                    
39: 00007FF6BA6267AC RC4_options+339628                                                                 
40: 00007FF6BB46BFD8 v8::internal::SetupIsolateDelegate::SetupHeap+1296248                              
41: 00007FFF87E77BD4 BaseThreadInitThunk+20                                                             
42: 00007FFF88E4CE51 RtlUserThreadStart+33         

Server currently shuts down when there is an error, which is not preferable for a robust application.

Also there is no stack trace in error shown, so it is hard to debug.

A couple of years ago, the developers of the node added a reasonable way to read a socket from a static buffer. This reduces memory allocations for temporary buffer copies and reduces work GC. https://github.com/nodejs/node/pull/25436

Does this make sense, for read HTTP body? If yes, I suggest adding an onRead handler, making the interface the same as in Node.js https://nodejs.org/api/net.html#net_socket_connect_options_connectlistener

{
  ...,
  onread: {
    // Reuses a 4KiB Buffer for every read from the socket.
    buffer: Buffer.alloc(4 * 1024),
    callback: function(nread, buf) {
      // Received data is available in `buf` from 0 to `nread`.
      console.log(buf.toString('utf8', 0, nread));
    }
  }
});

Are you planning on implementing app.use functionality in the router?

app.use((req, res, next)=>{ next() })  

app.use('/path', handler)

This would make it possible for developers to easily replace their current framework such as polka with µWS.

I'm using uWebsockets.js to communicate between servers, and i got this error:

"Cork buffer must not be held across event loop iterations!"

What exactly can cause this error in my js code?

Because of native nature of your library it's impossible for IDEs to list methods of req and res objects. Also it's impossible to get methods and properties of this objects via Object.enties or Object.keys.

So the question is where to find an uWS's HTTP API reference?

The PR changes the WebSocket type definition to allow for an optional type argument that allows for strictly defined WebSocket user data.

Previously, when you extended the WebSocket object in TypeScript, you did not get the benefit of the typing:

interface ExtendWebSocket extends WebSocket {
  username: 'biw'
}

uWebSockets.App().ws('/*', {
  open: (ws: ExtendWebSocket) => {
    ws.username = 'biw'
   
    // no error for key not in ExtendWebSocket
    ws.token = '123'
  },

With this change, you have the option for more strict type checking:

interface ExtendValues {
  username: 'biw'
}

uWebSockets.App().ws('/*', {
  open: (ws: ExtendWebSocket<ExtendValues>) => {
    ws.username = 'biw'
   
    // will throw typescript error for undefined key
    ws.token = '123'
  },

The default behavior is still the same and non-breaking:

uWebSockets.App().ws('/*', {
  open: (ws) => {
    // no typescript errors for either
    ws.username = 'biw'
    ws.token = '123'
  },

Happy to make any changes you'd like, just let me know!

• can't find the way to use "Cloudflare Origin Certificate"
• use then blocking IP list provided by Cloudflare that ignore many Asian exit countrys Siggapur,Thailand,Laos,Vietnam i.e missing 172.68.6.144 from cloudflare.com/ips/
• try to contact this m-o-r-o-n-s from Cloudflare like year ago but they don't provide basic support as is too expensive

What is my problem:

• need somehow hide my server identify by verify hash of cloudflare certyficate or some basic details about cert

// example nanoexpress use: uWebSockets.js
app.get('/24325325141', async (req, res) => {
       // this is a dummy - users from google please ignore
	res.end( req.cert.CommonName == 'sni.cloudflaressl.com' );

})

Hi @uNetworkingAB

I'm trying to run HTTP3 server but it does not work. Here minimal repo to reproduce: https://github.com/nanoexpress/http3-uws

Steps to reproduce

• Follow steps Open in VSCode from README
• Opening in browser local url with port, e.g. https://localhost:50624/

Actual

Expected

Working web-server with response of H3llo World!

Hi, I am getting this error Error: This version of µWS is not compatible with your Node.js build: after upgrading to 20.6.0.

I am running node v14.17.0

What is the new node version requirement?