[Nim] Update httpbeast to v0.3

[waghanza]

Hi @dom96,

This PR update https://github.com/dom96/httpbeast to 0.3.

On my os (osx), I could not start

Starting 4 threads
Listening on port 3000
oserr.nim(94)            raiseOSError
Error: unhandled exception: Address family not supported by protocol [OSError]

I however updated CI config so as to see any containers logs.

Hope this will be helpful

---

Closes #4449

[dom96]

Thanks for trying! Any chance you can try Ubuntu as the CI docker image for httpbeast?

[waghanza]

Same issue with ubuntu @dom96

https://the-benchmarker.semaphoreci.com/jobs/19c2aca5-89a7-4d98-be09-5d23b7e17d9d

[dom96]

This is very peculiar as it works just fine in HttpBeast's CI: https://github.com/dom96/httpbeast/actions/runs/1133816001. Could it be some weird Docker-related problem? Although then it would work for you on macOS, sadly I don't have access to my MBP right now so can't test. Any chance you'd be willing to bisect httpbeast to see what introduces the bug on macOS?

[waghanza]

At first glance, the reuse port option seems troubling, but I will take a deeper look

[waghanza]

@dom96

Two scenarios are OK :

• Using Domain.AF_INET6
  https://the-benchmarker.semaphoreci.com/jobs/3e7f5f76-3e8c-42aa-adf4-f2b16ff3dc4f
• Removing custom settings (ports ...)

[dom96]

@waghanza but did 0.3.0 stop using AF_INET6? I looked at the changes between the versions and nothing really seemed to stick out that could cause this.

[waghanza]

Indeed, ans the error stack (when disabling cli option) point to a logging cause -> to investiguate

[waghanza]

The full stack is

Starting 4 threads
Listening on port 3000
/root/.nimble/pkgs/httpbeast-0.3.0/httpbeast.nim(318) eventLoop
/nim/lib/pure/net.nim(275) newSocket
/nim/lib/pure/includes/oserr.nim(94) raiseOSError
Error: unhandled exception: Address family not supported by protocol [OSError]

[waghanza]

@dom96 I can see in dom96/httpbeast@v0.2.2...v0.3.0 that domain is set in 3.0 (Domain.AF_INET) but not in 2.0

[dom96]

@waghanza I see, but it uses the same default as the stdlib (https://nim-lang.org/docs/net.html#newSocket%2CSocketHandle%2CDomain%2CSockType%2CProtocol). So when the value isn't specified it should still be using AF_INET.

[waghanza]

Yes @dom96.

Since, it works with AF_INET6 but not AF_INET, somehow IPv4 is disabled, but IPv6 is enabled.

However, without any custom Settings it works.

The full stack trace is

Starting 8 threads
Listening on port 3000
/Users/xxxx/.nimble/pkgs/httpbeast-0.3.0/httpbeast.nim(318) eventLoop
/usr/local/Cellar/nim/1.4.8/nim/lib/pure/net.nim(275) newSocket
/usr/local/Cellar/nim/1.4.8/nim/lib/pure/includes/oserr.nim(94) raiseOSError
Error: unhandled exception: Bad file descriptor [OSError]

[waghanza]

@dom96 The actual code works. However, I had to specify Domain.AF_INET in settings.

I do not know nim grammar, but why there is : before https://github.com/dom96/httpbeast/blob/d679e50578969f116cd1bd989e39951535a4d5bf/src/httpbeast.nim#L66
and = on this line ?

[dom96]

I do not know nim grammar, but why there is : before https://github.com/dom96/httpbeast/blob/d679e50578969f116cd1bd989e39951535a4d5bf/src/httpbeast.nim#L66
and = on this line ?

It's the return type of the procedure. In most cases : is followed by a type in Nim.

[dom96]

I still am quite confused by this problem. The default should be Domain.AF_INET so why does specifying it in settings explicitly work?

[waghanza]

I still am quite confused by this problem.

Me too

[waghanza]

@dom96 without specifying domain, the default socket type is AF_UNSPEC, and without specifying settings the domain is AF_INET

[dom96]

Oh I see. Well here is your bug, please use initSettings instead which will set the defaults properly.

[waghanza]

oh I see ... https://github.com/dom96/httpbeast/blob/b33dba93a134faa2adc3b991cb69890375987076/src/httpbeast.nim#L464 should not be used directly unless using initSettings

however, should not httpbeast use AF_UNSPEC so as either IPv6 or IPv4 is determined on nim level (depending on system ability) ?

[waghanza]

@mattaylor should not it be used in https://github.com/mattaylor/whip/blob/a9fd1f04ba0167727dd0dbf9235791f708147992/whip.nim#L118 ?

[dom96]

however, should not httpbeast use AF_UNSPEC so as either IPv6 or IPv4 is determined on nim level (depending on system ability) ?

not sure what you mean. You mean it should automatically choose IPv6 or IPv4 if AF_UNSPEC is used? That's not something Nim supports

[waghanza]

Exactly @dom96. I think to follow standards httpbeast should use AF_UNSPEC as long as nim should choose IPv4 or IPv6 depending on system abilities https://man7.org/linux/man-pages/man3/getaddrinfo.3.html

[dom96]

@waghanza but that's exactly what doesn't work, right? Maybe it's a problem on the Nim side, is that what you think?

[waghanza]

Indeed. The network / transport layer is, in my opinion, a language concern.

[dom96]

Thanks for looking into it!