How to go about tracking down this error?

the last binary/build that I can use is e54a6b982545da111b2f24d725fb30b0279c11da­

I made some changes that should have generally increased speed/efficiency, but I tested them last night with a Pico and ESP8266 and they worked fine. And just tested them again, and they still work. Maybe it's the builds... I'll check.

It looks like the implementation is still unfinished

Any reason? Looks like I left that debug print in by accident though - it's fixed now.

Odd about the pipe ending - it's supposed to close when the close event is sent. That works when running a build on the PC, but it looks like on the Pico characters still get lost, and so the amount of data received doesn't equal content length. You could probably check that? global["\xFF"].HttpSC contains info about currently open connections - you should see cRcv in there as well as the Content-Length header.

If you run E.getErrorFlags() you might see a FIFO_FULL message - which means that the input FIFO has overrun and lost data.

can the (new) chunksize parameter be user-definable

I don't think that would help? When I looked at the data flowing through the system on my build it only seems to be pulling ~150 characters each time around the idle loop, far less than the 536 buffer size.

I'm just against adding extra complexity that realistically will never be used, especially with code size being such an issue at the moment. If you want to try stuff out, it's really not that hard to build Espruino in a VM.

req.on('end',... event

So in node.js, does res.end() close the connection immediately, or does it still wait for Content-Length bytes to be received, like is happening at the moment?

I could definitely change it to fire off an end event when content-length got reached.

Timeouts are something else that needs looking at - there's nothing implemented there at the moment at all.