Robert Nagy
Robert Nagy
Accessing `Request.aborted` should not be needed. - [ ] Remove unnecessary check before `request.onUpgrade`. - [ ] Remove unnecessary check after `request.onConnect`. - [ ] Find a more elegant solution...
Allow passing a factory method as body which would return a `Readable`. This would allow e.g. idempotent `PUT` requests which e.g. read from a file to be part of the...
The difference between 1 and 50 connections is rather strange...
Would it be useful to have more events for introspection? e.g. ```js client.on('requestStart', (origin, opts) => {}) client.on('requestEnd', (origin, opts, err) => {}) ``` Or is it just an unnecessary...
Some of our tests might emit disconnect, reconnect and then pass even though a disconnect was not expected. Add more assertions (`t.fail()`) to catch this if it happens.
I think `text/event-stream` responses should be handled as an upgrade and the socket released from the undici client (like with websockets).
- Try to avoid calling `socket._unrefTimer` as often (`getLibuvNow` is slow). - Investigate if `writeAsciiString` can be made faster? - Optimize GC? (reduce allocations) - Optimize `parseKeepAliveTimeout`?
Client will not notice requests might be aborted until `request.onConnect` which will only happen after the socket has connected. Thus the client might unnecessarily create a connection if all pending...