release: 2.0.0

[szmarczak]

done

wip: simplify forward

• remove babel
• simplify forward handler
• added https support
  • test
• require node.js 14
• skipped 2 tests (will re-enable once proxy-chain is fully rewritten)

wip: simplify custom response

• simplify custom response
• use shared eslint config

wip: simplify direct

• simplify direct

wip: simplify chain

• simplify chain
  • remove handler base

wip: simplify tools

• simplify tools
  • remove parseUrl(...) in favor of new URL(...)
  • remove parseHostHeader(...) in favor of new URL(...)
  • remove isInvalidHeader(...) (unused)
  • tests: remove buggy findFreePort in favor of port: 0
  • simplify redactUrl
  • remove addHeader (leftover from wip: simplify chain #156)
• add IPv6 tests

There's a slight behavior change in parseAuthorizationHeader. It now returns { type: '', data: '' } (instead of null) if the proxy-authorization header is invalid.

wip: simplify tunnel

• simplify TcpTunnel https://blog.apify.com/tunneling-arbitrary-protocols-over-http-proxy-with-static-ip-address-b3a2222191ff/
• turn the 5 parameters of direct and chain into object

wip: simplify server

• simplify server
• re-enable two skipped tests from wip: simplify forward #153

other

• Fix Memory leak in createTunnel #160
• Fix Proxy fails to handle non-standard HTTP response in HTTP forwarding mode, on certain websites #107
• enable coverage
• more descriptive errors

wip: move to TypeScript

• use typescript

• manual testing

[szmarczak]

I have tested this manually and found no issues. Chain, Custom Response, Direct, Forward - they all work.

IPv6 works as well (if upstream supports it, not all proxies do).

[temp3l]

awesome module!
currently seeing some errors in example/apify_proxy_tunnel.js (@next)

[szmarczak]

What errors are you seeing?

[mnmkng]

I'm pretty sure I won't find any issues now as all the PRs were reviewed individually. Let's wait for @jancurn's approval and then proceed with limited testing.

[jancurn]

I did a review of the new code. The code feels much much cleaner, it's broken down to more files, everything in TypeScript... in summary, definitely a big improvement, great work @szmarczak ! I didn't go into the lower-level details, I guess we'll have to gradually test it under heavier and heavier loads and see how it works.

Here are some comments:

• Altogether, the code is commented only very sparingly. A lot of functions don't have any comments, so you need to analyze the code to understand what they do. Sometimes their name doesn't say much too (e.g. getBasic, redactUrl). When the functions are internal and are a few lines long, then it's fine, but sometimes they are longer or serve an important case, and then they should be commented. At the very least, all public methods of Server class should be commented, as well as core functions like chain, handleCustomResponse, direct, forward, ...
• Please can you also update the CHANGELOG?
• It would be great if we could generate documentation of all the public classes and functions, now we have just README. Maybe in the next version...
• Are we using all the unit tests as we did in the past? I remember some things were commented out

[szmarczak]

Yep, all the tests pass. The commented out tests are now uncommented and pass as well :)

[B4nan]

Agreed regarding the comments, while I understand the motivation behind removing comments that are not helpful, it does not mean we should have no comments :] At least public API should be documented.

It's always good to try to look at the comments from a newbie point of view, while it might feel moot for you, there still can be some value for newbies/newcomers.

Btw what about #160, is that addressed by the PR too?
I see it is, so the PR desc should contain the closes/fixes part to link it (or is it enough like this, just fix?).

[szmarczak]

Altogether, the code is commented only very sparingly.

I'm trying to write self explanatory code when possible.

• countTargetBytes does exactly what it says, it starts to count read and written bytes of the target socket.
• decodeURIComponentSafe, safe means it doesn't throw. This is a common practice.
• I agree that getBasic doesn't say much, I've renamed it to getBasicAuthorizationHeader.
• isHopByHopHeader is self explanatory.
• parseAuthorizationHeader is self explanatory as well, no need to explicitly view the code since we have the TypeScript definitions.
• redactUrl may be not so self explanatory, but again - the parameters are url and passwordReplacement, and that is self explanatory :)
• Renamed the array parameter in validHeadersOnly to rawHeaders, also linked to Node.js docs. Should be enough :)

At the very least, all public methods of Server class should be commented

They already are, not sure what you mean. Those comments just need corrections, will fix them.

as well as core functions like chain, handleCustomResponse, direct, forward, ...

Done 👍🏼

Please can you also update the CHANGELOG?

On it.

It would be great if we could generate documentation of all the public classes and functions, now we have just README.

Agreed. However generators are not so friendly. Most projects do docs by hand.

@B4nan

Btw what about #160, is that addressed by the PR too?
I see it is, so the PR desc should contain the closes/fixes part to link it (or is it enough like this, just fix?).

Already there ;)