Re: [libmicrohttpd] using other TLS libraries

[Gauthier Haderer]

Hi Christan,

I'm not sure I really understand your point.

Regarding the detection of TLS backend's availability, one can use the
function MHD_TLS_is_feature_supported() to test if a backend is present.

Of course, if MHD was built without support for a TLS backend, a client
won't be able to use it unless it rebuilds MHD with support enabled. If
your intent is to be able to add this support without the rebuild
requirement, the only option is to add a TLS plugin mecanism. This would
mean to publish the TLS API for plugin creators, basically "tls.h" plus
plugin glue. And maybe deliver a few standard plugins for GnuTLS, OpenSSL,
LibreSSL along with MHD or in another package.

Is this your idea?


Gauthier


> Hi Gauthier,
> I agree with Evgeny, good job. However, there is one (modest) change I
> would like to see, which is that the TLS backend(s) should be loaded via
> dlopen()/dlsym()/libltdl instead of hard-linked with MHD. That way, we
> could actually have one "libmicrohttpd.so" binary installed and the
> application can choose which (of the available, possibly none) of the
> TLS backends it wants to use. If we do not do this, we end up with the
> libcurl situation where you never know what TLS backend is available,
> and if you do need a specific one, you're in hell.
> That said, I think your refactoring is _exactly_ the right step in that
> direction and it should take very little to go from there where I would
> like to see this go.
> Finally, while I agree with Evgeny that we want to see microhttpd2.h as
> the new API, I disagree that this needs to wait for the microhttpd2-API
> to be finalized or even implemented. I think if someone adds the
> dlopen() capability to this, it could be merged rather quickly. The main
> issue with dlopen() is the logic needed to reliably identify the
> (relocatable) path to the plugin/shared library, which is _always_ very
> messy IMO. (see gnunet/src/util/{os_installation.c,plugin.c} for how
> I've hacked up solutions for this in the past).
> Happy hacking!
> Christian
> On 10/18/2017 04:01 PM, Gauthier Haderer wrote:
> >
> * Hello,*>
> >
> * I recently made changes to abstract the TLS API needed by MHD. And I*>
> * added support for OpenSSL. Could someone review my changes and tell me*>
> * if this is something that could be part of an official version?*>
> >
> * You will find more information here:*>
> * https://gnunet.org/bugs/view.php?id=4917#c12475
> *>
> >
> * Thank you,*>
> >
> >* Gauthier*

Re: [libmicrohttpd] using other TLS libraries

[Gauthier Haderer]

Hi Denis,

Well seen! This is a small typo but it highlighted several issues in my
update of existing tests. The OpenSSL engine was identified as GnuTLS and
it caused MHD to allow calls to GnuTLS-specific options that should be
rejected when using OpenSSL. As I forgot to change a few occurences of
these options in existing tests, these tests failed after fixing the typo.

I fixed all of them and they pass again.

Thanks again,


Gauthier


> Hi Gauthier,
>
> Nice work! I think this would be a great addition to libmicrohttpd. From
> an embedded perspective it would be great to be able to link to openssl or
> perhaps wolfssl (https://www.wolfssl.com/products/wolfssl/) to have a
> single SSL implementation on the platform. I like the way the TLS API
> cleanly defines the features that MHD needs from an SSL library.
>
> Found a small typo:
> diff --git a/src/microhttpd/tls_openssl.c b/src/microhttpd/tls_openssl.c
> index fee4917..67d9162 100644
> --- a/src/microhttpd/tls_openssl.c
> +++ b/src/microhttpd/tls_openssl.c
> @@ -906,8 +906,8 @@ MHD_TLS_openssl_session_write (struct MHD_TLS_Session
> * session,
>  const struct MHD_TLS_Engine tls_engine_openssl =
> {
> -  "GnuTLS",
> -  MHD_TLS_ENGINE_TYPE_GNUTLS,
> +  "OpenSSL",
> +  MHD_TLS_ENGINE_TYPE_OPENSSL,
>MHD_TLS_openssl_has_feature,
>MHD_TLS_openssl_init_context,
>
>
> Regards,
> Denis

Re: [libmicrohttpd] using other TLS libraries

[Gauthier Haderer]

Hi Evgeny,

I'm not familiar with the new API. I noticed it was under development but I
don't know much about it. I'll try to take time to review the current
proposal.

Cheers,

Gauthier


> Hi Gauthier,
> I've done impressive work.
> We have very similar plans for integrated support for multiple TLS
> backends.
> However, I believe that we should start porting on updated MHD API (see
> microhttpd2.h). One of the goals of new API is to make MHD more TLS-lib
> independent.
> In the meantime, you could criticize new API and propose enhancements.
> --
> Best Wishes,
> Evgeny Grin
> On 18.10.2017 17:01, Gauthier Haderer wrote:
> >
> * Hello,*>
> >
> * I recently made changes to abstract the TLS API needed by MHD. And I*>
> * added support for OpenSSL. Could someone review my changes and tell me*>
> * if this is something that could be part of an official version?*>
> >
> * You will find more information here:*>
> * https://gnunet.org/bugs/view.php?id=4917#c12475
> *>
> >
> * Thank you,*>
> >
> >* Gauthier*

Re: [libmicrohttpd] using other TLS libraries

[Christian Grothoff]

Yes, that is exactly what I would like to see, and AFAIK Evgeny has
started to hack on it.

-Christian

On 10/25/2017 04:20 PM, Gauthier Haderer wrote:
> Hi Christan,
> 
> I'm not sure I really understand your point.
> 
> Regarding the detection of TLS backend's availability, one can use the
> function MHD_TLS_is_feature_supported() to test if a backend is present.
> 
> Of course, if MHD was built without support for a TLS backend, a client
> won't be able to use it unless it rebuilds MHD with support enabled. If
> your intent is to be able to add this support without the rebuild
> requirement, the only option is to add a TLS plugin mecanism. This would
> mean to publish the TLS API for plugin creators, basically "tls.h" plus
> plugin glue. And maybe deliver a few standard plugins for GnuTLS,
> OpenSSL, LibreSSL along with MHD or in another package.
> 
> Is this your idea?
> 
> 
> Gauthier
>  
> 
> Hi Gauthier,
> I agree with Evgeny, good job. However, there is one (modest) change I
> would like to see, which is that the TLS backend(s) should be loaded via
> dlopen()/dlsym()/libltdl instead of hard-linked with MHD. That way, we
> could actually have one "libmicrohttpd.so" binary installed and the
> application can choose which (of the available, possibly none) of the
> TLS backends it wants to use. If we do not do this, we end up with the
> libcurl situation where you never know what TLS backend is available,
> and if you do need a specific one, you're in hell.
> That said, I think your refactoring is _exactly_ the right step in that
> direction and it should take very little to go from there where I would
> like to see this go.
> Finally, while I agree with Evgeny that we want to see microhttpd2.h as
> the new API, I disagree that this needs to wait for the microhttpd2-API
> to be finalized or even implemented. I think if someone adds the
> dlopen() capability to this, it could be merged rather quickly. The main
> issue with dlopen() is the logic needed to reliably identify the
> (relocatable) path to the plugin/shared library, which is _always_ very
> messy IMO. (see gnunet/src/util/{os_installation.c,plugin.c} for how
> I've hacked up solutions for this in the past).
> Happy hacking!
> Christian
> On 10/18/2017 04:01 PM, Gauthier Haderer wrote:
> >/Hello,
> />
> //>/I recently made changes to abstract the TLS API needed by MHD. And I
> />/added support for OpenSSL. Could someone review my changes and
> tell me
> />/if this is something that could be part of an official version?
> />
> //>/You will find more information here:
> />/https://gnunet.org/bugs/view.php?id=4917#c12475
> />
> //>/Thank you,
> />
> //>
> //>/Gauthier/
> 



signature.asc
Description: OpenPGP digital signature

[libmicrohttpd] any plan to support http 2.0?

[Yuyong Zhang]

Hi,

There are requirements in one project I am working on to support http 2.0, 
especially server push functionalities.

Is http 2.0 supported? If not, are there a release plan to support http 2.0?

Thanks a lot.

Regards,

Yuyong

Re: [libmicrohttpd] any plan to support http 2.0?

[silvioprog]

Hi Yuyong.

An interface for HTTP2 was sent to the trunk and it is under development:

https://github.com/Karlson2k/libmicrohttpd/blob/master/src/include/microhttpd2.h

Please take a look at this topic too:

http://lists.gnu.org/archive/html/libmicrohttpd/2017-08/msg00013.html

Cheers.

On Wed, Oct 25, 2017 at 12:55 PM, Yuyong Zhang <
yuyong.zh...@casa-systems.com> wrote:

> Hi,
>
>
>
> There are requirements in one project I am working on to support http 2.0,
> especially server push functionalities.
>
>
>
> Is http 2.0 supported? If not, are there a release plan to support http
> 2.0?
>
>
>
> Thanks a lot.
>
>
>
> Regards,
>
>
>
> Yuyong
>

-- 
Silvio Clécio

Re: [libmicrohttpd] any plan to support http 2.0?

[Christian Grothoff]

Eh, no, microhttpd2.h has _nothing_ to do with HTTP 2.0. It is simply
about building a better interface for the existing HTTP 1.x.

In fact, I personally do not have plans to work on HTTP 2.0-support.

Happy hacking!

Christian

On 10/26/2017 01:23 AM, silvioprog wrote:
> Hi Yuyong.
> 
> An interface for HTTP2 was sent to the trunk and it is under development:
> 
> https://github.com/Karlson2k/libmicrohttpd/blob/master/src/include/microhttpd2.h
> 
> Please take a look at this topic too:
> 
> http://lists.gnu.org/archive/html/libmicrohttpd/2017-08/msg00013.html
> 
> Cheers.
> 
> On Wed, Oct 25, 2017 at 12:55 PM, Yuyong Zhang
> mailto:yuyong.zh...@casa-systems.com>>
> wrote:
> 
> Hi,
> 
> __ __
> 
> There are requirements in one project I am working on to support
> http 2.0, especially server push functionalities.
> 
> __ __
> 
> Is http 2.0 supported? If not, are there a release plan to support
> http 2.0?
> 
> __ __
> 
> Thanks a lot.
> 
> __ __
> 
> Regards,
> 
> __ __
> 
> Yuyong
> 
> 
> -- 
> Silvio Clécio



signature.asc
Description: OpenPGP digital signature