I've already found Event loop for large files?, but it's mostly about downloads. The conclusion I take from that post is node.js might have been adequate for downloads, but Nginx is a battle-hardened solution that "ain't broke."
But what about uploads? We have enormous files being uploaded. We do genomics, and human genome datasets are as much as 200GB in size. As far as I've been able to determine, Nginx always buffers the complete request, header and body, before forwarding it to a back-end. We've run out of memory handling three uploads at the same time.
We have a swarm of small, "does one thing and does it well" servers running in our application, one of which handles the uploads (and type transformations to an in-house format) of the genomic data, and another of which provides socket.io handling to keep customers appraised of both upload progress and other events going on in our application's ecology. Others handle authentication, customer data processing, and plain 'ol media service.
If I'm reading the code for node's http/https modules right, node.js would be an ideal tool for handling these issues: it speaks HTTP/1.1 natively, so the websockets passthrough would work, and it hands the (request, response)
tuple to the handler function after processing the HTTP HEAD but holding off on the BODY until the handler function binds request.on('data', ...)
events to drain the BODY buffer.
We have a well-segmented, url-based namespace for our services: "/import," "/events", "/users", "/api", "/media", etc. Nginx only handles the last three correctly. Would it be difficult or inappropriate to replace Nginx with a node.js application to handle all of them? Or is there some obscure reverse proxy (Nginx, Pound, and Varnish all have similar limitations) that already does everything I want?