You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@apache.org> on 2017/12/22 22:31:56 UTC
Re: SSLSrvConfigRec shared
On Thu, 21 Sep 2017 08:11:17 -0400
Eric Covener <co...@gmail.com> wrote:
> IIUC it should be safe to extend module_struct with a minor bump to
> add 'int flags' to the bottom, but when you check the value you'd need
> to check the MMN first. In the module you'd then just have some flags
> or'ed together after register_hooks.
Sorry to come to this late: arises from reviewing STATUS.
Ugh. Fine for trunk, but that's a lot of complexity to foist on
a stable branch. A module would not only need to check MMN,
but also implement fallback behaviour if there are no flags.
So why not KISS and stick with that fallback for all 2.4?
--
Nick Kew
Re: SSLSrvConfigRec shared
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Dec 23, 2017 at 3:53 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
> I think this really is a bug in our runtime. The flag was invented
> just for precaution, in case a module would rely on the no-copy
> behaviour. That is really close to saying: we will not fix
> any more bugs in 2.4.x as someone could rely on it.
I would be fine with duplicating/merging every server config by
default, even when no module directive is specified, the risk is that
some (third party) merger functions might not do the right thing when
called in this situation, and could break.
Too much caution possibly...
Re: SSLSrvConfigRec shared
Posted by Eric Covener <co...@gmail.com>.
> I think this really is a bug in our runtime. The flag was invented
> just for precaution, in case a module would rely on the no-copy
> behaviour. That is really close to saying: we will not fix
> any more bugs in 2.4.x as someone could rely on it.
I don't think this bit is fair. Every config section behaves the same
-- modules get a new configuration when their directives are used in
the section.
Re: SSLSrvConfigRec shared
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 23.12.2017 um 12:34 schrieb Yann Ylavic <yl...@gmail.com>:
>
> On Sat, Dec 23, 2017 at 9:00 AM, Nick Kew <ni...@apache.org> wrote:
>> On Sat, 2017-12-23 at 08:20 +0100, Stefan Eissing wrote:
>>
>>>> Ugh. Fine for trunk, but that's a lot of complexity to foist on
>>>> a stable branch. A module would not only need to check MMN,
>>>> but also implement fallback behaviour if there are no flags.
>>>> So why not KISS and stick with that fallback for all 2.4?
>>>
>>> Not sure, I parse that. Any module that does nothing continues to
>>> see the same behaviour than before. Where does the complexity
>>> arrive?
>>
>> But a module cannot ever *use* it without checking MMN
>> *AND* implementing fallback behaviour for being loaded
>> into an httpd built with the old struct - and consequently
>> old API and ABI.
>>
>> That's bad enough to work through once, let alone maintain longer-term!
>>
>> Whereas the fallback, by definition, works in all cases.
>
> Right, but hence nothing prevents the modules from implementing the
> fallback only, just as if "flags" were not in 2.4.x.
> It's not like depending on the MMN is mandatory.
>
> It seems that no module really needed it until mod_md, or they already
> implemented the fallback.
> If we make it to 2.4.next for mod_md needs (which anyway requires
> mod_ssl 2.4.next), at least it simplifies the code in mod_ssl...
Any module that writes to its config records in a post_config hook
is in danger of having shared instances between vhosts. Only when
directives of the module in the vhost are used, do they have
a unique config record instance.
There is workaround code in mod_md and I was writing that for mod_ssl
as Yann came with this flag solution. So, current mod_ssl does not
have a workaround and will not work in case someone uses the
SSLEngine *:443 and uses no SSL* directives in vhosts.
If "SSLEngine on" or other directives are used, that vhost has a
unique instance of its mod_ssl config record. Very subtle.
I think this really is a bug in our runtime. The flag was invented
just for precaution, in case a module would rely on the no-copy
behaviour. That is really close to saying: we will not fix
any more bugs in 2.4.x as someone could rely on it.
>> Agreed, post-config per-server stuff is clumsy: I have a distant
>> memory from 2.0 days of hacking some ugly workaround, though the
>> details elude me. But wouldn't it make more sense to review that
>> in 2.5/trunk rather than the stable branch?
>
> It shouldn't hurt in 2.4, IMHO.
I agree. I also think the bugfix without flag could have gone to 2.4.
Re: SSLSrvConfigRec shared
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Dec 23, 2017 at 9:00 AM, Nick Kew <ni...@apache.org> wrote:
> On Sat, 2017-12-23 at 08:20 +0100, Stefan Eissing wrote:
>
>> > Ugh. Fine for trunk, but that's a lot of complexity to foist on
>> > a stable branch. A module would not only need to check MMN,
>> > but also implement fallback behaviour if there are no flags.
>> > So why not KISS and stick with that fallback for all 2.4?
>>
>> Not sure, I parse that. Any module that does nothing continues to
>> see the same behaviour than before. Where does the complexity
>> arrive?
>
> But a module cannot ever *use* it without checking MMN
> *AND* implementing fallback behaviour for being loaded
> into an httpd built with the old struct - and consequently
> old API and ABI.
>
> That's bad enough to work through once, let alone maintain longer-term!
>
> Whereas the fallback, by definition, works in all cases.
Right, but hence nothing prevents the modules from implementing the
fallback only, just as if "flags" were not in 2.4.x.
It's not like depending on the MMN is mandatory.
It seems that no module really needed it until mod_md, or they already
implemented the fallback.
If we make it to 2.4.next for mod_md needs (which anyway requires
mod_ssl 2.4.next), at least it simplifies the code in mod_ssl...
>
> Agreed, post-config per-server stuff is clumsy: I have a distant
> memory from 2.0 days of hacking some ugly workaround, though the
> details elude me. But wouldn't it make more sense to review that
> in 2.5/trunk rather than the stable branch?
It shouldn't hurt in 2.4, IMHO.
Regards,
Yann.
Re: SSLSrvConfigRec shared
Posted by Nick Kew <ni...@apache.org>.
On Sat, 2017-12-23 at 08:20 +0100, Stefan Eissing wrote:
> > Ugh. Fine for trunk, but that's a lot of complexity to foist on
> > a stable branch. A module would not only need to check MMN,
> > but also implement fallback behaviour if there are no flags.
> > So why not KISS and stick with that fallback for all 2.4?
>
> Not sure, I parse that. Any module that does nothing continues to see the same behaviour than before. Where does the complexity arrive?
But a module cannot ever *use* it without checking MMN
*AND* implementing fallback behaviour for being loaded
into an httpd built with the old struct - and consequently
old API and ABI.
That's bad enough to work through once, let alone maintain longer-term!
Whereas the fallback, by definition, works in all cases.
Agreed, post-config per-server stuff is clumsy: I have a distant
memory from 2.0 days of hacking some ugly workaround, though the
details elude me. But wouldn't it make more sense to review that
in 2.5/trunk rather than the stable branch?
--
Nick Kew
Re: SSLSrvConfigRec shared
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 22.12.2017 um 23:31 schrieb Nick Kew <ni...@apache.org>:
>
> On Thu, 21 Sep 2017 08:11:17 -0400
> Eric Covener <co...@gmail.com> wrote:
>
>> IIUC it should be safe to extend module_struct with a minor bump to
>> add 'int flags' to the bottom, but when you check the value you'd need
>> to check the MMN first. In the module you'd then just have some flags
>> or'ed together after register_hooks.
>
> Sorry to come to this late: arises from reviewing STATUS.
>
> Ugh. Fine for trunk, but that's a lot of complexity to foist on
> a stable branch. A module would not only need to check MMN,
> but also implement fallback behaviour if there are no flags.
> So why not KISS and stick with that fallback for all 2.4?
Not sure, I parse that. Any module that does nothing continues to see the same behaviour than before. Where does the complexity arrive?
-Stefan
>
> --
> Nick Kew