http/1 - Client Request & Response

[ronag]

I find the current design of having a req and res API a bit unfortunate.

Currently they act as if they would be decoupled. However, this is not the case and it becomes very obvious during destroy().

Consider the following:

const req = http.request(...)
src.pipe(req)
req.on('finish', () => {
  req.on('close', common.mustCall());
  req.on('error', common.mustNotCall());

  // ... later

  // I would expect this to `autoDestroy` here.
  req.res.destroy(new Error('kaboom')); // This error is propagated to the request object, even though it was successful i.e. 'finish'?
}):

And vice versa: destroying the request after it has "completed" would destroy the response.

This has recently become a bit more obvious to me given recent issues with pipeline which has to have special cases for these objects due to this coupling.

What is the route we would prefer here:

1. Just leave it as is.
2. Try to decouple the two objects, i.e. when the request has 'finish':ed it decouples it self from the socket/response and destroys itself, as a normal stream, and the response lives its own life.
3. Try to convert the Request object in a Duplex where it would just emit itself on 'response' as a compat.

Currently the API is some kind of hybrid of 2 and 3, i.e. it behaves as if the two objects were a single Duplex instance, but they look like two separate streams.

[ronag]

Ref https://github.com/nodejs/node/pull/32197/files#diff-eefad5e8051f1634964a3847b691ff84R47

[antsmartian]

I'm not an expert on streams, but I guess the problem can be solved by the suggestion you @ronag mentioned on point 2. Is it easy to decouple the request once it is finished? I believe that is also easier to reason about the API for the developers.