You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2017/02/21 21:58:09 UTC
[RFC] ?
For cases like HttpProtocolOptions where a new directive is introduced
to multiple active branches simultaneously, it gets awkward to use
<IfVersion> to write conf files which use the new directive but are
compatible across multiple versions.
Triggered by a conversation with a user, but also e.g. see current test
suite t/conf/extra.conf.in which breaks for 2.4 releases older than
2.4.25 with:
<IfVersion >= 2.2.32>
<VirtualHost _default_:http_strict>
DocumentRoot @SERVERROOT@/htdocs/
HttpProtocolOptions Strict Require1.0 RegisteredMethods
Any reason <IfDirective> is a bad idea, so we can do that more cleanly
(... in a couple of decades time)?
Regards, Joe
Re: [RFC] ?
Posted by Reindl Harald <h....@thelounge.net>.
Am 21.02.2017 um 23:24 schrieb Eric Covener:
> On Tue, Feb 21, 2017 at 5:20 PM, Reindl Harald <h....@thelounge.net> wrote:
>>
>>
>> Am 21.02.2017 um 22:58 schrieb Joe Orton:
>>>
>>> For cases like HttpProtocolOptions where a new directive is introduced
>>> to multiple active branches simultaneously, it gets awkward to use
>>> <IfVersion> to write conf files which use the new directive but are
>>> compatible across multiple versions.
>>>
>>> Triggered by a conversation with a user, but also e.g. see current test
>>> suite t/conf/extra.conf.in which breaks for 2.4 releases older than
>>> 2.4.25 with:
>>>
>>> <IfVersion >= 2.2.32>
>>> <VirtualHost _default_:http_strict>
>>> DocumentRoot @SERVERROOT@/htdocs/
>>> HttpProtocolOptions Strict Require1.0 RegisteredMethods
>>>
>>> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
>>> (... in a couple of decades time)?
>>
>>
>> you need to wrap that at least in <IfModule> since mod_version is not
>> mandatory and httpd if unforgiving for unknown options
>>
>> for the same reason the dance below is needed
>>
>> <IfModule !mod_version.c>
>> <IfModule mod_authz_core.c>
>> Require all denied
>> </IfModule>
>> <IfModule !mod_authz_core.c>
>> Order deny,allow
>> Deny from All
>> </IfModule>
>> </IfModule>
>> <IfModule mod_version.c>
>> <IfVersion < 2.4>
>> Order deny,allow
>> Deny from all
>> </IfVersion>
>> <IfVersion >= 2.4>
>> Require all denied
>> </IfVersion>
>> </IfModule>
>
> Kind of weird to keep the <IfVersion-dependent branch in this example
in *this* example maybe, in general the "<IfVersion >= 2.4>" can be more
specific like "<IfVersion >= 2.4>" because there where options added in
2.4.x releases which would stop httpd on older minor versions and
especially in conext of LTS distributions you don't always know which
features are really in the 2.4.x-distr
SSLCompression
Available in httpd 2.4.3 and later
so you can write a config which is safe for any httpd but chain it to
recent features if available and *if* mod_version is available
Re: [RFC] ?
Posted by Eric Covener <co...@gmail.com>.
On Tue, Feb 21, 2017 at 5:20 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 21.02.2017 um 22:58 schrieb Joe Orton:
>>
>> For cases like HttpProtocolOptions where a new directive is introduced
>> to multiple active branches simultaneously, it gets awkward to use
>> <IfVersion> to write conf files which use the new directive but are
>> compatible across multiple versions.
>>
>> Triggered by a conversation with a user, but also e.g. see current test
>> suite t/conf/extra.conf.in which breaks for 2.4 releases older than
>> 2.4.25 with:
>>
>> <IfVersion >= 2.2.32>
>> <VirtualHost _default_:http_strict>
>> DocumentRoot @SERVERROOT@/htdocs/
>> HttpProtocolOptions Strict Require1.0 RegisteredMethods
>>
>> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
>> (... in a couple of decades time)?
>
>
> you need to wrap that at least in <IfModule> since mod_version is not
> mandatory and httpd if unforgiving for unknown options
>
> for the same reason the dance below is needed
>
> <IfModule !mod_version.c>
> <IfModule mod_authz_core.c>
> Require all denied
> </IfModule>
> <IfModule !mod_authz_core.c>
> Order deny,allow
> Deny from All
> </IfModule>
> </IfModule>
> <IfModule mod_version.c>
> <IfVersion < 2.4>
> Order deny,allow
> Deny from all
> </IfVersion>
> <IfVersion >= 2.4>
> Require all denied
> </IfVersion>
> </IfModule>
Kind of weird to keep the <IfVersion-dependent branch in this example.
--
Eric Covener
covener@gmail.com
Re: [RFC] ?
Posted by Reindl Harald <h....@thelounge.net>.
Am 21.02.2017 um 22:58 schrieb Joe Orton:
> For cases like HttpProtocolOptions where a new directive is introduced
> to multiple active branches simultaneously, it gets awkward to use
> <IfVersion> to write conf files which use the new directive but are
> compatible across multiple versions.
>
> Triggered by a conversation with a user, but also e.g. see current test
> suite t/conf/extra.conf.in which breaks for 2.4 releases older than
> 2.4.25 with:
>
> <IfVersion >= 2.2.32>
> <VirtualHost _default_:http_strict>
> DocumentRoot @SERVERROOT@/htdocs/
> HttpProtocolOptions Strict Require1.0 RegisteredMethods
>
> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
> (... in a couple of decades time)?
you need to wrap that at least in <IfModule> since mod_version is not
mandatory and httpd if unforgiving for unknown options
for the same reason the dance below is needed
<IfModule !mod_version.c>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from All
</IfModule>
</IfModule>
<IfModule mod_version.c>
<IfVersion < 2.4>
Order deny,allow
Deny from all
</IfVersion>
<IfVersion >= 2.4>
Require all denied
</IfVersion>
</IfModule>
Re: [RFC] ?
Posted by Eric Covener <co...@gmail.com>.
On Wed, Feb 22, 2017 at 8:43 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> I was more concerned about our support for <IfVersion >...
> I'd really like to see mod_version go away in 2.next and force
> the availability of that feature so that .conf authors are assured
> of it's presence moving forwards.
+1
--
Eric Covener
covener@gmail.com
Re: [RFC] ?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Feb 22, 2017 at 1:04 AM, Nick Kew <ni...@apache.org> wrote:
> On Tue, 2017-02-21 at 21:58 +0000, Joe Orton wrote:
>
>> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
>> (... in a couple of decades time)?
>
> One reason it might be a very bad idea: user confusion!
>
> I'm thinking of the track record of <IfModule> here.
> Our support fora are full of users who have seen it in
> default/shipped config and docs, and treat it as some
> magic incantation they need. They end up with a problem
> "why doesn't Foo work?", which they bring to our fora
> after many hours of tearing their hair. The usual answer:
> Get rid of all the <IfModule> crap, to stop suppressing
> the error message you need!
That speaks to our docs/conf/* tree, right? Not the existence
of the <IfModule > directive ... I'm guessing you don't support
eliminating that feature in the future?
I was more concerned about our support for <IfVersion >...
I'd really like to see mod_version go away in 2.next and force
the availability of that feature so that .conf authors are assured
of it's presence moving forwards.
An issue is that this is needed to let users devs toggle specific
tests based on patch level. Right now, testing requires a backport,
which doesn't vary by the httpd version, and only rarely varies
by <IfModule >. This proposal makes introducing the tests
upon adding a feature to trunk painless; the test is accessible
from the moment the directive is backported.
If you want to propose an "<IfModule > considered harmful"
caution in the docs (which we can borrow or point to for the
<IfDirective > docs) ... that could be helpful. It often indicates
that the user's conf was not thought out, and that it is subject
to unexpected behavior changes if a module is loaded or
commented out. That doesn't mean these serve no purpose.
Re: [RFC] ?
Posted by Nick Kew <ni...@apache.org>.
On Tue, 2017-02-21 at 21:58 +0000, Joe Orton wrote:
> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
> (... in a couple of decades time)?
One reason it might be a very bad idea: user confusion!
I'm thinking of the track record of <IfModule> here.
Our support fora are full of users who have seen it in
default/shipped config and docs, and treat it as some
magic incantation they need. They end up with a problem
"why doesn't Foo work?", which they bring to our fora
after many hours of tearing their hair. The usual answer:
Get rid of all the <IfModule> crap, to stop suppressing
the error message you need!
--
Nick Kew
Re: [RFC] ?
Posted by Eric Covener <co...@gmail.com>.
On Tue, Feb 21, 2017 at 4:58 PM, Joe Orton <jo...@redhat.com> wrote:
> For cases like HttpProtocolOptions where a new directive is introduced
> to multiple active branches simultaneously, it gets awkward to use
> <IfVersion> to write conf files which use the new directive but are
> compatible across multiple versions.
>
> Triggered by a conversation with a user, but also e.g. see current test
> suite t/conf/extra.conf.in which breaks for 2.4 releases older than
> 2.4.25 with:
>
> <IfVersion >= 2.2.32>
> <VirtualHost _default_:http_strict>
> DocumentRoot @SERVERROOT@/htdocs/
> HttpProtocolOptions Strict Require1.0 RegisteredMethods
>
> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
> (... in a couple of decades time)?
>
> Regards, Joe
Seems pretty neat.
Re: [RFC] ?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Feb 28, 2017 at 5:57 PM, Jacob Champion <ch...@gmail.com> wrote:
> On 02/27/2017 03:19 AM, Joe Orton wrote:
>>
>> On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote:
>>>
>>> On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton <jo...@redhat.com> wrote:
>>>>
>>>> (b) for <IfDirective foo> match both "foo" and "<foo".
>>>
>>>
>>> I'd vote for this, it's very unlikely that some day we want to add a
>>> directive called VirtualHost or If (w/o the leading '<') which may
>>> conflict here, so it shouldn't hurt.
>>
>>
>> I'm fine with that, I'll commit like this unless anybody else has strong
>> opinions.
>
>
> mod_lua (in trunk at least) apparently ships both a '<LuaXXX>' and 'LuaXXX'
> version of several directives. It wouldn't surprise me to find that other
> third-party modules have a "block version" of a normal directive with the
> same name. I'm kind of -0.5 to making the two collide.
>
> Is there a good reason that quoting the argument to a block gives a syntax
> error? Can we fix that instead?
As much as we all suck at naming things...
What about <IfDirective > vs. <IfSection >?
(And deliberately circumvent anyone using <IfDirective "<... since it is simply
too confusing for any sane parser.)
Re: [RFC] ?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mar 8, 2017 4:29 AM, "Joe Orton" <jo...@redhat.com> wrote:
Sorry, taking my time here, and I appreciate all the feedback.
Definitely happier to debate it and get it right than be lumbered with
annoying edge cases forever.
I did the refactoring in r1785943, so third iteration attached has both
<IfDirective X> and <IfSection Y>. I'd have been fine with either
previous iteration, but this does make sense to me.
Final call for yay/nay?
Aye!
Re: [RFC] ?
Posted by Jacob Champion <ch...@gmail.com>.
On 03/08/2017 02:29 AM, Joe Orton wrote:
> Final call for yay/nay?
Works great on my machine, +1!
--Jacob
Re: [RFC] ?
Posted by Stefan Eissing <st...@greenbytes.de>.
+1
> Am 08.03.2017 um 11:29 schrieb Joe Orton <jo...@redhat.com>:
>
> <ap_ifdirective3.diff>
Stefan Eissing
<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de
AW: [RFC] ?
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
+1
Regards
Rüdiger
> -----Ursprüngliche Nachricht-----
> Von: Joe Orton [mailto:jorton@redhat.com]
> Gesendet: Mittwoch, 8. März 2017 11:30
> An: dev@httpd.apache.org
> Betreff: Re: [RFC] <IfDirective>?
>
> On Tue, Mar 07, 2017 at 11:52:17AM -0800, Jacob Champion wrote:
> > On 02/28/2017 04:32 PM, Jacob Champion wrote:
> > > I just don't like hamstringing a nice new directive with what's
> > > effectively a (rare) bug.
> >
> > (The conversation kinda died shortly after I said this. That was not
> my
> > intent -- I like this directive a lot. Whether the consensus is to
> keep the
> > corner case, or introduce a new <IfSection> or <IfContainer>, or make
> the
> > arg quotable, or whatever. I don't mean to be throwing up roadblocks.)
>
> Sorry, taking my time here, and I appreciate all the feedback.
> Definitely happier to debate it and get it right than be lumbered with
> annoying edge cases forever.
>
> I did the refactoring in r1785943, so third iteration attached has both
> <IfDirective X> and <IfSection Y>. I'd have been fine with either
> previous iteration, but this does make sense to me.
>
> Final call for yay/nay?
>
> Regards, Joe
Re: [RFC] ?
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Mar 07, 2017 at 11:52:17AM -0800, Jacob Champion wrote:
> On 02/28/2017 04:32 PM, Jacob Champion wrote:
> > I just don't like hamstringing a nice new directive with what's
> > effectively a (rare) bug.
>
> (The conversation kinda died shortly after I said this. That was not my
> intent -- I like this directive a lot. Whether the consensus is to keep the
> corner case, or introduce a new <IfSection> or <IfContainer>, or make the
> arg quotable, or whatever. I don't mean to be throwing up roadblocks.)
Sorry, taking my time here, and I appreciate all the feedback.
Definitely happier to debate it and get it right than be lumbered with
annoying edge cases forever.
I did the refactoring in r1785943, so third iteration attached has both
<IfDirective X> and <IfSection Y>. I'd have been fine with either
previous iteration, but this does make sense to me.
Final call for yay/nay?
Regards, Joe
Re: [RFC] ?
Posted by Jacob Champion <ch...@gmail.com>.
On 02/28/2017 04:32 PM, Jacob Champion wrote:
> I just don't like hamstringing a nice new directive with what's
> effectively a (rare) bug.
(The conversation kinda died shortly after I said this. That was not my
intent -- I like this directive a lot. Whether the consensus is to keep
the corner case, or introduce a new <IfSection> or <IfContainer>, or
make the arg quotable, or whatever. I don't mean to be throwing up
roadblocks.)
--Jacob
Re: [RFC] ?
Posted by Jacob Champion <ch...@gmail.com>.
On 02/28/2017 04:09 PM, Eric Covener wrote:
> But even if it wasn't, you'd also have to be interested in one being
> available when the other isn't, for it to affect <IfDirective>
Right. My concern is mostly for the following situation:
- module author provides a ModuleDirective in v1
- author realizes that a block version of said directive would make a
lot of sense
- author releases <ModuleDirective> in v2
- everyone eventually figures out, after wailing and gnashing of teeth,
that they can't use <IfDirective> to differentiate between the two
I definitely don't think this will be common. I just don't like
hamstringing a nice new directive with what's effectively a (rare) bug.
--Jacob
Re: [RFC] ?
Posted by Eric Covener <co...@gmail.com>.
On Tue, Feb 28, 2017 at 6:57 PM, Jacob Champion <ch...@gmail.com> wrote:
> mod_lua (in trunk at least) apparently ships both a '<LuaXXX>' and 'LuaXXX'
> version of several directives. It wouldn't surprise me to find that other
> third-party modules have a "block version" of a normal directive with the
> same name. I'm kind of -0.5 to making the two collide.
I think it would still be pretty rare.
But even if it wasn't, you'd also have to be interested in one being
available when the other isn't, for it to affect <IfDirective>
--
Eric Covener
covener@gmail.com
Re: [RFC] ?
Posted by Jacob Champion <ch...@gmail.com>.
On 02/27/2017 03:19 AM, Joe Orton wrote:
> On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote:
>> On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton <jo...@redhat.com> wrote:
>>> (b) for <IfDirective foo> match both "foo" and "<foo".
>>
>> I'd vote for this, it's very unlikely that some day we want to add a
>> directive called VirtualHost or If (w/o the leading '<') which may
>> conflict here, so it shouldn't hurt.
>
> I'm fine with that, I'll commit like this unless anybody else has strong
> opinions.
mod_lua (in trunk at least) apparently ships both a '<LuaXXX>' and
'LuaXXX' version of several directives. It wouldn't surprise me to find
that other third-party modules have a "block version" of a normal
directive with the same name. I'm kind of -0.5 to making the two collide.
Is there a good reason that quoting the argument to a block gives a
syntax error? Can we fix that instead?
--Jacob
Re: [RFC] ?
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Feb 22, 2017 at 10:00:08PM +0100, Yann Ylavic wrote:
> On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton <jo...@redhat.com> wrote:
> > (b) for <IfDirective foo> match both "foo" and "<foo".
>
> I'd vote for this, it's very unlikely that some day we want to add a
> directive called VirtualHost or If (w/o the leading '<') which may
> conflict here, so it shouldn't hurt.
I'm fine with that, I'll commit like this unless anybody else has strong
opinions.
Regards, Joe
Re: [RFC] ?
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Feb 22, 2017 at 11:47 AM, Joe Orton <jo...@redhat.com> wrote:
>
> It actually only works like:
>
> <IfDirective <IfFile>
>
> which is a bit ugly. Quoting the argument is a syntax error. Not sure
> how best to handle this.
>
> (b) for <IfDirective foo> match both "foo" and "<foo".
I'd vote for this, it's very unlikely that some day we want to add a
directive called VirtualHost or If (w/o the leading '<') which may
conflict here, so it shouldn't hurt.
>
> (In core.c the start_if* code is mostly common across all the functions
> and I think can be factored out, so it's possible to make core.c
> simpler/smaller net of even two more container directives.)
+1
Regards,
Yann.
Re: [RFC] ?
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Feb 21, 2017 at 02:28:52PM -0800, Jacob Champion wrote:
> I haven't tried your patch yet, but from inspection it looks like you'd have
> to do something like this if you're looking for a <Directive>:
>
> <IfDirective "<IfFile">
> ...
>
> (Note the missing closing angle bracket in the argument.) Assuming I've read
> that correctly, should we add some sugar to allow "<Directive>" to be fully
> bracketed in the argument?
It actually only works like:
<IfDirective <IfFile>
which is a bit ugly. Quoting the argument is a syntax error. Not sure
how best to handle this.
(a) ignore the problem, i.e. allow above syntax
(b) for <IfDirective foo> match both "foo" and "<foo".
(c) also add "<ifsection X>" or "<ifcontainer X>" which match
only against container type directives, and explicitly reject a leading
"<" in IfDirective
... or something else?
(In core.c the start_if* code is mostly common across all the functions
and I think can be factored out, so it's possible to make core.c
simpler/smaller net of even two more container directives.)
Regards, Joe
Re: [RFC] ?
Posted by Jacob Champion <ch...@gmail.com>.
On 02/21/2017 01:58 PM, Joe Orton wrote:
> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
> (... in a couple of decades time)?
I like it! It would be really useful for running bisections... once
we're far enough in the future, that is. I currently have to comment out
portions of the test config (including the one you pointed out,
incidentally).
I haven't tried your patch yet, but from inspection it looks like you'd
have to do something like this if you're looking for a <Directive>:
<IfDirective "<IfFile">
...
(Note the missing closing angle bracket in the argument.) Assuming I've
read that correctly, should we add some sugar to allow "<Directive>" to
be fully bracketed in the argument?
--Jacob
Re: [RFC] ?
Posted by Stefan Eissing <st...@greenbytes.de>.
Neat! +1
> Am 21.02.2017 um 22:58 schrieb Joe Orton <jo...@redhat.com>:
>
> For cases like HttpProtocolOptions where a new directive is introduced
> to multiple active branches simultaneously, it gets awkward to use
> <IfVersion> to write conf files which use the new directive but are
> compatible across multiple versions.
>
> Triggered by a conversation with a user, but also e.g. see current test
> suite t/conf/extra.conf.in which breaks for 2.4 releases older than
> 2.4.25 with:
>
> <IfVersion >= 2.2.32>
> <VirtualHost _default_:http_strict>
> DocumentRoot @SERVERROOT@/htdocs/
> HttpProtocolOptions Strict Require1.0 RegisteredMethods
>
> Any reason <IfDirective> is a bad idea, so we can do that more cleanly
> (... in a couple of decades time)?
>
> Regards, Joe
> <ap_ifdirective.diff>
Stefan Eissing
<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de