mod_md version 2
Heya, the beautiful people at MOSS, Mozilla's Open Source Support, decided to give me a grant for Let's Encrypt and Stapling improvements in Apache! Big thanks! I described what I plan to do here: https://github.com/icing/mod_md/wiki/V2Design There are also github issues for collecting feedback and I pointed people to the Apache users mailing list as well. Besides the support for ACMEv2, which is in-scope of the module, I plan to add a new OCSP stapling implementation in the module as well. That may lead to some head scratching here and I want to explain my reasoning and, ideally, get feedback from you. - Any new OCSP stapling implementation must, in the 2.4.x release line, live along side the existing one. We will, with out backward compatibility requirements, never be able to switch that one off in 2.4.x. - We need a new implementation in the near future. OCSP responder downtimes become more threatening for the web, just because everyone goes https: if you look at browser statistics. - The infrastructure is there in mod_md. A curl http client, proxy configuration and the dependency on mod_watchdog already exist. Linkage to openssl (or its cousins) is there as well. - OCSP answers will be persisted in mod_md's file system store and shared between child processes that way. - Of course, the plan is to have it inactive by default, as shipped by us. Admins need to turn it on. If that can be done per vhost, MDomain or globally remains to be discussed. Cheers, Stefan
AW: svn commit: r1787606 - /httpd/httpd/trunk/server/core.c
C2 General
> -Ursprüngliche Nachricht-
> Von: Christophe JAILLET
> Gesendet: Samstag, 4. Mai 2019 09:20
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1787606 - /httpd/httpd/trunk/server/core.c
>
> Hi,
>
> In my perpetual effort to synch 2.4 and trunk, I have stopped r1787606
> as a potential candidate.
>
> However, I don't understand the rational with this patch and wonder if
> it should be backported, left as-is in trunk only or removed from trunk.
>
> Why should we avoid timeout and TCP_NODELAY settings for slave
> connection?
Because to my understanding these are only 'logical' connections that share the
masters TCP connection.
> Is it already set some other way, (i.e APR_TCP_NODELAY_INHERITED???)
IMHO on the master connection.
>
>
> This patch also makes the 'if (c->master == NULL) {' block at the end of
> this function unclear.
> Now, we know that c->master != NULL and the logic could be simplified.
I agree that the c->master == NULL could be removed. I guess this could then be
backported together with r1787606.
Regards
Rüdiger
>
>
> Any opinion?
>
> CJ
>
>
> Le 19/03/2017 à 11:33, ic...@apache.org a écrit :
> > Author: icing
> > Date: Sun Mar 19 10:33:43 2017
> > New Revision: 1787606
> >
> > URL: http://svn.apache.org/viewvc?rev=1787606=rev
> > Log:
> > On the trunk:
> >
> > core: avoid socket timeout settings etc. on slave connections.
> >
> >
> > Modified:
> > httpd/httpd/trunk/server/core.c
> >
> > Modified: httpd/httpd/trunk/server/core.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1787606
> =1787605=1787606=diff
> >
>
> ==
> > --- httpd/httpd/trunk/server/core.c (original)
> > +++ httpd/httpd/trunk/server/core.c Sun Mar 19 10:33:43 2017
> > @@ -5280,9 +5280,14 @@ static conn_rec *core_create_conn(apr_po
> >
> > static int core_pre_connection(conn_rec *c, void *csd)
> > {
> > -core_net_rec *net = apr_palloc(c->pool, sizeof(*net));
> > +core_net_rec *net;
> > apr_status_t rv;
> >
> > +if (c->master) {
> > +return DONE;
> > +}
> > +
> > +net = apr_palloc(c->pool, sizeof(*net));
> > /* The Nagle algorithm says that we should delay sending partial
> >* packets in hopes of getting more data. We don't want to do
> >* this; we are not telnet. There are bad interactions between
> >
> >
> >
