Allow to specify the local endpoint for HttpListener

[Alex-111]

Description

Currently the HttpListener does not allow to listen on a specific interface. It always is listening to the first interfase it finds. E.g. if you have more than one it always binds to the first interface.

Motivation and Context

The HttpListener should be able to bind e.g. to the second network interface...

[nfbot]

Hi @Alex-111,

😯 I'm afraid you'll have to use the PR template like the rest of us...
Make sure you've used the template and have include all the required information and fill in the appropriate details. After doing that feel free to reopen the PR. If you have questions we are here to help..

[Alex-111]

@dotnet-policy-service agree

[nfbot]

Hi @Alex-111,

😯 I'm afraid you'll have to use the PR template like the rest of us...
Make sure you've used the template and have include all the required information and fill in the appropriate details. After doing that feel free to reopen the PR. If you have questions we are here to help..

[Ellerbach]

@Alex-111 please use the PR template, there are automations based on it!

[josesimoes]

@Alex-111 I've just merged upstream changes with code style fixes so the changes on the PR are only related with the matter.

[nfbot]

Hi @Alex-111,

😯 I'm afraid you'll have to use the PR template like the rest of us...
Make sure you've used the template and have include all the required information and fill in the appropriate details. After doing that feel free to reopen the PR. If you have questions we are here to help..

[josesimoes]

@Alex-111 please don't give up on the PR! Nor get spooked with the messages from nfbot. 😄
It's a matter of having back the PR comment template and it's ready for review.

[josesimoes]

@Alex-111 never mind! Just saw that you've started over. Thanks!

[Alex-111]

@josesimoes
I'm not sure how much the core .net classes like HttpListener has to be aligned with the full framework. In full framework the above feature seems to be available via Prefixes, but at the moment there is no such an API in nanoFramework available...
Are there any best practices for nanoframework how new features should be implemented?
is it allowed to have a different API in nanoframework than in full framework?

[josesimoes]

@Alex-111 the strategy is to have the exact same API as the full framework. When that is not possible/doesn't make sense we're OK to deviate. This seams to be the case.
I'm OK with your proposed change. It's not breaking anything and it's implemented in a reasonable way. Even for discoverability.

@Ellerbach would you agree?

[Alex-111]

Well. Full Framework would look like this:

HttpListener listener = new HttpListener(); listener.Prefixes.Add("http://10.0.0.1:80/"); listener.Start();

i.e. there shouldn't be a "port" and also no "localEndpointIP" parameter at all. But as we already have port I would agree to leave it as it is now. Thanks!