Skip to content

Conversation

yglukhov
Copy link
Member

@yglukhov yglukhov commented Jul 23, 2025

  • Added support for SOCKS5h (h for proxy-side DNS resolving) to httpclient
  • Deprecated auth arguments for newProxy constructors, for auth to be embedded in the url.

Unfortunately http://example.com is not currently reachable from github CI, so the tests fail there for a few days already, I'm not sure what can be done here.

@@ -338,7 +347,6 @@ proc body*(response: AsyncResponse): Future[string] {.async.} =
type
Proxy* = ref object
url*: Uri
auth*: string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep it. Why break the code?

## Constructs a new `TProxy` object.
result = Proxy(url: url, auth: auth)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise for all these constructors.

Copy link
Member Author

@yglukhov yglukhov Jul 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code is not broken, I've introduced backward compatible (but deprecated) constructors and auth getter. I've removed the field, because of ambiguity redundancy with url, which IMO is a well-established format for providing/storing username/password.

@yglukhov
Copy link
Member Author

Let me expand a bit on API change.

Most importantly, it doesn't break existing code!

The auth argument is supposed to be "user:password", and is passed along with url parameter. While the user:password bits of the url are surprisingly ignored, despite them being a part of url spec. Initializing a proxy with url and passing user:password in the url would be the most immediately intuitive way.

As a real-world example, take a look at nimble code here and here where it takes deliberate actions to parse user:password out of the url only to pass it to newProxy constructor, instead of just passing the url as is.

@Araq
Copy link
Member

Araq commented Jul 29, 2025

Well CI failure seems related:

Category: stdlib
Name: tests/stdlib/thttpclient.nim c
Action: run
Result: reExitcodesDiffer
-------- Expected -------
exitcode: 0
--------- Given --------
exitcode: 1

Output:
thttpclient.nim(193) thttpclient
thttpclient.nim(120) syncTest
httpclient.nim(1261) request
httpclient.nim(1162) requestAux
httpclient.nim(1057) newConnection
net.nim(2046) dial
oserrors.nim(92) raiseOSError
Error: unhandled exception: Invalid argument [OSError]

@yglukhov
Copy link
Member Author

It does seem that way, but the adjacent PR tests fail with same exact message, I think it's because http://example.com doesn't currently work in github CI.

@Araq Araq merged commit 161b321 into nim-lang:devel Jul 29, 2025
14 of 18 checks passed
Copy link
Contributor

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 161b321

Hint: mm: orc; opt: speed; options: -d:release
182976 lines; 8.627s; 658.121MiB peakmem

@yglukhov yglukhov deleted the socks5h branch July 30, 2025 08:35
narimiran pushed a commit that referenced this pull request Aug 18, 2025
- Added support for SOCKS5h (h for proxy-side DNS resolving) to
httpclient
- Deprecated `auth` arguments for `newProxy` constructors, for auth to
be embedded in the url.

Unfortunately `http://example.com` is not currently reachable from
github CI, so the tests fail there for a few days already, I'm not sure
what can be done here.

(cherry picked from commit 161b321)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants