subject:"\"mod

Re: [I] x64 win compilation [httpd-mod_fcgid]

2024-07-18 Thread via GitHub



JBlond commented on issue #2:
URL: https://github.com/apache/httpd-mod_fcgid/issues/2#issuecomment-2237458160

   At https://www.apachelounge.com/viewtopic.php?t=8609 is a very simple 
tutorial using cmake


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@httpd.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: mod_fcgid Release

2020-12-17 Thread Jan Ehrhardt

Mario Brandt in gmane.comp.apache.devel (Tue, 15 Dec 2020 14:14:43
+0100):
>Ping
>
>On Thu, 24 Jan 2019 at 11:23, Mario Brandt  wrote:
>>
>> Hi,
>> it has beens a while since there was the last release of mod_fcgid.
>> There are some important fixes in trunk, but never made it to a
>> release since 2013.
>> Is anyone willing to file a release?

+1
-- 
Jan

Re: mod_fcgid Release

2020-12-15 Thread Jeff McKenna


Seconded.

-jeff



On 2020-12-15 9:14 a.m., Mario Brandt wrote:

Ping

On Thu, 24 Jan 2019 at 11:23, Mario Brandt  wrote:


Hi,
it has beens a while since there was the last release of mod_fcgid.
There are some important fixes in trunk, but never made it to a
release since 2013.
Is anyone willing to file a release?

Cheers
Mario

Re: mod_fcgid Release

2020-12-15 Thread Mario Brandt

Ping

On Thu, 24 Jan 2019 at 11:23, Mario Brandt  wrote:
>
> Hi,
> it has beens a while since there was the last release of mod_fcgid.
> There are some important fixes in trunk, but never made it to a
> release since 2013.
> Is anyone willing to file a release?
>
> Cheers
> Mario

mod_fcgid Release

2019-01-24 Thread Mario Brandt

Hi,
it has beens a while since there was the last release of mod_fcgid.
There are some important fixes in trunk, but never made it to a
release since 2013.
Is anyone willing to file a release?

Cheers
Mario

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

2016-09-30 Thread Ivan Zahariev


Hi,

Thanks for the review. You can find my comments below in the reply.


On 20.9.2016 г. 16:33 ч., Eric Covener wrote:

Unfortunately there are not many reviewers for mod_fcgid.
I tried to take as a relative laymen and had a few comments/questions:

* a few C99 // comments were added and should be zapped

Fixed.


* the assert looks funny -- no assert.   maybe ap_debug_assert() so it
blows up in maintainer builds only?
It's a paranoid check. If it ever blows the whistle, this will be in 
some very hard to reproduce case, and I don't expect that we catch this 
on a maintainer build. I made this an APLOG_CRIT message because a 
mismatch in the counts between proctable_count_all_nonfree_nodes() and 
"g_total_process" could make your FastCGI requests fail erroneously with 
an immediate 503 HTTP error. A System Administrator who could encounter 
this bug will appreciate the immediate APLOG_CRIT message in the 
"error_log".


I don't insist this to remain like this and I will change it as you say, 
in order to comply with the usual development practices. Or we can give 
this function check a better name.



* The new flag is merged, but cannot be unset?
** Probably need to make it look like an AP_INIT_FLAG

Right. I've converted this to an AP_INIT_FLAG which makes more sense.

I don't understand what you mean by "it cannot be unset". I'm merging it 
in the same way as other mod_fcgid config options. Please read below for 
more information regarding this matter.



* I couldn't follow the concept in the comments around
max_process_count moving or being per-request. Is it maybe out of
date? I think the current impl takes an existing global only and
merges it with vhost server confs but it will always be a copy.


The original implementation allows you to set "max_process_count" in the 
GLOBAL_ONLY context. This is enforced by ap_check_cmd_context() in the 
AP_INIT_TAKE1() handler, because RSRC_CONF would otherwise allow us to 
define this config option also "per vhost".


I've added the new variable "max_process_used_no_wait_enable" in the 
same way.


The original implementation works well without further magic, because it 
really uses "max_process_count" in code which works with the 
"main_server" (global) context. Now I need to access the value of 
"max_process_count" inside a "request_rec" (per VirtualHost) variable. 
If one or more mod_fcgid directives are defined not only within the main 
server config, but also as additional settings in a VirtualHost context, 
then we need to merge "max_process_count", too. If we don't merge, the 
value of "max_process_count" returned by the "request_rec" variable will 
be the default init value (zero, in our case).


Long story short -- you are right, this is a global only variable and it 
merges with vhost confs always as a copy of the global value. This is 
just a behind-the-scenes action and doesn't affect Apache 
administrators, since they can't define this variable in a vhost context 
anyway. I tried to summarize this as the comment ["global only" but we 
use its main_server value in a "request_rec"] but maybe someone can 
propose a better text.


I've committed the source code changes and you can review them again. 
When we're satisfied with the changes, I'll test the final version on 
our server fleet.


Best regards.
--Ivan

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

2016-09-20 Thread Eric Covener

On Mon, Sep 19, 2016 at 4:30 AM, Ivan Zahariev  wrote:
> Hello devs,
>
> It's been four months since I originally proposed this new feature in
> "mod_fcgid". During this time I've tested and deployed it on hundreds of
> busy production servers. It works as expected. If enabled, web visitors get
> an immediate response when FastCGI is overloaded, and no RAM is
> over-utilized.
>
> You can find all the information and a patch in the enhancement request at
> Bugzilla: https://bz.apache.org/bugzilla/show_bug.cgi?id=59656
>
> Can we get this merged into "mod_fcgid"?
>
> Best regards.
> --Ivan

Unfortunately there are not many reviewers for mod_fcgid.

I tried to take as a relative laymen and had a few comments/questions:

* a few C99 // comments were added and should be zapped
* the assert looks funny -- no assert.   maybe ap_debug_assert() so it
blows up in maintainer builds only?
* The new flag is merged, but cannot be unset?
** Probably need to make it look like an AP_INIT_FLAG
* I couldn't follow the concept in the comments around
max_process_count moving or being per-request. Is it maybe out of
date? I think the current impl takes an existing global only and
merges it with vhost server confs but it will always be a copy.

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

2016-09-19 Thread Ivan Zahariev


Hello devs,

It's been four months since I originally proposed this new feature in 
"mod_fcgid". During this time I've tested and deployed it on hundreds of 
busy production servers. It works as expected. If enabled, web visitors 
get an immediate response when FastCGI is overloaded, and no RAM is 
over-utilized.


You can find all the information and a patch in the enhancement request 
at Bugzilla: https://bz.apache.org/bugzilla/show_bug.cgi?id=59656


Can we get this merged into "mod_fcgid"?

Best regards.
--Ivan


On 2.6.2016 г. 11:57 ч., Ivan Zahariev wrote:

Hi Nick,

Thanks for the info.

I've followed your instructions and submitted an enhancement request: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=59656


Cheers.
--Ivan


On 31.5.2016 г. 13:45 ч., Nick Kew wrote:

On Tue, 2016-05-31 at 11:15 +0300, Ivan Zahariev wrote:

Hello,

I got no feedback. Am I posting this suggestion at the right mailing
list?

Sorry, I see your original post marked for attention in my mail
folder, but languishing hitherto unattended.  Just now opened your
link in a browser to take a look.  There could be others who
have done something similar.

As a general reply to this question, yes, this is the best
available mailinglist.  The other place to post it would be
as an enhancement request in bugzilla (issues.apache.org).
The keyword "PatchAvailable" there may help by marking it as
low-hanging fruit.

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

2016-06-02 Thread Ivan Zahariev


Hi Nick,

Thanks for the info.

I've followed your instructions and submitted an enhancement request: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=59656


Cheers.
--Ivan


On 31.5.2016 г. 13:45 ч., Nick Kew wrote:

On Tue, 2016-05-31 at 11:15 +0300, Ivan Zahariev wrote:

Hello,

I got no feedback. Am I posting this suggestion at the right mailing
list?

Sorry, I see your original post marked for attention in my mail
folder, but languishing hitherto unattended.  Just now opened your
link in a browser to take a look.  There could be others who
have done something similar.

As a general reply to this question, yes, this is the best
available mailinglist.  The other place to post it would be
as an enhancement request in bugzilla (issues.apache.org).
The keyword "PatchAvailable" there may help by marking it as
low-hanging fruit.

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

2016-05-31 Thread Nick Kew

On Tue, 2016-05-31 at 11:15 +0300, Ivan Zahariev wrote:
> Hello,
> 
> I got no feedback. Am I posting this suggestion at the right mailing
> list?

Sorry, I see your original post marked for attention in my mail
folder, but languishing hitherto unattended.  Just now opened your
link in a browser to take a look.  There could be others who
have done something similar.

As a general reply to this question, yes, this is the best
available mailinglist.  The other place to post it would be
as an enhancement request in bugzilla (issues.apache.org).
The keyword "PatchAvailable" there may help by marking it as
low-hanging fruit.

-- 
Nick Kew

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

2016-05-31 Thread Ivan Zahariev

Hello,

I got no feedback. Am I posting this suggestion at the right mailing list?

Best regards.
--Ivan

On 19.5.2016 г. 10:40 ч., Ivan Zahariev wrote:

Hi all,

I'd like to propose a new configuration setting for "mod_fcgid". The
source code changes to review follow:

* The whole patch compared to version 2.3.9:

https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split&name=maxnowait
* The whole patch as a single file:

https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait.patch?diff=unified&name=maxnowait
* Every single commit compared to version 2.3.9:
https://github.com/famzah/mod_fcgid/commits/maxnowait
* There should be no merge conflicts with the current "trunk"
version 2.3.10.

The motivation is that the current behavior to queue up new pending
requests differs from the RLimitNPROC directive behavior. When there
is a spike in the web hits, lots of Apache children get busy just
waiting for up to 30+ seconds to get an idle FastCGI process. Thus we
"waste" Apache children doing nothing while they could serve static
content. This also puts unneeded memory pressure. Additionally, users
today won't wait for a page to load, if it takes more than a few
seconds, and we'd rather notify them that we are currently overloaded
by sending them a 503 HTTP response immediately.

Here is the documentation for the new directive:
http://www.famzah.net/temp/FcgidMaxProcessesUsedNoWait.docs.txt

Let me know what you think.

Best regards.
--Ivan

mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

2016-05-19 Thread Ivan Zahariev


  
  
Hi all,

I'd like to propose a new configuration setting for "mod_fcgid". The
source code changes to review follow:

  The whole patch compared to version 2.3.9:
https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split&name=maxnowait
  The whole patch as a single file:
https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait.patch?diff=unified&name=maxnowait
  Every single commit compared to version 2.3.9:
https://github.com/famzah/mod_fcgid/commits/maxnowait
  There should be no merge conflicts with the current "trunk"
version 2.3.10.


The motivation is that the current behavior to queue up new pending
requests differs from the RLimitNPROC directive behavior. When there
is a spike in the web hits, lots of Apache children get busy just
waiting for up to 30+ seconds to get an idle FastCGI process. Thus
we "waste" Apache children doing nothing while they could serve
static content. This also puts unneeded memory pressure.
Additionally, users today won't wait for a page to load, if it takes
more than a few seconds, and we'd rather notify them that we are
currently overloaded by sending them a 503 HTTP response
immediately.

Here is the documentation for the new directive:
http://www.famzah.net/temp/FcgidMaxProcessesUsedNoWait.docs.txt

Let me know what you think.

Best regards.
--Ivan

Re: mod_fcgid and broken doc links

2016-01-19 Thread Jim Jagielski

There is a need and an audience for both. We provide
both. I see no reason for us to stop doing that unless
we feel that we can no longer support both in the
manner in which our community expects. FWIW, I don't
see that as the current situation.

> On Jan 18, 2016, at 9:29 PM, William A Rowe Jr  wrote:
> 
> On Mon, Jan 18, 2016 at 3:29 PM, Jim Jagielski  wrote:
> 
> > On Jan 18, 2016, at 3:28 PM, William A Rowe Jr  wrote:
> >
> > On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski  wrote:
> >
> > > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr  
> > > wrote:
> > >
> > > Good point with your example, this is something that should
> > > be benchmarked and the winner-take-all, loser bumped from the
> > > trunk/ copy of httpd.
> >
> > -1
> >
> > You are implying that one would be a winner in all cases. The
> > whole idea is that there are cases where one is better than
> > the other. We provide both.
> >
> > You might have made that inference, but I'm going to assert that
> > for this one module, for s/{literal}/{repl}, mod_sed is going to
> > outperform mod_substitute /if/ we wrote the code correctly.
> 
> I disagree... it's kind of obvious by simple inspection that
> mod_substitute has fast paths that mod_sed lacks and, as thus,
> can be quite performant and the "better" choice in numerous cases
> where that fast path is used.
> 
> Well, only benchmarking is going to prove that one way or the other,
> something I don't have free cycles for right now (committed to way too
> many other project priorities.)  And it perhaps opens up opportunities
> to optimize mod_sed in ways that might have been initially overlooked
> when the code was thrown into trunk ;-)
>  
> Me, I don't tend to think of myself as "smarter" than all of
> our users, nor do I try to act as Big Brother and remove choices
> from people in cases and situations where they are using them.
> The ASF itself doesn't do that, nor do projects... so it seems
> kinda weird that you would want the httpd project to all of
> a sudden start removing choice and options for end users instead
> of helping them out and trusting them to know which impl is
> best for them.
> 
> Thankfully, we aren't, but our users do look at us as experts in the
> code they consume, considering that we collectively have authored
> and maintain the stuff.  So they do look to us to make the best
> choices they don't have the individual time to compare and elect.
> Why would I want us to collectively (and for me specifically) to
> propose the best solutions to the common use cases, and to
> depreciate less maintained code in favor of maintained code?  
> 
> Can't imagine why I or other project members would be possessed 
> to do that.  If you figure it out, please share :)

Re: mod_fcgid and broken doc links

2016-01-18 Thread William A Rowe Jr

On Mon, Jan 18, 2016 at 3:29 PM, Jim Jagielski  wrote:

>
> > On Jan 18, 2016, at 3:28 PM, William A Rowe Jr 
> wrote:
> >
> > On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski  wrote:
> >
> > > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr 
> wrote:
> > >
> > > Good point with your example, this is something that should
> > > be benchmarked and the winner-take-all, loser bumped from the
> > > trunk/ copy of httpd.
> >
> > -1
> >
> > You are implying that one would be a winner in all cases. The
> > whole idea is that there are cases where one is better than
> > the other. We provide both.
> >
> > You might have made that inference, but I'm going to assert that
> > for this one module, for s/{literal}/{repl}, mod_sed is going to
> > outperform mod_substitute /if/ we wrote the code correctly.
>
> I disagree... it's kind of obvious by simple inspection that
> mod_substitute has fast paths that mod_sed lacks and, as thus,
> can be quite performant and the "better" choice in numerous cases
> where that fast path is used.
>

Well, only benchmarking is going to prove that one way or the other,
something I don't have free cycles for right now (committed to way too
many other project priorities.)  And it perhaps opens up opportunities
to optimize mod_sed in ways that might have been initially overlooked
when the code was thrown into trunk ;-)


> Me, I don't tend to think of myself as "smarter" than all of
> our users, nor do I try to act as Big Brother and remove choices
> from people in cases and situations where they are using them.
> The ASF itself doesn't do that, nor do projects... so it seems
> kinda weird that you would want the httpd project to all of
> a sudden start removing choice and options for end users instead
> of helping them out and trusting them to know which impl is
> best for them.
>

Thankfully, we aren't, but our users do look at us as experts in the
code they consume, considering that we collectively have authored
and maintain the stuff.  So they do look to us to make the best
choices they don't have the individual time to compare and elect.
Why would I want us to collectively (and for me specifically) to
propose the best solutions to the common use cases, and to
depreciate less maintained code in favor of maintained code?

Can't imagine why I or other project members would be possessed
to do that.  If you figure it out, please share :)

Re: mod_fcgid and broken doc links

2016-01-18 Thread Jim Jagielski

> On Jan 18, 2016, at 3:28 PM, William A Rowe Jr  wrote:
> 
> On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski  wrote:
> 
> > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr  wrote:
> >
> > Good point with your example, this is something that should
> > be benchmarked and the winner-take-all, loser bumped from the
> > trunk/ copy of httpd.
> 
> -1
> 
> You are implying that one would be a winner in all cases. The
> whole idea is that there are cases where one is better than
> the other. We provide both.
> 
> You might have made that inference, but I'm going to assert that
> for this one module, for s/{literal}/{repl}, mod_sed is going to 
> outperform mod_substitute /if/ we wrote the code correctly.

I disagree... it's kind of obvious by simple inspection that
mod_substitute has fast paths that mod_sed lacks and, as thus,
can be quite performant and the "better" choice in numerous cases
where that fast path is used.

Me, I don't tend to think of myself as "smarter" than all of
our users, nor do I try to act as Big Brother and remove choices
from people in cases and situations where they are using them.
The ASF itself doesn't do that, nor do projects... so it seems
kinda weird that you would want the httpd project to all of
a sudden start removing choice and options for end users instead
of helping them out and trusting them to know which impl is
best for them.

Re: mod_fcgid and broken doc links

2016-01-18 Thread William A Rowe Jr

On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski  wrote:

>
> > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr 
> wrote:
> >
> > Good point with your example, this is something that should
> > be benchmarked and the winner-take-all, loser bumped from the
> > trunk/ copy of httpd.
>
> -1
>
> You are implying that one would be a winner in all cases. The
> whole idea is that there are cases where one is better than
> the other. We provide both.
>

You might have made that inference, but I'm going to assert that
for this one module, for s/{literal}/{repl}, mod_sed is going to
outperform mod_substitute /if/ we wrote the code correctly.  Whas
is missing is a mod_sed directive for adding literal s/{orig}/{repl}/
patterns that follows the substitute syntax and that admins don't
have to wrap their heads around the special character escaping.
At that point, there is no reason for the redundant module, but
we aren't at that point.

Would you also recommend such a scenario with MPMs, and
> having the "winner" take all? I certainly hope not!!!
>

No, I generally agree with TMTOWTDI.  Glad you raised the MPMs
issue, because my exact complaint about folding in mod_fcgid
"as is" and overlapping with mod_proxy_fcgi was addressed by the
MPM community in pulling out and sharing the mpm_common.c
logic. Great example, thanks Jim!

Re: mod_fcgid and broken doc links

2016-01-15 Thread Jim Jagielski

> On Jan 14, 2016, at 5:19 PM, William A Rowe Jr  wrote:
> 
> 
> Good point with your example, this is something that should 
> be benchmarked and the winner-take-all, loser bumped from the
> trunk/ copy of httpd.

-1

You are implying that one would be a winner in all cases. The
whole idea is that there are cases where one is better than
the other. We provide both.

Would you also recommend such a scenario with MPMs, and
having the "winner" take all? I certainly hope not!!!

Re: mod_fcgid and broken doc links

2016-01-14 Thread William A Rowe Jr

On Thu, Jan 14, 2016 at 6:19 AM, Jim Jagielski  wrote:

>
> > On Jan 13, 2016, at 12:28 PM, William A Rowe Jr 
> wrote:
> >
> > I can see us moving those modules into trunk (not 2.4), retaining the
> > mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release
> > out of trunk/modules/fcgid/.  But I'm not clear why we would want to
> > maintain the duplication between mod_proxy_fcgi and mod_fcgid?
> > Individually they get little enough attention as it is.
>
> Because they are separate solutions to a similar problem,
> ala mod_sed and mod_substitute for example. I can site several
> more if that is worthwhile (but the point is made) mod_fcgid does
> not require the whole mod_proxy overhead, for example, but
> lacks some features that mod_proxy_fcgi does have, since the
> latter can leverage some of that "overhead".

Good point with your example, this is something that should
be benchmarked and the winner-take-all, loser bumped from the
trunk/ copy of httpd.  They are slightly different in that sed is one
specific grammar, while substitute uses literal replacements, but
that could be a syntax tweak to mod_sed to allow some literal
replacements.  In any case, it relieves the dozen or so regular
httpd contributors from maintaining two modules which do, for
the most part, the very same thing expressed with redundant
yet different code.

Likewise with fcgid/proxy_fcgi - /if/ we bring mod_fcgid sources
into the trunk, I'd add the caveat that we do so if there is an offer
to eliminate all of the code duplication in the process, or reject
this proposition.  They do perform two different purposes and
overlap in interesting ways, so there has to be something gained
by pushing fcgid upon the entire httpd committer community
to maintain.  It was one thing for the handful of us who commit
to mod_fcgid to deal with that legacy, but another to push it
mainstream.

> > Just my 2c USD, I'm open to ideas.
>
> That is good to know.

Was simply offering backstory for why things ended up as they
have, sans snark, and no snark needed in response :)  Would
love to learn who is interested in helping merge mod_fcgid and
mod_proxy_ftp functionality into a util_fcgi, or otherwise condense
this functionality into something manageable, long term.

Re: mod_fcgid and broken doc links

2016-01-14 Thread Jim Jagielski

> On Jan 13, 2016, at 12:28 PM, William A Rowe Jr  wrote:
> 
> 
> I can see us moving those modules into trunk (not 2.4), retaining the
> mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release
> out of trunk/modules/fcgid/.  But I'm not clear why we would want to
> maintain the duplication between mod_proxy_fcgi and mod_fcgid?
> Individually they get little enough attention as it is.
> 

Because they are separate solutions to a similar problem,
ala mod_sed and mod_substitute for example. I can site several
more if that is worthwhile (but the point is made) mod_fcgid does
not require the whole mod_proxy overhead, for example, but
lacks some features that mod_proxy_fcgi does have, since the
latter can leverage some of that "overhead".

> Just my 2c USD, I'm open to ideas.

That is good to know.

Re: mod_fcgid and broken doc links

2016-01-13 Thread William A Rowe Jr

On Jan 13, 2016 15:50, "Rich Bowen"  wrote:
>
> Yes, it would be nice to merge them, from the perspective of explaining
> things to users.

Guess I am still confused what you suggest to merge... Docs or both docs
and code...

Also curious about released vs unreleased with respect to docs.  Our
pointers and resources for developers mostly live under
http://httpd.a.o/dev/ per ASF policy, but docs is an exception.  We are
supposed to be pointing users at the released artifacts, and not at
unreleased drafts.

Even http://httpd.apache.org/docs/dev/  might be clearer than trunk/ for
those who stumble upon them.

Thoughts?

Re: mod_fcgid and broken doc links

2016-01-13 Thread Rich Bowen



On 01/13/2016 12:28 PM, William A Rowe Jr wrote:

> The reason for mod_ftp and mod_fcgid separate builds was historically
> that the same module, releasing on a different calendar than httpd, have
> been build-able independently against 2.0, 2.2 or 2.4.  Maintaining the 
> sources across the different branches was also something of a PITA.
> 
> Maybe more significantly, mod_proxy_fcgi was our 'adopted' solution 
> to the fcgi case.  mod_fcgid is a different beast with process pool 
> management. I was always under the impression that for 2.4 and later, 
> we collectively wanted to express process pools independently of the
> mod_proxy_fcgi structure, much like we and tomcat would love to see
> folks use mod_proxy_http or _ajp rather than mod_jk.
> 
> mod_ftp clearly isn't http:// so it never quite felt appropriate in that
> tree, but then again neither is mod_proxy_ajp :)  Which goes to the
> gist of it all, code bloat.  We've successfully only killed a tiny handful
> of modules in our entire history (imagemap, mem_cache etc). 

mod_imagemap still lives on in trunk. As does mod_cern_meta.

Point taken.

> So once merge to trunk, we own that code bloat for a very long time,
> but if it exists separate these can be enhanced or retired based on
> our desires.  E.g. if mod_aspdotnet had lived in modules/os/win32/
> we would still probably be shipping it, irrespective of how out of date
> that module becomes.
> 
> I can see us moving those modules into trunk (not 2.4), retaining the
> mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release
> out of trunk/modules/fcgid/.  But I'm not clear why we would want to
> maintain the duplication between mod_proxy_fcgi and mod_fcgid?
> Individually they get little enough attention as it is.

Yes, it would be nice to merge them, from the perspective of explaining
things to users.

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: mod_fcgid and broken doc links

2016-01-13 Thread William A Rowe Jr

On Tue, Jan 12, 2016 at 12:13 PM, Rich Bowen  wrote:

> mod_fcgid is in a separate repo from the main httpd tree, due to
> historical reasons. I presume there are good reasons for this. JimJag
> suggested on IRC it's due to its independent release cycle.
>
> Be that as it may, because it uses the standard documentation tools for
> the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
> is full of broken links. In particular, try any of the directive and
> links to other modules - try the mod_cgi or AddHandler links in the
> intro paragraph, and you'll see immediately what the problem is.
>
> Now, we could of course have a separate version of the docs building
> tools just for this module, or we could patch the doc manually, but I
> was wondering, if there's no strong current reason for the module to be
> kept separate, can we please move it into the main httpd tree?
>

The reason for mod_ftp and mod_fcgid separate builds was historically
that the same module, releasing on a different calendar than httpd, have
been build-able independently against 2.0, 2.2 or 2.4.  Maintaining the
sources across the different branches was also something of a PITA.

Maybe more significantly, mod_proxy_fcgi was our 'adopted' solution
to the fcgi case.  mod_fcgid is a different beast with process pool
management. I was always under the impression that for 2.4 and later,
we collectively wanted to express process pools independently of the
mod_proxy_fcgi structure, much like we and tomcat would love to see
folks use mod_proxy_http or _ajp rather than mod_jk.

mod_ftp clearly isn't http:// so it never quite felt appropriate in that
tree, but then again neither is mod_proxy_ajp :)  Which goes to the
gist of it all, code bloat.  We've successfully only killed a tiny handful
of modules in our entire history (imagemap, mem_cache etc).
So once merge to trunk, we own that code bloat for a very long time,
but if it exists separate these can be enhanced or retired based on
our desires.  E.g. if mod_aspdotnet had lived in modules/os/win32/
we would still probably be shipping it, irrespective of how out of date
that module becomes.

I can see us moving those modules into trunk (not 2.4), retaining the
mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release
out of trunk/modules/fcgid/.  But I'm not clear why we would want to
maintain the duplication between mod_proxy_fcgi and mod_fcgid?
Individually they get little enough attention as it is.

Just my 2c USD, I'm open to ideas.

Re: mod_fcgid and broken doc links

2016-01-13 Thread Jim Jagielski

Not just for that, but to make it easier for people
to use it... Seems stable enough that making it a
bundled module makes sense.

> On Jan 13, 2016, at 9:43 AM, Ruediger Pluem  wrote:
> 
> 
> 
> On 01/13/2016 01:33 PM, Jim Jagielski wrote:
>> Does it make sense to "officially" bundle mod_fcgid w/ httpd?
> 
> Just for fixing the documention?
> In this case I would prefer to investigate other solutions for the 
> documentation and keep it separate.
> 
> Regards
> 
> Rüdiger
>

Re: mod_fcgid and broken doc links

2016-01-13 Thread Mike Rumph


A background for this request can be seen in bug report 56121.
- https://bz.apache.org/bugzilla/show_bug.cgi?id=56121#c4
This bug also describes a manual method for working around this problem.

On 1/12/2016 10:13 AM, Rich Bowen wrote:

mod_fcgid is in a separate repo from the main httpd tree, due to
historical reasons. I presume there are good reasons for this. JimJag
suggested on IRC it's due to its independent release cycle.

Be that as it may, because it uses the standard documentation tools for
the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
is full of broken links. In particular, try any of the directive and
links to other modules - try the mod_cgi or AddHandler links in the
intro paragraph, and you'll see immediately what the problem is.

Now, we could of course have a separate version of the docs building
tools just for this module, or we could patch the doc manually, but I
was wondering, if there's no strong current reason for the module to be
kept separate, can we please move it into the main httpd tree?

(Note that exactly the same situation applies to mod_ftp, but there's
just fewer links from that doc so we don't hear it as often.)

--Rich

Re: mod_fcgid and broken doc links

2016-01-13 Thread Ruediger Pluem



On 01/13/2016 01:33 PM, Jim Jagielski wrote:
> Does it make sense to "officially" bundle mod_fcgid w/ httpd?

Just for fixing the documention?
In this case I would prefer to investigate other solutions for the 
documentation and keep it separate.

Regards

Rüdiger

Re: mod_fcgid and broken doc links

2016-01-13 Thread Jan Ehrhardt

Jim Jagielski in gmane.comp.apache.devel (Wed, 13 Jan 2016 07:33:43
-0500):
>Does it make sense to "officially" bundle mod_fcgid w/ httpd?

FWIW: I always compile mod_fcgid.so together with Apache httpd. I have
made it part of my VC 9/11/14 solution files. I guess that many Windows
users of httpd install mod_fcgid, so for them it makes sense.

Jan

Re: mod_fcgid and broken doc links

2016-01-13 Thread Jim Jagielski

Does it make sense to "officially" bundle mod_fcgid w/ httpd?

> On Jan 12, 2016, at 1:13 PM, Rich Bowen  wrote:
> 
> mod_fcgid is in a separate repo from the main httpd tree, due to
> historical reasons. I presume there are good reasons for this. JimJag
> suggested on IRC it's due to its independent release cycle.
> 
> Be that as it may, because it uses the standard documentation tools for
> the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
> is full of broken links. In particular, try any of the directive and
> links to other modules - try the mod_cgi or AddHandler links in the
> intro paragraph, and you'll see immediately what the problem is.
> 
> Now, we could of course have a separate version of the docs building
> tools just for this module, or we could patch the doc manually, but I
> was wondering, if there's no strong current reason for the module to be
> kept separate, can we please move it into the main httpd tree?
> 
> (Note that exactly the same situation applies to mod_ftp, but there's
> just fewer links from that doc so we don't hear it as often.)
> 
> --Rich
> 
> -- 
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon

mod_fcgid and broken doc links

2016-01-12 Thread Rich Bowen

mod_fcgid is in a separate repo from the main httpd tree, due to
historical reasons. I presume there are good reasons for this. JimJag
suggested on IRC it's due to its independent release cycle.

Be that as it may, because it uses the standard documentation tools for
the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
is full of broken links. In particular, try any of the directive and
links to other modules - try the mod_cgi or AddHandler links in the
intro paragraph, and you'll see immediately what the problem is.

Now, we could of course have a separate version of the docs building
tools just for this module, or we could patch the doc manually, but I
was wondering, if there's no strong current reason for the module to be
kept separate, can we please move it into the main httpd tree?

(Note that exactly the same situation applies to mod_ftp, but there's
just fewer links from that doc so we don't hear it as often.)

--Rich

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Next release of mod_fcgid

2015-06-23 Thread Jeff Trawick

On Mon, Jun 22, 2015 at 11:42 AM, Mario Brandt  wrote:

> r1604123: Lower log "graceful kill fail, sending SIGKILL" level to
> DEBUG on Windows. PR 54597.
> and
> r16041237: Follow up to r1604123: make it compile.
>
> I've now listed the fix in CHANGES-FCGID.  IMO it isn't worth rolling a
release for this.  I'm happy to T&R and help test a mod_fcgid release that
has more fixes.  IIRC, there's some low-hanging fruit in Bugzilla that
interested developers can help test and promote.

(Not to say that this fix isn't important to some people, but they can
change "WARNING" to "DEBUG"  in the right place with zero risk.)



> Cheers
> Mario
>
> On 22 June 2015 at 16:59, Jeff Trawick  wrote:
> > On Mon, Jun 22, 2015 at 10:14 AM, Mario Brandt  wrote:
> >>
> >> Hi,
> >>
> >> the last release of mod_fcgid was been a long while.
> >>
> >> There was an important bugfix on windows side in June last year.
> >>
> >> Is there anyone willing to tag and release a new version?
> >>
> >
> > There's nothing in CHANGES.  What was it?
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
> >
>



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

Re: Next release of mod_fcgid

2015-06-22 Thread Mario Brandt

r1604123: Lower log "graceful kill fail, sending SIGKILL" level to
DEBUG on Windows. PR 54597.
and
r16041237: Follow up to r1604123: make it compile.

Cheers
Mario

On 22 June 2015 at 16:59, Jeff Trawick  wrote:
> On Mon, Jun 22, 2015 at 10:14 AM, Mario Brandt  wrote:
>>
>> Hi,
>>
>> the last release of mod_fcgid was been a long while.
>>
>> There was an important bugfix on windows side in June last year.
>>
>> Is there anyone willing to tag and release a new version?
>>
>
> There's nothing in CHANGES.  What was it?
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>

Re: Next release of mod_fcgid

2015-06-22 Thread Jeff Trawick

On Mon, Jun 22, 2015 at 10:14 AM, Mario Brandt  wrote:

> Hi,
>
> the last release of mod_fcgid was been a long while.
>
> There was an important bugfix on windows side in June last year.
>
> Is there anyone willing to tag and release a new version?
>
>
There's nothing in CHANGES.  What was it?

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

Next release of mod_fcgid

2015-06-22 Thread Mario Brandt

Hi,

the last release of mod_fcgid was been a long while.

There was an important bugfix on windows side in June last year.

Is there anyone willing to tag and release a new version?


Cheers
Mario

Re: mod_fcgid kill all subprocesses in reload

2014-12-28 Thread Stefan Priebe


Am 26.12.2014 um 17:49 schrieb Mario Brandt:

Hi,
there is a patch for busy processes
https://issues.apache.org/bugzilla/show_bug.cgi?id=48769 Maybe that is
a starting point.


Thanks, this helps a lot. Still wondering why it isn't upstream.

Stefan

Re: mod_fcgid kill all subprocesses in reload

2014-12-26 Thread Mario Brandt

Hi,
there is a patch for busy processes
https://issues.apache.org/bugzilla/show_bug.cgi?id=48769 Maybe that is
a starting point.

Cheers
Mario

On 26 December 2014 at 07:05, Graham Dumpleton  wrote:
> Sounds like it would perhaps be for the same reason as mod_wsgi has issues
> with that sort of thing.
>
> Only Apache child worker processes get special dispensation as far as
> graceful shutdowns or reloads are concerned. If instead a module creates
> additional processes using the other child API calls in APR:
>
> http://apr.apache.org/docs/apr/1.4/group__apr__thread__proc.html#gaf8d2be452a819161aa4cd6205a17761e
>
> then when a shutdown or restart occurs they get a hard 3 seconds to shutdown
> or they will be killed with SIGKILL. Up to that 3 seconds they will be sent
> a normal SIGTERM each second to try and get them to exit.
>
> Thus there is no facility to allow them to linger longer that I know of
> unless something has been added in more recent times.
>
> Graham
>
>
> On 26 December 2014 at 16:57, Stefan Priebe - Profihost AG
>  wrote:
>>
>> Hi list,
>>
>> i like mod fcgid a lot but there's one bug which makes me crazy.
>>
>> On DSO unload (Apache reload ) all child's get killed no matter if they
>> process requests or not. This makes no sense to me httpd processes itself
>> are also kept until all requests are served.
>>
>> Stefan
>>
>> Excuse my typo sent from my mobile phone.
>
>

Re: mod_fcgid kill all subprocesses in reload

2014-12-25 Thread Graham Dumpleton

Sounds like it would perhaps be for the same reason as mod_wsgi has issues
with that sort of thing.

Only Apache child worker processes get special dispensation as far as
graceful shutdowns or reloads are concerned. If instead a module creates
additional processes using the other child API calls in APR:

http://apr.apache.org/docs/apr/1.4/group__apr__thread__proc.html#gaf8d2be452a819161aa4cd6205a17761e

then when a shutdown or restart occurs they get a hard 3 seconds to
shutdown or they will be killed with SIGKILL. Up to that 3 seconds they
will be sent a normal SIGTERM each second to try and get them to exit.

Thus there is no facility to allow them to linger longer that I know of
unless something has been added in more recent times.

Graham

On 26 December 2014 at 16:57, Stefan Priebe - Profihost AG <
s.pri...@profihost.ag> wrote:

> Hi list,
>
> i like mod fcgid a lot but there's one bug which makes me crazy.
>
> On DSO unload (Apache reload ) all child's get killed no matter if they
> process requests or not. This makes no sense to me httpd processes itself
> are also kept until all requests are served.
>
> Stefan
>
> Excuse my typo sent from my mobile phone.
>

mod_fcgid kill all subprocesses in reload

2014-12-25 Thread Stefan Priebe - Profihost AG

Hi list,

i like mod fcgid a lot but there's one bug which makes me crazy.

On DSO unload (Apache reload ) all child's get killed no matter if they process 
requests or not. This makes no sense to me httpd processes itself are also kept 
until all requests are served.

Stefan

Excuse my typo sent from my mobile phone.

Re: mod_fcgid and streaming large request bodies

2013-12-27 Thread Justin Erenkrantz

On Fri, Dec 27, 2013 at 6:42 PM, Jeff Trawick  wrote:
> It would be quite valuable if there is a limit on how much can be pre-read
> (0 for pure streaming).  Pre-reading the request body reduces the number of
> application processes or threads required, and they are usually fatter
> (sometimes dramatically so) than httpd workers.  While the current
> implementation is truly ridiculous, there's some goodness that could be
> kept.  I'll try to look through this in the next few days and see if it is
> practical to keep the best of both versions.  If no round tuits are
> available we should at least proceed with this, perhaps changing the
> directive syntax to allow a hybrid implementation in the future with no
> legacy cruft.  (Wild suggestion: FcgiPreReadRequestBody
> Off|On|Unlimited|K, where On is K)

I definitely agree that doing some type of pre-read may be often
useful before we start sending stuff via FastCGI.  Yet, the current
code structure doesn't lend itself to that very well - I guess what we
could do is convert the IPC to be opened lazily rather than always
open it.  If we do that, then I think the code changes would be
manageable.  (In our use case, reading the first say 64KB into RAM is
fine, but we definitely want to avoid spooling to disk.)

I'll see if I can find some round tuits...

Cheers.  -- justin

Re: mod_fcgid and streaming large request bodies

2013-12-27 Thread Jeff Trawick

On Fri, Dec 27, 2013 at 6:14 PM, Justin Erenkrantz wrote:

> On Fri, Dec 27, 2013 at 8:49 AM, Justin Erenkrantz
>  wrote:
> > Anyway, I'm diving into the code a bit - but, I figured it might be
> useful
> > to see if anyone else has any thoughts about how to handle large request
> > bodies with mod_fcgid.
>
> Here's a first-cut patch that compiles at least.  Cheers.  -- justin
>
> Add FcgidStreamRequestBody directive to send request body as it arrives
> without
> storing it in memory or on disk.
>

It would be quite valuable if there is a limit on how much can be pre-read
(0 for pure streaming).  Pre-reading the request body reduces the number of
application processes or threads required, and they are usually fatter
(sometimes dramatically so) than httpd workers.  While the current
implementation is truly ridiculous, there's some goodness that could be
kept.  I'll try to look through this in the next few days and see if it is
practical to keep the best of both versions.  If no round tuits are
available we should at least proceed with this, perhaps changing the
directive syntax to allow a hybrid implementation in the future with no
legacy cruft.  (Wild suggestion: FcgiPreReadRequestBody
Off|On|Unlimited|K, where On is K)


> * modules/fcgid/mod_fcgid.c
>   (fcgid_cmds): Add FcgidStreamRequestBody directive.
> * modules/fcgid/fcgid_conf.h
>   (fcgid_server_conf): Add stream_request_body/stream_request_body_set
> flags.
> * modules/fcgid/fcgid_conf.c
>   (DEFAULT_STREAM_REQUEST_BODY): Set to 0.
>   (create_fcgid_server_config): Init stream_request_body flag.
>   (merge_fcgid_server_config): Merge new stream_request_body flag.
>   (set_stream_request_body): New config helper.
> * modules/fcgid/fcgid_bridge.c
>   (add_request_body): Add a forward declaration to reduce diff (for now);
>   take fcgid_bucket_ctx param; if stream_request_body is set, don't copy
>   bucket and then call proc_write_ipc to send out that brigade and clear it
>   out before next loop iteration.
>   (bridge_request): Delay reading the request body until later.
>   (handle_request_ipc): Move add_request_body call to here and append the
> EOS
>   bucket before we do the final write of the request body.
>
> Index: modules/fcgid/fcgid_bridge.c
> ===
> --- modules/fcgid/fcgid_bridge.c (revision 1553671)
> +++ modules/fcgid/fcgid_bridge.c (working copy)
> @@ -287,6 +287,10 @@ static int getsfunc_fcgid_BRIGADE(char *buf, int l
>  return done;
>  }
>
> +static int add_request_body(request_rec *r, apr_pool_t *request_pool,
> +apr_bucket_brigade *output_brigade,
> +fcgid_bucket_ctx *bucket_ctx);
> +
>  static int
>  handle_request_ipc(request_rec *r, int role,
> apr_bucket_brigade *output_brigade,
> @@ -295,9 +299,21 @@ handle_request_ipc(request_rec *r, int role,
>  int cond_status;
>  apr_status_t rv;
>  apr_bucket_brigade *brigade_stdout;
> +apr_bucket *bucket_eos;
>  char sbuf[MAX_STRING_LEN];
>  const char *location;
>
> +if (role == FCGI_RESPONDER) {
> +rv = add_request_body(r, r->pool, output_brigade, bucket_ctx);
> +if (rv) {
> +return rv;
> +}
> +}
> +
> +/* The eos bucket now */
> +bucket_eos = apr_bucket_eos_create(r->connection->bucket_alloc);
> +APR_BRIGADE_INSERT_TAIL(output_brigade, bucket_eos);
> +
>  /* Write output_brigade to fastcgi server */
>  if ((rv = proc_write_ipc(&bucket_ctx->ipc,
>   output_brigade)) != APR_SUCCESS) {
> @@ -304,6 +320,7 @@ handle_request_ipc(request_rec *r, int role,
>  bucket_ctx->has_error = 1;
>  return HTTP_INTERNAL_SERVER_ERROR;
>  }
> +apr_brigade_cleanup(output_brigade);
>
>  /* Create brigade */
>  brigade_stdout =
> @@ -522,7 +539,8 @@ handle_request(request_rec * r, int role, fcgid_cm
>  }
>
>  static int add_request_body(request_rec *r, apr_pool_t *request_pool,
> -apr_bucket_brigade *output_brigade)
> +apr_bucket_brigade *output_brigade,
> +fcgid_bucket_ctx *bucket_ctx)
>  {
>  apr_bucket *bucket_input, *bucket_header;
>  apr_file_t *fd = NULL;
> @@ -563,8 +581,6 @@ static int add_request_body(request_rec *r, apr_po
>  return HTTP_INTERNAL_SERVER_ERROR;
>  }
>
> -
> -
>  while ((bucket_input = APR_BRIGADE_FIRST(input_brigade)) !=
> APR_BRIGADE_SENTINEL(input_brigade)) {
>  const char *data;
>  apr_size_t len;
> @

Re: mod_fcgid and streaming large request bodies

2013-12-27 Thread Justin Erenkrantz

On Fri, Dec 27, 2013 at 8:49 AM, Justin Erenkrantz
 wrote:
> Anyway, I'm diving into the code a bit - but, I figured it might be useful
> to see if anyone else has any thoughts about how to handle large request
> bodies with mod_fcgid.

Here's a first-cut patch that compiles at least.  Cheers.  -- justin

Add FcgidStreamRequestBody directive to send request body as it arrives without
storing it in memory or on disk.

* modules/fcgid/mod_fcgid.c
  (fcgid_cmds): Add FcgidStreamRequestBody directive.
* modules/fcgid/fcgid_conf.h
  (fcgid_server_conf): Add stream_request_body/stream_request_body_set flags.
* modules/fcgid/fcgid_conf.c
  (DEFAULT_STREAM_REQUEST_BODY): Set to 0.
  (create_fcgid_server_config): Init stream_request_body flag.
  (merge_fcgid_server_config): Merge new stream_request_body flag.
  (set_stream_request_body): New config helper.
* modules/fcgid/fcgid_bridge.c
  (add_request_body): Add a forward declaration to reduce diff (for now);
  take fcgid_bucket_ctx param; if stream_request_body is set, don't copy
  bucket and then call proc_write_ipc to send out that brigade and clear it
  out before next loop iteration.
  (bridge_request): Delay reading the request body until later.
  (handle_request_ipc): Move add_request_body call to here and append the EOS
  bucket before we do the final write of the request body.

Index: modules/fcgid/fcgid_bridge.c
===
--- modules/fcgid/fcgid_bridge.c (revision 1553671)
+++ modules/fcgid/fcgid_bridge.c (working copy)
@@ -287,6 +287,10 @@ static int getsfunc_fcgid_BRIGADE(char *buf, int l
 return done;
 }

+static int add_request_body(request_rec *r, apr_pool_t *request_pool,
+apr_bucket_brigade *output_brigade,
+fcgid_bucket_ctx *bucket_ctx);
+
 static int
 handle_request_ipc(request_rec *r, int role,
apr_bucket_brigade *output_brigade,
@@ -295,9 +299,21 @@ handle_request_ipc(request_rec *r, int role,
 int cond_status;
 apr_status_t rv;
 apr_bucket_brigade *brigade_stdout;
+apr_bucket *bucket_eos;
 char sbuf[MAX_STRING_LEN];
 const char *location;

+if (role == FCGI_RESPONDER) {
+rv = add_request_body(r, r->pool, output_brigade, bucket_ctx);
+if (rv) {
+return rv;
+}
+}
+
+/* The eos bucket now */
+bucket_eos = apr_bucket_eos_create(r->connection->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(output_brigade, bucket_eos);
+
 /* Write output_brigade to fastcgi server */
 if ((rv = proc_write_ipc(&bucket_ctx->ipc,
  output_brigade)) != APR_SUCCESS) {
@@ -304,6 +320,7 @@ handle_request_ipc(request_rec *r, int role,
 bucket_ctx->has_error = 1;
 return HTTP_INTERNAL_SERVER_ERROR;
 }
+apr_brigade_cleanup(output_brigade);

 /* Create brigade */
 brigade_stdout =
@@ -522,7 +539,8 @@ handle_request(request_rec * r, int role, fcgid_cm
 }

 static int add_request_body(request_rec *r, apr_pool_t *request_pool,
-apr_bucket_brigade *output_brigade)
+apr_bucket_brigade *output_brigade,
+fcgid_bucket_ctx *bucket_ctx)
 {
 apr_bucket *bucket_input, *bucket_header;
 apr_file_t *fd = NULL;
@@ -563,8 +581,6 @@ static int add_request_body(request_rec *r, apr_po
 return HTTP_INTERNAL_SERVER_ERROR;
 }

-
-
 while ((bucket_input = APR_BRIGADE_FIRST(input_brigade)) !=
APR_BRIGADE_SENTINEL(input_brigade)) {
 const char *data;
 apr_size_t len;
@@ -615,7 +631,9 @@ static int add_request_body(request_rec *r, apr_po
 return HTTP_INTERNAL_SERVER_ERROR;
 }

-if (request_size > sconf->max_mem_request_len) {
+if (sconf->stream_request_body) {
+bucket_stdin = bucket_input;
+} else if (request_size > sconf->max_mem_request_len) {
 apr_size_t wrote_len;
 static const char *fd_key = "fcgid_fd";

@@ -701,6 +719,16 @@ static int add_request_body(request_rec *r, apr_po
 }
 APR_BRIGADE_INSERT_TAIL(output_brigade, bucket_header);
 APR_BRIGADE_INSERT_TAIL(output_brigade, bucket_stdin);
+
+if (sconf->stream_request_body) {
+/* Write output_brigade to fastcgi server */
+if ((rv = proc_write_ipc(&bucket_ctx->ipc,
+ output_brigade)) != APR_SUCCESS) {
+bucket_ctx->has_error = 1;
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+apr_brigade_cleanup(output_brigade);
+}
 }

 apr_brigade_cleanup(input_brigade);
@@ -731,7 +759,6 @@ static int add_request_body(request_rec *

mod_fcgid and streaming large request bodies

2013-12-27 Thread Justin Erenkrantz

Hi all!

I'm currently using FastCGI for an application - in particular, Ceph's
radosgw (S3 endpoint).  I was told to use mod_fastcgi as mod_fcgid doesn't
handle large request bodies appropriately.  Yet, when I looked at the
mod_fastcgi code, I shrieked in horror.  =)

In looking at add_request_body in fcgid_bridge.c, it looks like we read the
request body into memory and if it crosses a threshold, we spool it to
disk.  After everything is read from the client, then mod_fcgid begins to
write to the FastCGI socket.  In my use case, we would be PUT'ing large
request bodies that are many GB in size - so, I'd rather just stream it to
the FastCGI socket and take the hit on potentially blocking other incoming
requests.  (In our case, it makes no sense to spool the request body to
local disk.)

Anyway, I'm diving into the code a bit - but, I figured it might be useful
to see if anyone else has any thoughts about how to handle large request
bodies with mod_fcgid.

Happy holidays!  -- justin

[ANNOUNCE] mod_fcgid 2.3.9 released

2013-10-08 Thread Jeff Trawick

 The Apache Software Foundation and the Apache HTTP Server Project are
  pleased to announce the release of version 2.3.9 of mod_fcgid, a
  FastCGI implementation for Apache HTTP Server versions 2.0, 2.2, and
  2.4.  This version of mod_fcgid is a security release, resolving a
  defect that could result in a denial of service with some applications.
  Other fixes and improvements are also included in this release.

  mod_fcgid is available for download from:

http://httpd.apache.org/download.cgi#mod_fcgid

  A full list of changes in this release follows:

  *) SECURITY: CVE-2013-4365 (cve.mitre.org)
 Fix possible heap buffer overwrite.  Reported and solved by:
 [Robert Matthews ]

  *) Add experimental cmake-based build system for Windows.  [Jeff Trawick]

  *) Correctly parse quotation and escaped spaces in FcgidWrapper and the
 AAA Authenticator/Authorizor/Access directives' command line argument,
 as currently documented.  PR 51194  [William Rowe]

  *) Honor quoted FcgidCmdOptions arguments (notably for InitialEnv
 assignments).  PR 51657  [William Rowe]

  *) Conform script response parsing with mod_cgid and ensure no response
 body is sent when ap_meets_conditions() determines that request
 conditions are met.  [Chris Darroch]

  *) Improve logging in access control hook functions.  [Chris Darroch]

  *) Avoid making internal sub-requests and processing Location headers
 when in FCGI_AUTHORIZER mode, as the auth hook functions already
 treat Location headers returned by scripts as an error since
 redirections are not meaningful in this mode.  [Chris Darroch]

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-07 Thread William A. Rowe Jr.

Excellent, although I was not able to test, I was more than happy to laud
one extra 'officious' +1 based on non-member, community review.  This has
been subject to almost more scrutiny than several core httpd releases :)

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-07 Thread Jeff Trawick

On Fri, Oct 4, 2013 at 5:16 PM, Jeff Trawick  wrote:

> Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/
>
> Shortcut to changes:
> http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID
>
> The difference with 2.3.8 is that one of the regressions found in 2.3.8
> has been reverted and and the other has been fixed.
>
> +/-1
> [  ] Release mod_fcgid 2.3.9 as GA
>
> I'll hold the vote open for 72 hours unless something out of the ordinary
> occurs.
>
> Thanks in advance for testing!
>

The vote is successful, and mod_fcgid 2.3.9 is on its way to the mirrors.

Thanks to members of the community for your invaluable assistance with
getting this new release ready!

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-07 Thread Piotr Kloc


W dniu 2013-10-07 18:13, Jeff Trawick pisze:
On Fri, Oct 4, 2013 at 5:16 PM, Jeff Trawick <mailto:traw...@gmail.com>> wrote:


Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

Shortcut to changes:
http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID

The difference with 2.3.8 is that one of the regressions found in
2.3.8 has been reverted and and the other has been fixed.

+/-1
[  ] Release mod_fcgid 2.3.9 as GA

I'll hold the vote open for 72 hours unless something out of the
ordinary occurs.


We're getting fairly close.  If someone still plans to test and might 
need a little extra time, please let me know on this thread.



I have tested this on few servers with about 2000 vhosts and all is ok

Piotr

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-07 Thread Jeff Trawick

On Fri, Oct 4, 2013 at 5:16 PM, Jeff Trawick  wrote:

> Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/
>
> Shortcut to changes:
> http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID
>
> The difference with 2.3.8 is that one of the regressions found in 2.3.8
> has been reverted and and the other has been fixed.
>
> +/-1
> [  ] Release mod_fcgid 2.3.9 as GA
>
> I'll hold the vote open for 72 hours unless something out of the ordinary
> occurs.
>

We're getting fairly close.  If someone still plans to test and might need
a little extra time, please let me know on this thread.


> Thanks in advance for testing!
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



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

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-06 Thread Chris Darroch


Jeff Trawick wrote:

[ ] Release mod_fcgid 2.3.9 as GA

+1

Chris.

--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820  6715 F54F E648 0883 35A9

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-06 Thread Jeff Trawick

On Sun, Oct 6, 2013 at 6:44 AM, Steffen  wrote:

>  From the docu: FcgidIdleTimeout , Application processes which have not
> handled a request for this period of time will be terminated, if the number
> of processses for the class exceeds FcgidMinProcessesPerClass.
>
> The  FcgidMinProcessesPerClass is default (3), so not exit with two
> processes should be ok. had read the docu before.
>
> Not tested for more processes (yet)
>

I could see processes exiting not long after FcgidIdleTimeout with this
setting:

FcgidIdleTimeout 30
FcgidMinProcessesPerClass 1
FcgidIdleScanInterval 3

Without that last directive, it will only look for idle processes every two
minutes.  FcgidZombieScanInterval might reduce the window where a process
is thought to be exiting, but I haven't tried that.

With both 2.3.7 and 2.3.9, the message "mod_fcgid: process  graceful
kill fail, sending SIGKILL" seems to be prevalent.  I wonder how many times
the graceful kill works.



> Left to have attention: Stopping Apache does not exit/kill the running
> processes, not sure it is regression
>

I only tested with php-cgi.exe processes, and they seem to die a few
seconds after I initiated shutdown, with both 2.3.7 and 2.3.9.

2.3.7 added this directive, which I haven't tried:

http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidwin32preventorphans

 But I haven't seen an issue with exiting processes anyway.


> On Sunday 06/10/2013 at 12:13, Steffen wrote:
>
> Maybe other testers can have a look:
>
> Tested with 2.2.25 Win32.
>
> Stopping Apache does not exit/kill the running processes
>
> Processes with FcgidIdleTimeout more then 300 (default) is still there, a
> process has 2016 seconds and stays with 20 accesses and it does not
> exit/kill:
>
> PidActiveIdleAccessesState15682357201620Ready596023594036Ready
>
> Ok exit, when processes reach:
> FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000
> FcgidMaxRequestsPerProcess 1000
>
>
>
>
> On Friday 04/10/2013 at 23:16, Jeff Trawick wrote:
>
> Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/
>
> Shortcut to changes:
> http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID
>
> The difference with 2.3.8 is that one of the regressions found in 2.3.8
> has been reverted and and the other has been fixed.
>
> +/-1
> [  ] Release mod_fcgid 2.3.9 as GA
>
> I'll hold the vote open for 72 hours unless something out of the ordinary
> occurs.
>
> Thanks in advance for testing!
>
> --
> Born in Roswell... married an alien...
> http://emptyhamm**ock.com/ <http://emptyhammock.com/>
>
>
>
>


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

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-06 Thread Steffen



From the docu: FcgidIdleTimeout , Application processes which have not 
handled a request for this period of time will be terminated, if the 
number of processses for the class exceeds FcgidMinProcessesPerClass.


The  FcgidMinProcessesPerClass is default (3), so not exit with two 
processes should be ok. had read the docu before.



Not tested for more processes (yet)


Left to have attention: Stopping Apache does not exit/kill the running 
processes, not sure it is regression



On Sunday 06/10/2013 at 12:13, Steffen  wrote:



Maybe other testers can have a look:

Tested with 2.2.25 Win32.

Stopping Apache does not exit/kill the running processes

Processes with FcgidIdleTimeout more then 300 (default) is still 
there, a process has 2016 seconds and stays with 20 accesses and it 
does not exit/kill:


PidActiveIdleAccessesState15682357201620Ready596023594036Ready

Ok exit, when processes reach:
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000

FcgidMaxRequestsPerProcess 1000





On Friday 04/10/2013 at 23:16, Jeff Trawick  wrote:



Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

Shortcut to changes: 
http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID


The difference with 2.3.8 is that one of the regressions found in 
2.3.8 has been reverted and and the other has been fixed.


+/-1
[  ] Release mod_fcgid 2.3.9 as GA

I'll hold the vote open for 72 hours unless something out of the 
ordinary occurs.


Thanks in advance for testing!
--
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-06 Thread Steffen



Maybe other testers can have a look:

Tested with 2.2.25 Win32.

Stopping Apache does not exit/kill the running processes

Processes with FcgidIdleTimeout more then 300 (default) is still 
there, a process has 2016 seconds and stays with 20 accesses and it 
does not exit/kill:


PidActiveIdleAccessesState15682357201620Ready596023594036Ready

Ok exit, when processes reach:
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000

FcgidMaxRequestsPerProcess 1000





On Friday 04/10/2013 at 23:16, Jeff Trawick  wrote:



Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

Shortcut to changes: 
http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID


The difference with 2.3.8 is that one of the regressions found in 
2.3.8 has been reverted and and the other has been fixed.


+/-1
[  ] Release mod_fcgid 2.3.9 as GA

I'll hold the vote open for 72 hours unless something out of the 
ordinary occurs.


Thanks in advance for testing!
--
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-05 Thread Jeff Trawick

On Fri, Oct 4, 2013 at 5:16 PM, Jeff Trawick  wrote:

> Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/
>
> Shortcut to changes:
> http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID
>
> The difference with 2.3.8 is that one of the regressions found in 2.3.8
> has been reverted and and the other has been fixed.
>
> +/-1
>


 [X] Release mod_fcgid 2.3.9 as GA

Ubuntu 12.10 64-bit: built with configure.apxs, tested with 64-bit builds
of httpd 2.2.x HEAD and httpd 2.4.x HEAD
Windows 7: built with VS2012 and cmaket, tested with 64-bit build of httpd
2.4.x HEAD

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

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-04 Thread Mario Brandt

 [+1 ] Release mod_fcgid 2.3.9 as GA
works for me on Debian 7 (x64)

Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c

2013-10-04 Thread Chris Darroch


Jeff Trawick wrote:


 The app is out of spec either way.  I think the trunk behavior is better.


  I'd agree on both counts (the latter IMHO, of course).  For reference,
here's a breakdown of 2.3.7 vs. trunk behaviour for Authorizers:

Authorizer response2.3.7   trunk
====   =
200proceed proceed
200 + rel Location 200 + munged out + err  401
200 + bad rel Location 404 + munged err + err  401
200 + abs Location 302 + Location  401
all other  401 401

  I'll try to run some quick smoke tests on your 2.3.9 over the weekend;
thanks again for pushing this along.

Chris.

--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820  6715 F54F E648 0883 35A9

Re: [VOTE] Release mod_fcgid 2.3.9

2013-10-04 Thread Gregg Smith


Works for me
VC9 x86 & x64
VC12 x86 & x64
XP, Server 2003, Vista & Server 2012

[+1] Release mod_fcgid 2.3.9 as GA

[VOTE] Release mod_fcgid 2.3.9

2013-10-04 Thread Jeff Trawick

Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

Shortcut to changes:
http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID

The difference with 2.3.8 is that one of the regressions found in 2.3.8 has
been reverted and and the other has been fixed.

+/-1
[  ] Release mod_fcgid 2.3.9 as GA

I'll hold the vote open for 72 hours unless something out of the ordinary
occurs.

Thanks in advance for testing!

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

1 2 3 4 5 6 7 8 >

1 - 100 of 726 matches

Mail list logo