undici - next

[ronag]

TODO:

• remove anti-pattern dispatcher hooks
• remove old interceptor pattern (refactor(#2722)!: Drop Interceptors support #2754)
• new interceptor pattern (Dispatch compose #2795)
• change so that dispatcher hooks take an options object instead of multiple arguments
• remove pipelining retries from core
• implement "idempotent" retry interceptor for pipeline resets
• implement "decompress" interceptor - Interceptors: add response decompress interceptor #3255
• separate out http2
• interceptors: move throwOnError to interceptor #3275
• interceptors: move signal handling to interceptor #3276
• make dump investigate content-length to see if it's worth trying to read
• move dump to interceptor - feat: dump interceptor #3118
• fix Readable.setEncoding issue (client.request throws Error with setEncoding #1125 (comment))
• [x] non-keep alive connections are not data safe
• [ ] Should we split onHeaders into more fine-grained hooks? i.e. onHeader(key, val) and onStatus(code, message)?

Refs: #2722

[ronag]

@metcoder95

[metcoder95]

With dispatcher hooks do you refer to interceptors?

[ronag]

With dispatcher hooks do you refer to interceptors?

It's methods on Dispatcher, i.e. onHeaders etc...

[ronag]

Some of the above we can probably land on main.

[metcoder95]

Should we split onHeaders into more fine-grained hooks? i.e. onHeader(key, val) and onStatus(code, message)?

This seems interesting, in theory, the HTTP response is split into three parts, the status line, headers and body; maybe we can follow this line?
See potential use cases, specially around stop request processing if the status is not the one expected

[ronag]

This seems interesting, in theory, the HTTP response is split into three parts, the status line, headers and body; maybe we can follow this line?

it's actually headers first, then status and then body.

[metcoder95]

I'm working on the dump to interceptor, but I'm curious what do you have in mind for that API?

Also removing the legacy interceptor concepts from next, but is out of sync, should I open aim the branch anyways in this state?

[metcoder95]

cc: @ronag

[ronag]

I will sort the next branch sometime in the next two weeks. Just open or against current state.

[ronag]

I'm working on the dump to interceptor, but I'm curious what do you have in mind for that API?

.compose(interceptors.dump({ maxSize: 1024 * 1024 }))

Something like that?

[PandaWorker]

It is also necessary to move the decompression of compressed data (gzip, deflate, br, zstd) into a separate interceptor

[ronag]

This plans need to be redone.

[ronag]

Creating a next branch etc is maybe not something I should be in charge of. I believe we should do the following things in next semvar major:

• remove old interceptor pattern
• remove maxRedirect defaults from agent etc... (apply interceptor in API methods instead)
• update llhttp

And that's it. I'll probably fork and apply things there for my own needs. Happy to help if someone else takes charge.

[metcoder95]

• Old pattern
• Replace max redirect with interceptor
• Update llhttp

[metcoder95]

I can help with this if support is needed 👍

[KhafraDev]

could we add #3366 and #2727 to next too?

... or the main branch. Whatever we're doing now, I'd love to get rid of these.

[metcoder95]

Yeah, let's add them to next 👍

[ronag]

@metcoder95 Just to be clear. I won't be doing anything further with the next branch despite previous indications. Feel free to do whatever you want with it. I'm doing my stuff on a fork.

[metcoder95]

Sure thing, no worries 👍

[artur-ma]

@ronag
How about changing the onHeaders ? Now u get there just Buffer array, which requires each handler that needs headers to parse them again and again(e.g retry handler, redirect handler)

So basically, we parse the headers multiple times, in each handler that needs headers
Also regarding removing onConnect, how to measure timing of acquiring the socket without it?
and the last one, removing onBodySent and wrapping the body, is there an example for that?

Thanks

[ronag]

How about changing the onHeaders ? Now u get there just Buffer array, which requires each handler that needs headers to parse them again and again(e.g retry handler, redirect handler)

This can solves with the following pattern that I've been using:

onHeaders(statusCode, rawHeaders, resume, statusMessage, headers = parseHeaders(rawHeaders)) {

and then make sure to pass the 4th argument to any sub handlers.

Not great though. I would also prefer to have the 2nd arg already pre-parsed.

[metcoder95]

Any specific reason why we added them unparsed?