[Enhancement] Add Https capability option?

[DevTKSS]

Would it be thinkable to add a Https capability?

I was replicating the Server behavior here on my repo, just with the difference if one call at a time and simplifyed response and came up with a HttpListener using setup

From what I readed, the HttpsListener is able to provide https🤔

I would indeed not know how it would be seperate-able as much that the actual listening instance could be made exchange-able or selectable in code, but maybe someone with more knowledge does have ideas for that 😅
Not sure if there is any other specific important reason for not using that type, so if there is one, please let me know!

Maybe you could take a look if that would work for the Server definition here?

[carldebilly]

That's a good idea TBH. I fear it could defeat the purpose of a lightweight silly http server, but maybe I should try :-) Le me check if I can do something quickly.

[DevTKSS]

@carldebilly up from the accessor level change of the Disposable Extension of your server I had to comment out my try if the http listener because except from duplicating your extension or adding a ICollection<T> inheritance to the handler, which would not make sense as its an item and not the "list keeper" 😅, so the Uno Extension CompositeDisposableExtensions could be used 🫤
Hoping that there might be a way that could be directly implemented here then.

[carldebilly]

[...] the accessor level change of the Disposable Extension of your server I had to comment out my try if the http listener because except from duplicating your extension.

I made the disposable extension internal on purpose. The goal of this library is to provide a dependency-free, minimal HTTP server. Shipping additional low-level helpers would make the package opinionated, which goes against that philosophy.

If you need a composite/disposable helper, I suggest one of the following:

• Use your own tiny local extension (it’s just a few lines), or
• Rely on an external helper (e.g., Uno’s CompositeDisposableExtensions) in your app layer.

If there’s strong interest, I’m open to exposing this as a separate optional package (e.g., Yllibed.HttpServer.Disposables) so the core stays lean.

[DevTKSS]

I mas just trying to replicate this with the other "client" instance with it. I think to have a ICollection implementation, it would require to have the Registration you recently made a extension method calling the server a very own instance like a kind of mediator pattern.
While that approach indeed sounds interesting that the server would have more SOC, the complexity of the current definition (single class for server + Response + handling registration) is too high that I would see my knowledge for it.

Is there a specific reason for you decided to build it as one big class instead of more seperated in the functionalitys its providing?
Could move that as idea also to a new issue but looks like you made it intentional 🤔