Re: commercial support

[Jeff Trawick]

On Sun, Nov 23, 2014 at 2:48 AM, Issac Goldstand 
wrote:

>
>
> On 11/21/2014 4:21 PM, Victor J. Orlikowski wrote:
> > On Nov 21, 2014, at 9:01 AM, Jeff Trawick  > > wrote:
> >>
> >> * oh, and make it possible for 90% of the potential user base to be
> >> running 2.4.latest in several minutes without possibly interfering
> >> with existing software; user guide material (above) must support
> >> having the user's own application deployed behind httpd a few minutes
> >> later
> >>
> >
> > The “new hotness” making something like this possible, on Linux and OS X
> > at least, is Docker.
> > Here’s the Dockerfile in github:
> > https://github.com/docker-library/docs/tree/master/httpd
> >
> > The “deploy X application, according to how the developers spelled it
> > out, isolated from host OS environment” scenario has been pretty much
> > captured and owned by the Docker folks; they’ve done a masterful job of
> it.
>
> Docker is awesome for "get started fast" (as are Chef & Puppet) with
> best-practices, but none of those 3 solutions really deal with how to
> migrate an existing pre-2.4 config to 2.4, which I think was the point
> Jeff was trying to make.
>
> I have to admit, even given my involvement in the project, I personally
> still cringe a bit every time I need to do that upgrade.
>

I wasn't referring to an upgrade to 2.4.  Here's a little more of what I
was thinking about potential users that aren't prepared to manage Docker
images themselves:

* Docker could be a good way to give somebody a way to kick the tires with
2.4, hopefully with their app wired in automatically
* Docker would not be the right solution for someone who wants to use httpd
over the long haul (future updates to httpd+libs while maintain existing
config, etc.); beyond the complication of container layers to manage this
properly, these folks should have packaging that's managed like other
software on their system so that they don't have to learn any new concepts



>
> >
> > Best,
> > Victor
> > --
> > Victor J. Orlikowski <> victor.j.orlikow...@alumni.duke.edu
> > 
> >
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: commercial support

[Victor J. Orlikowski]

On Nov 23, 2014, at 8:11 AM, Jeff Trawick  wrote:
> 
>  Docker would not be the right solution for someone who wants to use httpd 
> over the long haul (future updates to httpd+libs while maintain existing 
> config, etc.); beyond the complication of container layers to manage this 
> properly, these folks should have packaging that's managed like other 
> software on their system so that they don't have to learn any new concepts


Hrm.

To my mind, at least on RPM-based distributions, that sounds like a set of 
prefixed RPM packages, that install into a non-default system location, and 
that can be built from APR-Util/APR/httpd source trees.

To be a bit more specific: a buildrpm.sh that takes a templated spec file, does 
the needed configure and make, and drops out a set of packages that would 
install things under /opt/local.

That about sound about right, Jeff?

Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikow...@alumni.duke.edu

Re: commercial support

[Eric Covener]

On Sun, Nov 23, 2014 at 9:53 AM, Victor J. Orlikowski
 wrote:
> To my mind, at least on RPM-based distributions, that sounds like a set of
> prefixed RPM packages, that install into a non-default system location, and
> that can be built from APR-Util/APR/httpd source trees.
>
> To be a bit more specific: a buildrpm.sh that takes a templated spec file,
> does the needed configure and make, and drops out a set of packages that
> would install things under /opt/local.
>
> That about sound about right, Jeff?

I'm not sure there's much value in this going forward (as opposed to
say 18 months ago) compared to say the doc or evangelism efforts
advocated in Jeff's other thread.

* The 2014 releases of RedHat, SLES, and Ubuntu have 2.4.
* There are already options for older RHEL (epel, although it doesn't
seem to be servied & RedHat Software Collections) and older Ubuntu (at
least 1 PPA)
* Users who can't avail of these, or the source itself, are unlikely
to move to some even more unusual way to get httpd

-- 
Eric Covener
cove...@gmail.com

Re: commercial support

[Issac Goldstand]

On 11/23/2014 4:53 PM, Victor J. Orlikowski wrote:
> On Nov 23, 2014, at 8:11 AM, Jeff Trawick  > wrote:
>>
>>  Docker would not be the right solution for someone who wants to use
>> httpd over the long haul (future updates to httpd+libs while maintain
>> existing config, etc.); beyond the complication of container layers to
>> manage this properly, these folks should have packaging that's managed
>> like other software on their system so that they don't have to learn
>> any new concepts
> 
> Hrm.
> 
> To my mind, at least on RPM-based distributions, that sounds like a set
> of prefixed RPM packages, that install into a non-default system
> location, and that can be built from APR-Util/APR/httpd source trees.
> 
> To be a bit more specific: a buildrpm.sh that takes a templated spec
> file, does the needed configure and make, and drops out a set of
> packages that would install things under /opt/local.
> 
> That about sound about right, Jeff?
> 

Again, you're focusing on the packages, but not on configuration
changes, which I think is what Jeff was trying to point out to begin
with.  I'm pretty sure that there's even a .spec file somewhere that the
project used to maintain, and possibly still does.

The package upgrade is easy, but non-backwards-compatible changes, like
the historic ones between 1.3 and 2.0, and the recent ones between
2.0/2.2 and 2.4 are the hard part.

Re: commercial support

[Victor J. Orlikowski]

On Nov 23, 2014, at 10:07 AM, Eric Covener  wrote:
> 
> I'm not sure there's much value in this going forward (as opposed to
> say 18 months ago) compared to say the doc or evangelism efforts
> advocated in Jeff's other thread.

Agreed, though I’d say that the true havoc has been in migrating configs from 
pre-2.4 to 2.4.
Perhaps *especially* when the Linux vendor bundling httpd changes versions, as 
the end user isn’t expecting it.

My personal experience with this has to do with the VM images we’ve been 
producing at my current gig; there’s a tutorial that makes use of httpd, and 
the unexpected change in the authz syntax caused a 1 day loss of time for the 
person who manages the tutorial.

If she’d reached out to me earlier, I could have saved her the time - 
but…that’s unrelated to the point.

Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikow...@alumni.duke.edu

Re: commercial support

[Victor J. Orlikowski]

On Nov 23, 2014, at 10:10 AM, Issac Goldstand  wrote:
> 
> Again, you're focusing on the packages, but not on configuration
> changes, which I think is what Jeff was trying to point out to begin
> with.  I'm pretty sure that there's even a .spec file somewhere that the
> project used to maintain, and possibly still does.
> 
> The package upgrade is easy, but non-backwards-compatible changes, like
> the historic ones between 1.3 and 2.0, and the recent ones between
> 2.0/2.2 and 2.4 are the hard part.

So - that’s been my focus, if only because Jeff mentioned the idea of wanting 
to get a new user up-to-speed quickly with 2.4, and mentioned earlier the 
issues of running into pre-installed headers, etc. being a source of pain and 
spurious bug reports.

I will *absolutely* agree with you about the configuration changes, as I’ve had 
folks working with me run head on into them.
Perhaps a tool to scan an existing configuration (single file or directory 
structure) and flag potential problems is in order?

Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikow...@alumni.duke.edu

pull windows binaries?

[Eric Covener]

2.2.25 binaries still show up under the binaries link on mirrors.
Shouldn't they be zapped?

-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1640031 - in /httpd/httpd/trunk/server/mpm: event/event.c event/fdqueue.c eventopt/eventopt.c eventopt/fdqueue.c

[Yann Ylavic]

On Sun, Nov 23, 2014 at 12:25 AM, Eric Covener  wrote:
> On Sun, Nov 16, 2014 at 4:32 PM,   wrote:
>> @@ -1010,8 +1003,6 @@ static void process_socket(apr_thread_t
>>  c = ap_run_create_connection(p, ap_server_conf, sock,
>>   conn_id, sbh, cs->bucket_alloc);
>>  if (!c) {
>> -apr_bucket_alloc_destroy(cs->bucket_alloc);
>> -apr_pool_clear(p);
>>  ap_push_pool(worker_queue_info, p);
>>  return;
>>  }
>
> first line intentional?

Yes, bucket_alloc is created on p just above, we can let it die when p
is cleared/destroyed in ap_push_pool().
This saves apr_bucket_alloc_destroy()'s walk/compare on p->cleanups
before apr_pool_clear().

Re: pull windows binaries?

[Jeff Trawick]

On Sun, Nov 23, 2014 at 10:58 AM, Eric Covener  wrote:

> 2.2.25 binaries still show up under the binaries link on mirrors.
> Shouldn't they be zapped?
>

IMO yes, because vulnerabilities were fixed in subsequent releases

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: commercial support

[Jeff Trawick]

On Sun, Nov 23, 2014 at 10:07 AM, Eric Covener  wrote:

> On Sun, Nov 23, 2014 at 9:53 AM, Victor J. Orlikowski
>  wrote:
> > To my mind, at least on RPM-based distributions, that sounds like a set
> of
> > prefixed RPM packages, that install into a non-default system location,
> and
> > that can be built from APR-Util/APR/httpd source trees.
> >
> > To be a bit more specific: a buildrpm.sh that takes a templated spec
> file,
> > does the needed configure and make, and drops out a set of packages that
> > would install things under /opt/local.
> >
> > That about sound about right, Jeff?
>

Yeah; the existing RPMs for httpd, apr, and apr-util template-ized to be
able to install elsewhere and not be part of the system packages is an
actual (but partial) solution I was thinking of as a way to make it easy
for some class of users.


> I'm not sure there's much value in this going forward (as opposed to
> say 18 months ago) compared to say the doc or evangelism efforts
> advocated in Jeff's other thread.
>
> * The 2014 releases of RedHat, SLES, and Ubuntu have 2.4.
> * There are already options for older RHEL (epel, although it doesn't
> seem to be servied & RedHat Software Collections) and older Ubuntu (at
> least 1 PPA)
> * Users who can't avail of these, or the source itself, are unlikely
> to move to some even more unusual way to get httpd
>

One thing to keep in mind about these is that the level of 2.4 will get
older and older and the default configuration differs significantly between
them.  This doesn't support goals like the following:

* actually fix/improve issues in the code and have users able to make use
of that on your timeframe, which in turn allows you to provide how-to
guides that don't have to pretend that, for example, mod_proxy only works
with TCP sockets, since probably none of the distros above have a new
enough httpd
* providing how-to guides that aren't cluttered up with distro-specific
configuration layout

--/--

At Sun we had a relocatable distribution of httpd and friends based on
something like yum or apt;  it was trivial for users to bootstrap and
install packages and keep updated, and applicable for use by root and
non-root alike.  (There was also a system package distribution.)  The
relocatable distribution was perfect for casual use (really just a couple
of minutes to get running) that can evolve into a permanently maintained
install.  Also, there was no inherent reason why any modern OS couldn't be
supported.

--/--

If you're doing Python web apps it would be cool to "pip install httpd
FRAMEWORK-httpd-wiring" and have a command that wires it up based on
framework settings and a bit of other declarative configuration.  (similar
for other ecosystems with a packaging/build infrastructure)  mod_wsgi
actually has a version in PyPI that works like this, although it doesn't
bring httpd with it.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: pull windows binaries?

[Eric Covener]

On Sun, Nov 23, 2014 at 12:30 PM, Jeff Trawick  wrote:
> On Sun, Nov 23, 2014 at 10:58 AM, Eric Covener  wrote:
>>
>> 2.2.25 binaries still show up under the binaries link on mirrors.
>> Shouldn't they be zapped?
>
>
> IMO yes, because vulnerabilities were fixed in subsequent releases

Had another look at dates and versions and just pulled everything +
minor README updates.

Re: pull windows binaries?

[Gregg Smith]

On 11/23/2014 7:58 AM, Eric Covener wrote:

2.2.25 binaries still show up under the binaries link on mirrors.
Shouldn't they be zapped?


+1

Re: commercial support

[Mark Blackman]

Is Apache 2.4 really just as fast as nginx for response times for an arbitrary 
number of concurrent connections?

Apache is great and it’s now so mature that most enterprises are very 
comfortable with it, but where nginx started with a very simple premise and 
have kept the scope restricted.

For me, Apache is a Swiss army knife that has a solution for nearly every use 
case and nginx is more like a surgeon’s scalpel, best of breed in that domain 
(maximal concurrent connections for minimum resource cost with minimum feature 
set), but unhelpful in other places.


Cheers,
Mark

> On 20 Nov 2014, at 22:00, Jim Jagielski  wrote:
> 
> It's a shame that there isn't a company like Covalent
> around anymore that focuses on the Apache httpd web-server.
> nginx.com shows kinda clearly that having a motivated
> company behind a web-server helps grab market share and
> market awareness (they can continue to beat the drum about
> how fast and reliable they are, when so many benchmarks
> lately show that 2.4 is just as fast if not faster in
> actual response time, but we have limited ability to
> do that, and most reporters see us as Old "news" and
> nginx as the new hotness anyway)...
> 
> So who wants to get together and create a company
> around httpd? :)
> 
> Honestly though, how much of the uptake in nginx
> do people think is actually due to nginx being "better"
> or the "best" choice, and how much do you think is
> due simply because it's *seen* as better or that we
> are seen as old and tired?
> 
> This is our 20year anniversary... It would be cool
> to use that to remind people! :)

Re: commercial support

[Jeff Trawick]

On Sun, Nov 23, 2014 at 4:23 PM, Mark Blackman  wrote:

> Is Apache 2.4 really just as fast as nginx for response times for an
> arbitrary number of concurrent connections?
>
> Apache is great and it’s now so mature that most enterprises are very
> comfortable with it, but where nginx started with a very simple premise and
> have kept the scope restricted.
>
> For me, Apache is a Swiss army knife that has a solution for nearly every
> use case and nginx is more like a surgeon’s scalpel, best of breed in that
> domain (maximal concurrent connections for minimum resource cost with
> minimum feature set), but unhelpful in other places.
>

The question is hard to answer satisfactorily.  You have to pick a workload
that you are familiar with and try it with both (where httpd is 2.4 with
Event MPM).  httpd is faster at some, and I'm sure that nginx is faster at
others.

Your characterization of httpd and nginx is a lot more nuanced than the
assumptions of a lot of people.  httpd is often characterized as big and
slow based on old reality and the continued use of it in old ways, and
because of that it is passed over in a lot of cases where it is the better
overall solution.



>
>
> Cheers,
> Mark
>
> > On 20 Nov 2014, at 22:00, Jim Jagielski  wrote:
> >
> > It's a shame that there isn't a company like Covalent
> > around anymore that focuses on the Apache httpd web-server.
> > nginx.com shows kinda clearly that having a motivated
> > company behind a web-server helps grab market share and
> > market awareness (they can continue to beat the drum about
> > how fast and reliable they are, when so many benchmarks
> > lately show that 2.4 is just as fast if not faster in
> > actual response time, but we have limited ability to
> > do that, and most reporters see us as Old "news" and
> > nginx as the new hotness anyway)...
> >
> > So who wants to get together and create a company
> > around httpd? :)
> >
> > Honestly though, how much of the uptake in nginx
> > do people think is actually due to nginx being "better"
> > or the "best" choice, and how much do you think is
> > due simply because it's *seen* as better or that we
> > are seen as old and tired?
> >
> > This is our 20year anniversary... It would be cool
> > to use that to remind people! :)
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1540052 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c proxy_util.c

[Eric Covener]

On Fri, Nov 8, 2013 at 9:30 AM,   wrote:
>
> URL: http://svn.apache.org/r1540052
> Log:
> UDS urls need to be desockified when configuring...
>
> Modified:
> httpd/httpd/trunk/modules/proxy/mod_proxy.c
> httpd/httpd/trunk/modules/proxy/proxy_util.c


Caution: I don't know anything about UDS in mod_prox as user much less
as a developer, but in my sandboxes with:

  ProxyPassMatch ^/test.php$
"unix:/var/run/php5-fpm.sock|fcgi://localhost/home/covener/SRC/httpd-trunk/built/htdocs/info.php"

* 2.4 works
* trunk w/o this patch works
* trunk fails because it tries to actually connect to localhost:8000
(fcgi:// default port)

Is this commit broken or did it change the syntax?

-- 
Eric Covener
cove...@gmail.com

Re: commercial support

[Graham Dumpleton]

On 24 November 2014 at 04:59, Jeff Trawick  wrote:

>
> If you're doing Python web apps it would be cool to "pip install httpd
> FRAMEWORK-httpd-wiring" and have a command that wires it up based on
> framework settings and a bit of other declarative configuration.  (similar
> for other ecosystems with a packaging/build infrastructure)  mod_wsgi
> actually has a version in PyPI that works like this, although it doesn't
> bring httpd with it.
>

Downloading and compiling the whole of httpd as a side effect of doing a
Python pip install isn't really practical. The process would just take too
long for a start, plus it doesn't solve the problem that many systems will
not have the dependencies installed in order to compile it. You don't want
to have to also be separately downloading and compiling APR, APU-UTIL and
PCRE now that they aren't bundled with the Apache source code.

I have tried going that path, albeit not triggered by pip, in trying to
create a build pack for Heroku which could be used to bring mod_wsgi to
that PaaS and it was a right pain, especially since the resulting size of
all the compiled components would chew up a significant part of the image
slug allowance that Heroku gave you. In the end I gave up on it because it
was so customised and unsupported by Heroku that no one would be likely to
use it.

So for the pip installable mod_wsgi it does at least rely on you having
httpd and the httpd-dev packages, plus any dependencies for those installed.

This still doesn't help with PaaS services which have such a narrow view of
what they want to allow you to do. For example, Heroku will not provide the
httpd and httpd-dev packages in the operating system image they use to
allow people to run it using their own custom configurations and compile
and use their own Apache modules. It even took me a couple of years at
least to get Heroku to update their Python installations so they provided
shared libraries and so allow any sort of dynamically loaded embedded
system such as the mod_wsgi module inside of Apache to be able to use their
Python installations. Before that I would have to also compile Python
source code from scratch as well.

Heroku isn't the only PaaS who has gone down a path which makes it near on
impossible to use them with Apache and a customised setup. OpenShift does
actually provide an Apache/Python/mod_wsgi cartridge, but they hardwire the
Apache configuration and you cannot change it. The particular configuration
actually has various problems in the way it is done and so provides a sub
optimal experience. They also use a very old mod_wsgi version which RHEL
version they use ships. Even if you could get around that you can't change
the Apache configuration and not even the startup command, it isn't even
possible to build an Apache module from scratch as they don't install the
httpd-dev package for RHEL.

The only PaaS where I could do what I want and use the pip installable
mod_wsgi was dotcloud. This as because it was what became docker and so
allowed a user to install the missing httpd-dev package in your own space
and so it was possible to then actually compile custom Apache modules.

So for me and turning around the rapid decline in mod_wsgi usage caused by
the narrow options most PaaS providers give you, docker is definitely the
way forward.

The idea of a pip installable mod_wsgi is therefore two fold.

The first is to work around the fact that Linux distributions ship very out
of date versions of packages. Most Linux distributions are over a dozen
releases behind on mod_wsgi.

The second is that the pip installable mod_wsgi does more than just compile
the mod_wsgi Apache module. It also installs a script called
mod_wsgi-express that automatically generates an Apache configuration for
you which is setup properly for mod_wsgi. This is what Jeff is alluding to
in saying 'a command that wires it up based on framework settings and a bit
of other declarative configuration'.

This solves another serious problem that mod_wsgi has had over the years.
That is that the default Apache configuration isn't particularly
appropriate. This is especially the case for prefork MPM where Python code
is run in embedded mode inside of the Apache child work process rather than
in mod_wsgi daemon mode, whereby the Python code runs in separate
processes. This isn't aided by what I would argue as being a somewhat
flawed child worker dynamic scaling algorithm in Apache which causes too
much process churn, negatively affecting embedded systems which have a
large startup cost.

So what mod_wsgi-express does is provide a turn key solution for setting up
Apache with Python as a form of appliance which is going to suit the
majority of cases where users are just running a single Python web
application. I can take all the knowledge I have accumulated over the years
as to what is the best way of setting up Apache for Python web applications
to avoid problems and distil that in a custom streamlined Apache
configurat

Re: svn commit: r1540052 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c proxy_util.c

[Eric Covener]

Seems to be a mix of this commit and 1609680

On Sun, Nov 23, 2014 at 7:47 PM, Eric Covener  wrote:
> On Fri, Nov 8, 2013 at 9:30 AM,   wrote:
>>
>> URL: http://svn.apache.org/r1540052
>> Log:
>> UDS urls need to be desockified when configuring...
>>
>> Modified:
>> httpd/httpd/trunk/modules/proxy/mod_proxy.c
>> httpd/httpd/trunk/modules/proxy/proxy_util.c
>
>
> Caution: I don't know anything about UDS in mod_prox as user much less
> as a developer, but in my sandboxes with:
>
>   ProxyPassMatch ^/test.php$
> "unix:/var/run/php5-fpm.sock|fcgi://localhost/home/covener/SRC/httpd-trunk/built/htdocs/info.php"
>
> * 2.4 works
> * trunk w/o this patch works
> * trunk fails because it tries to actually connect to localhost:8000
> (fcgi:// default port)
>
> Is this commit broken or did it change the syntax?
>
> --
> Eric Covener
> cove...@gmail.com



-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1609680 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h proxy_util.c

[Eric Covener]

On Fri, Jul 11, 2014 at 6:36 AM,   wrote:
> static int ap_proxy_strcmp_ematch(const char *str, const char *expected)
> +{
> +apr_size_t x, y;
> +
> +for (x = 0, y = 0; expected[y]; ++y, ++x) {
> +if ((!str[x]) && (expected[y] != '
> || !apr_isdigit(expected[y + 1])))
> +return -1;
> +if (expected[y] == ' && apr_isdigit(expected[y + 1])) {
> +while (expected[y] == ' && apr_isdigit(expected[y + 1]))
> +y += 2;
> +if (!expected[y])
> +return 0;
> +while (str[x]) {
> +int ret;
> +if ((ret = ap_proxy_strcmp_ematch(&str[x++], &expected[y])) 
> != 1)
> +return ret;
> +}
> +return -1;
> +}
> +else if (expected[y] == '\\') {
> +/* NUL is an invalid char! */
> +if (!expected[++y])
> +return -2;
> +}
> +if (str[x] != expected[y])
> +return 1;
> +}
> +return (str[x] != '\0');
> +}


This is breaking the common PHP-FPM recipes using unix domain sockets
in trunk e.g.

ProxyPassMatch ^/info.php$
"unix:/var/run/php5-fpm.sock|fcgi://localhost/home/covener/SRC/httpd-trunk/built/htdocs/"

The old test accepted the worker URL being a prefix of the worker:
 (, but now that doesn't happen for ProxyPassMatch.  This seems to be
due to the last return.






-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1609680 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h proxy_util.c

[Eric Covener]

On Sun, Nov 23, 2014 at 9:57 PM, Eric Covener  wrote:
> On Fri, Jul 11, 2014 at 6:36 AM,   wrote:
>> static int ap_proxy_strcmp_ematch(const char *str, const char *expected)
>> +{
>> +apr_size_t x, y;
>> +
>> +for (x = 0, y = 0; expected[y]; ++y, ++x) {
>> +if ((!str[x]) && (expected[y] != '
>> || !apr_isdigit(expected[y + 1])))
>> +return -1;
>> +if (expected[y] == ' && apr_isdigit(expected[y + 1])) {
>> +while (expected[y] == ' && apr_isdigit(expected[y + 1]))
>> +y += 2;
>> +if (!expected[y])
>> +return 0;
>> +while (str[x]) {
>> +int ret;
>> +if ((ret = ap_proxy_strcmp_ematch(&str[x++], &expected[y])) 
>> != 1)
>> +return ret;
>> +}
>> +return -1;
>> +}
>> +else if (expected[y] == '\\') {
>> +/* NUL is an invalid char! */
>> +if (!expected[++y])
>> +return -2;
>> +}
>> +if (str[x] != expected[y])
>> +return 1;
>> +}
>> +return (str[x] != '\0');
>> +}
>

Sorry, stray keystroke (tab?) made gmail send early.

This is breaking the common PHP-FPM recipes using unix domain sockets
in trunk e.g.

ProxyPassMatch ^/info.php$
"unix:/var/run/php5-fpm.sock|fcgi://localhost/home/covener/SRC/httpd-trunk/built/htdocs/"

The old test accepted the worker URL being a prefix of the worker:

strncmp(url_copy, worker->s->name, worker_name_length) == 0)

but now that doesn't happen for ProxyPassMatch.  This seems to be
due to the last return expecting str[x] to have been totally consumed
by the expected (worker) string.


-- 
Eric Covener
cove...@gmail.com