You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2014/03/19 16:36:51 UTC
Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_regex.h include/http_core.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c server/request.c server/util_pcre.c
As I understand it, we require PCRE_DUPNAMES functionality, right?
So I think we need to check for it at configure/build time
and bail if it isn't available.
The configure part is done in
http://svn.apache.org/r1579259
Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h
include/ap_regex.h include/http_core.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
server/core.c server/request.c server/util_pcre.c
Posted by Ruediger Pluem <rp...@apache.org>.
Jim Jagielski wrote:
> Just looking for verification here ;)
No worries.
>
> Thx!
> On Mar 19, 2014, at 12:46 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> As noted, from how I understand it, currently we allow it to
>> build BUT the behavior is not as expected or designed, since
>> the expected behavior *requires* PCRE_DUPNAMES. If we require
>> PCRE_DUPNAMES then we require it, right?
>>
>
>
Correct. As far as I remember Grahams proposal was to put the different behaviors in the documentation
as the behavior only differs in specific cases (same capture name used more then once). So IMHO the feature still
makes sense even without PCRE_DUPNAMES available.
To be honest that documentation part somehow felt through the cracks :-).
Regards
Rüdiger
Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_regex.h include/http_core.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c server/request.c server/util_pcre.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
Just looking for verification here ;)
Thx!
On Mar 19, 2014, at 12:46 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> As noted, from how I understand it, currently we allow it to
> build BUT the behavior is not as expected or designed, since
> the expected behavior *requires* PCRE_DUPNAMES. If we require
> PCRE_DUPNAMES then we require it, right?
>
Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_regex.h include/http_core.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c server/request.c server/util_pcre.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
As noted, from how I understand it, currently we allow it to
build BUT the behavior is not as expected or designed, since
the expected behavior *requires* PCRE_DUPNAMES. If we require
PCRE_DUPNAMES then we require it, right?
On Mar 19, 2014, at 12:26 PM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> wrote:
>
>
>> -----Original Message-----
>> From: Jim Jagielski > Sent: Mittwoch, 19. März 2014 16:37
>> To: httpd
>> Subject: Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES
>> include/ap_mmn.h include/ap_regex.h include/http_core.h
>> modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c
>> server/request.c server/util_pcre.c
>>
>> As I understand it, we require PCRE_DUPNAMES functionality, right?
>> So I think we need to check for it at configure/build time
>> and bail if it isn't available.
>>
>> The configure part is done in
>>
>> http://svn.apache.org/r1579259
>>
>
> Keep in mind that this causes trunk to fail building on RHEL 5 with the system provided PCRE
>
RE: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES
include/ap_mmn.h include/ap_regex.h include/http_core.h
modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c
server/request.c server/util_pcre.c
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Original Message-----
> From: Jim Jagielski > Sent: Mittwoch, 19. März 2014 16:37
> To: httpd
> Subject: Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES
> include/ap_mmn.h include/ap_regex.h include/http_core.h
> modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c
> server/request.c server/util_pcre.c
>
> As I understand it, we require PCRE_DUPNAMES functionality, right?
> So I think we need to check for it at configure/build time
> and bail if it isn't available.
>
> The configure part is done in
>
> http://svn.apache.org/r1579259
>
Keep in mind that this causes trunk to fail building on RHEL 5 with the system provided PCRE