Mailing List Archive: Apache: Dev

[mod_fcgid] Feedback / Suggestions

1 2

View All

Index | Next | Previous | View Threaded

ef-lists at email

Nov 24, 2009, 7:05 AM

Post #1 of 27 (2243 views)
Permalink

[mod_fcgid] Feedback / Suggestions

Hi dev,

I'd like to suggest to following changes / offer feedback for mod_fcgid:

(1)
mod_fcgid should be capable of specifying an external FCGI server.

Assume a scenario where the backend FCGI server (e.g. PHP with
php-fpm) runs for security considerations prespawned on a separate
machine with a firewall only letting FCGI traffic through.

This is possible with mod_proxy_fcgi or mod_fastcgi (with
mod_proxy_fcgi only being in trunk and mod_fastcgi kinda outdated).

(2)
In conjunction with (1), mod_fcgid should be able to select the backend
server based on request data.

Current, this kind of behaviour is possible with mod_proxy and
mod_proxy_fcgi using either interpolated environment variables and/or
mod_rewrite with the [P] suffix in a RewriteRule.

Unfortunately mod_proxy_fcgi currently exists only in trunk, seems to
be kind of abandoned and has some bugs (I filed two bug reports in BZ
under 48272 and 48273).

As mod_fcgid seems to be the current "weapon of choice", it would be
great to have this feature(s) in mod_fcgid (or mod_proxy_fcgi fixed
otherwise).

Admittedly I have a urgent need for this feature in a production
environment. If this feature can't be implemented (respectivly fixed)
in the near future (which can I fully understand as a software
developer), what would be your suggestion to get an Apache running this
way? I'd really hate it to abandon Apache because of this (and am
willing to do something against it as far as I still have time in my
current project)

(3)
mod_fcgid currently buffers the complete input from the client
(occasionaly in a temp-file if the request is large) before it passes it
through to a FCGI backend. Could this be made configurable in a way like
File|Memory|Pipeline? (file - as is | memory - buffer in memory always
| pipeline - directly pass the read data to the backend)

Or otherwise, can someone explain the details to me why it is as it is?
Especially in terms of not pipeling data directly (maybe after a little
buffering to build proper FCGI packets)? The comment in
fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
keep the server in processing too long? Processing takes its time either
way, I'd assume. Looking forward to enlightment. :)

(4)
Would it make sense to use the FCGI feature to multiplex several
requests over a single connection? Does any backend support this
feature anyway?
When thinking of an external FCGI backend with a socket connection and
very high Requests/s, this could keep open connections and
used/available ports much lower.

Really looking forward to your comments.
Regards,
Edgar Frank

trawick at gmail

Nov 24, 2009, 7:24 AM

Post #2 of 27 (2190 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank <ef-lists [at] email> wrote:
> Hi dev,
>
> I'd like to suggest to following changes / offer feedback for mod_fcgid:

my 2cents below

>
> (1)
> mod_fcgid should be capable of specifying an external FCGI server.
> (2)
> In conjunction with (1), mod_fcgid should be able to select the backend
> server based on request data.

I'd much rather see effort put into mod_proxy_fcgi to support this use
case. I wish somebody, perhaps myself, had time to work on it. It
doesn't seem that hard a task.

In the interim, is mod_fastcgi really that bad?

>
> (3)
> mod_fcgid currently buffers the complete input from the client
> (occasionaly in a temp-file if the request is large) before it passes it
> through to a FCGI backend. Could this be made configurable in a way like
> File|Memory|Pipeline? (file - as is | memory - buffer in memory always
> | pipeline - directly pass the read data to the backend)

This will definitely be resolved ;)

>
> Or otherwise, can someone explain the details to me why it is as it is?
> Especially in terms of not pipeling data directly (maybe after a little
> buffering to build proper FCGI packets)? The comment in
> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
> keep the server in processing too long? Processing takes its time either
> way, I'd assume. Looking forward to enlightment. :)

I can only guess that the problem at hand when this was implemented
was that some backend application processes were so expensive that
that they couldn't be tied up until all data had been read from slow
clients.

> (4)
> Would it make sense to use the FCGI feature to multiplex several
> requests over a single connection? Does any backend support this
> feature anyway?

no idea here

> When thinking of an external FCGI backend with a socket connection and
> very high Requests/s, this could keep open connections and
> used/available ports much lower.

olafvdspek at gmail

Nov 24, 2009, 7:34 AM

Post #3 of 27 (2182 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 4:24 PM, Jeff Trawick <trawick [at] gmail> wrote:
>> (1)
>> mod_fcgid should be capable of specifying an external FCGI server.
>> (2)
>> In conjunction with (1), mod_fcgid should be able to select the backend
>> server based on request data.
>
> I'd much rather see effort put into mod_proxy_fcgi to support this use
> case. I wish somebody, perhaps myself, had time to work on it. It
> doesn't seem that hard a task.

What was the reason to import mod_fcgi again? Wasn't the ETA of
mod_proxy_fcgi too high?

> In the interim, is mod_fastcgi really that bad?

I assume mod_fcgi wasn't developed without proper reason.

Olaf

trawick at gmail

Nov 24, 2009, 7:47 AM

Post #4 of 27 (2182 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 10:34 AM, Olaf van der Spek
<olafvdspek [at] gmail> wrote:
> On Tue, Nov 24, 2009 at 4:24 PM, Jeff Trawick <trawick [at] gmail> wrote:
>>> (1)
>>> mod_fcgid should be capable of specifying an external FCGI server.
>>> (2)
>>> In conjunction with (1), mod_fcgid should be able to select the backend
>>> server based on request data.
>>
>> I'd much rather see effort put into mod_proxy_fcgi to support this use
>> case. �I wish somebody, perhaps myself, had time to work on it. �It
>> doesn't seem that hard a task.
>
> What was the reason to import mod_fcgi again? Wasn't the ETA of
> mod_proxy_fcgi too high?

mod_fcgid was imported because it was

* widely used
* not actively maintained
* httpd developers were willing to adopt it

I felt that it was a nice addition particularly because it had a
different approach to this important problem space compared with
mod_proxy_fcgi.

>
>> In the interim, is mod_fastcgi really that bad?
>
> I assume mod_fcgi wasn't developed without proper reason.

So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to
continue doing so in the future.)

The situation at hand seems to be

* mod_proxy_fcgi promises to meet those requirements but falls short at present
* mod_fcgid doesn't even try
* mod_fastcgi implements at least some of those requirements and is mature

pqf at mailtech

Nov 24, 2009, 7:50 AM

Post #5 of 27 (2186 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

--------------------------------------------------
From: "Jeff Trawick" <trawick [at] gmail>
Sent: Tuesday, November 24, 2009 11:24 PM
To: <dev [at] httpd>
Subject: Re: [mod_fcgid] Feedback / Suggestions

> On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank <ef-lists [at] email> wrote:
>> Hi dev,
>>
>> I'd like to suggest to following changes / offer feedback for mod_fcgid:
>
> my 2cents below
>
>>
>> (1)
>> mod_fcgid should be capable of specifying an external FCGI server.
>> (2)
>> In conjunction with (1), mod_fcgid should be able to select the backend
>> server based on request data.
>
> I'd much rather see effort put into mod_proxy_fcgi to support this use
> case. I wish somebody, perhaps myself, had time to work on it. It
> doesn't seem that hard a task.
>
> In the interim, is mod_fastcgi really that bad?
>
>>
>> (3)
>> mod_fcgid currently buffers the complete input from the client
>> (occasionaly in a temp-file if the request is large) before it passes it
>> through to a FCGI backend. Could this be made configurable in a way like
>> File|Memory|Pipeline? (file - as is | memory - buffer in memory always
>> | pipeline - directly pass the read data to the backend)
>
> This will definitely be resolved ;)
>
Pipeline is a little complex. FastCGI process would write during reading. so
mod_fcgid should check both read and write on the socket, and read/write while
the socket is readable/writeable.
But is do-able :) Any one interesting?

>>
>> Or otherwise, can someone explain the details to me why it is as it is?
>> Especially in terms of not pipeling data directly (maybe after a little
>> buffering to build proper FCGI packets)? The comment in
>> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
>> keep the server in processing too long? Processing takes its time either
>> way, I'd assume. Looking forward to enlightment. :)
>
> I can only guess that the problem at hand when this was implemented
> was that some backend application processes were so expensive that
> that they couldn't be tied up until all data had been read from slow
> clients.
>
Yes, Jeff is right :)

>> (4)
>> Would it make sense to use the FCGI feature to multiplex several
>> requests over a single connection? Does any backend support this
>> feature anyway?
>
> no idea here
>
In this case, one httpd thread(process) will have to bind to one FastCGI process.
I don't think connect() to a local pipe/unix domain socket is the bottle-neck, so let it be?

>> When thinking of an external FCGI backend with a socket connection and
>> very high Requests/s, this could keep open connections and
>> used/available ports much lower.
>
connect() may be bottle-neck if using external FCGI backend. But now mod_fcgid don't support
external FCGI backend yet.

olafvdspek at gmail

Nov 24, 2009, 7:58 AM

Post #6 of 27 (2179 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 4:47 PM, Jeff Trawick <trawick [at] gmail> wrote:
>> What was the reason to import mod_fcgi again? Wasn't the ETA of
>> mod_proxy_fcgi too high?
>
> mod_fcgid was imported because it was
>
> * widely used
> * not actively maintained
> * httpd developers were willing to adopt it
>
> I felt that it was a nice addition particularly because it had a
> different approach to this important problem space compared with
> mod_proxy_fcgi.

What advantages does fcgid have over proxy_fcgi (except being ready)?

>>
>>> In the interim, is mod_fastcgi really that bad?
>>
>> I assume mod_fcgi wasn't developed without proper reason.
>
> So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to
> continue doing so in the future.)
>
> The situation at hand seems to be
>
> * mod_proxy_fcgi promises to meet those requirements but falls short at present
> * mod_fcgid doesn't even try
> * mod_fastcgi implements at least some of those requirements and is mature

mod_fcgid isn't in 2.2, right?
So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi
expected to be not ready for 2.4?

Olaf

olafvdspek at gmail

Nov 24, 2009, 8:00 AM

Post #7 of 27 (2181 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 4:50 PM, pqf <pqf [at] mailtech> wrote:
> In this case, one httpd thread(process) will have to bind to one FastCGI process.
> I don't think connect() to a local pipe/unix domain socket is the bottle-neck, so let it be?

Doesn't it require an extra round trip? It's probably not too bad, but
would be nice to avoid.

Olaf

trawick at gmail

Nov 24, 2009, 8:03 AM

Post #8 of 27 (2186 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 10:58 AM, Olaf van der Spek
<olafvdspek [at] gmail> wrote:
> On Tue, Nov 24, 2009 at 4:47 PM, Jeff Trawick <trawick [at] gmail> wrote:
>>> What was the reason to import mod_fcgi again? Wasn't the ETA of
>>> mod_proxy_fcgi too high?
>>
>> mod_fcgid was imported because it was
>>
>> * widely used
>> * not actively maintained
>> * httpd developers were willing to adopt it
>>
>> I felt that it was a nice addition particularly because it had a
>> different approach to this important problem space compared with
>> mod_proxy_fcgi.
>
> What advantages does fcgid have over proxy_fcgi (except being ready)?

integrated, on-demand process management

>
>>>
>>>> In the interim, is mod_fastcgi really that bad?
>>>
>>> I assume mod_fcgi wasn't developed without proper reason.
>>
>> So do I. �(FWIW, I've put a lot of time into mod_fcgid and expect to
>> continue doing so in the future.)
>>
>> The situation at hand seems to be
>>
>> * mod_proxy_fcgi promises to meet those requirements but falls short at present
>> * mod_fcgid doesn't even try
>> * mod_fastcgi implements at least some of those requirements and is mature
>
> mod_fcgid isn't in 2.2, right?

mod_fcgid is actually not bundled with the HTTP server. It is
released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk
(future httpd 2.4.x) with one delivery.

> So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi
> expected to be not ready for 2.4?

mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your baby?

trawick at gmail

Nov 24, 2009, 8:06 AM

Post #9 of 27 (2183 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 10:50 AM, pqf <pqf [at] mailtech> wrote:
>>> (3)
>>> mod_fcgid currently buffers the complete input from the client
>>> (occasionaly in a temp-file if the request is large) before it passes it
>>> through to a FCGI backend. Could this be made configurable in a way like
>>> File|Memory|Pipeline? (file - as is | memory - buffer in memory always
>>> | pipeline - directly pass the read data to the backend)
>>
>> This will definitely be resolved ;)
>>
> Pipeline is a little complex. FastCGI process would write during reading. so
> mod_fcgid should check both read and write on the socket, and read/write while
> the socket is readable/writeable.
> But is do-able :) Any one interesting?

I'm interested, but need to find adequate time. (I can certainly find
time to review and help test somebody else's implementation.)

>
>>>
>>> Or otherwise, can someone explain the details to me why it is as it is?
>>> Especially in terms of not pipeling data directly (maybe after a little
>>> buffering to build proper FCGI packets)? The comment in
>>> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
>>> keep the server in processing too long? Processing takes its time either
>>> way, I'd assume. Looking forward to enlightment. :)
>>
>> I can only guess that the problem at hand when this was implemented
>> was that some backend application processes were so expensive that
>> that they couldn't be tied up until all data had been read from slow
>> clients.
>>
> Yes, Jeff is right :)

This is a reasonable feature; once streaming to the app is implemented
this alternate mechanism can be enabled with a per-request envvar
(e.g., SetEnv in the directory or location).

olafvdspek at gmail

Nov 24, 2009, 8:08 AM

Post #10 of 27 (2181 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 5:03 PM, Jeff Trawick <trawick [at] gmail> wrote:
>> What advantages does fcgid have over proxy_fcgi (except being ready)?
>
> integrated, on-demand process management

How valuable is that?
In most cases a static number of backends seems fine.

>> mod_fcgid isn't in 2.2, right?
>
> mod_fcgid is actually not bundled with the HTTP server. It is
> released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk
> (future httpd 2.4.x) with one delivery.

Ah, nice. What's the reason it's not bundled though?

In this case, I'd love to see support for TCP/IP backends too.
Shouldn't be too hard to implement.

>> So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi
>> expected to be not ready for 2.4?
>
> mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your baby?

Olaf

ef-lists at email

Nov 24, 2009, 8:12 AM

Post #11 of 27 (2179 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

> > (1)
> > mod_fcgid should be capable of specifying an external FCGI server.
> > (2)
> > In conjunction with (1), mod_fcgid should be able to select the
> > backend server based on request data.
>
> I'd much rather see effort put into mod_proxy_fcgi to support this use
> case. I wish somebody, perhaps myself, had time to work on it. It
> doesn't seem that hard a task.

mod_proxy_fcgi already supports this use case completely, if it weren't
for the two bugs I filed.

While I see BZ#48273 as not-so-big issue, BZ#48272 presents a potential
crash for the Apache process, which excludes it for production use.
As far as I have understood the problem in BZ#48272, this is a real
design issue in mod_proxy_fcgi, as it tries to stream the response by
design while ap_scan_header_err_core wants the complete script output
by design.

> In the interim, is mod_fastcgi really that bad?

Lets say, it works (fine) in terms that you can specify an external
server.

I took modifying mod_fastcgi into account to add the functionality for
dynamic backend-switching, but refrained from doing so as the source
code is made to work with Apache 1.x/2.0/2.2 with lots of #ifdefs, only
partial APR support (handful of things are done on OS level) and
additional Win32-kludges.

Additionally, mod_fastcgi reads its backend servers at configuration
time and access them at runtime readonly. Modifying this would mean to
add thread safty to the source, if you want to use it in the worker mpm.
Considering the sourcecode, this would be a bad job.

ef-lists at email

Nov 25, 2009, 1:50 AM

Post #12 of 27 (2151 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick <trawick [at] gmail> wrote:
> >>> Or otherwise, can someone explain the details to me why it is as it is?
> >>> Especially in terms of not pipeling data directly (maybe after a little
> >>> buffering to build proper FCGI packets)? The comment in
> >>> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
> >>> keep the server in processing too long? Processing takes its time either
> >>> way, I'd assume. Looking forward to enlightment. :)
> >>
> >> I can only guess that the problem at hand when this was implemented
> >> was that some backend application processes were so expensive that
> >> that they couldn't be tied up until all data had been read from slow
> >> clients.
> >>
> > Yes, Jeff is right :)
>
> This is a reasonable feature; once streaming to the app is implemented
> this alternate mechanism can be enabled with a per-request envvar
> (e.g., SetEnv in the directory or location).

Thanks for explaining this to me.

While delving into the FCGI and CGI spec, I encountered another reason not to
stream client data directly. CGI wants an explicitly set CONTENT_LENGTH and
FCGI enforces than rather obsoletes this (last sentence in 6.2 of the FCGI
spec).
If the client sends for any reason a message body with no CONTENT_LENGTH set
or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to read the
full message body to determine the correct content length which should be
transferred to the backend.

Regards,
Edgar

graham.dumpleton at gmail

Nov 25, 2009, 2:03 AM

Post #13 of 27 (2153 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

2009/11/25 Edgar Frank <ef-lists [at] email>:
>> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick <trawick [at] gmail> wrote:
>> >>> Or otherwise, can someone explain the details to me why it is as it is?
>> >>> Especially in terms of not pipeling data directly (maybe after a little
>> >>> buffering to build proper FCGI packets)? The comment in
>> >>> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
>> >>> keep the server in processing too long? Processing takes its time either
>> >>> way, I'd assume. Looking forward to enlightment. :)
>> >>
>> >> I can only guess that the problem at hand when this was implemented
>> >> was that some backend application processes were so expensive that
>> >> that they couldn't be tied up until all data had been read from slow
>> >> clients.
>> >>
>> > Yes, Jeff is right :)
>>
>> This is a reasonable feature; once streaming to the app is implemented
>> this alternate mechanism can be enabled with a per-request envvar
>> (e.g., SetEnv in the directory or location).
>
> Thanks for explaining this to me.
>
> While delving into the FCGI and CGI spec, I encountered another reason not to
> stream client data directly. CGI wants an explicitly set CONTENT_LENGTH and
> FCGI enforces than rather obsoletes this (last sentence in 6.2 of the FCGI
> spec).
> If the client sends for any reason a message body with no CONTENT_LENGTH set
> or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to read the
> full message body to determine the correct content length which should be
> transferred to the backend.

Things can get worse. Even if CONTENT_LENGTH is sent, if you have
requests with compressed content which is decompressed by mod_deflate,
the amount of content will not actually match what CONTENT_LENGTH says
there will be as it reflects how things are before content is
decompressed.

Don't know about FASTCGI in general, but for WSGI (Python higher level
interface that can sit on CGI or FASTCGI) they have the stupid
requirement that you take CONTENT_LENGTH as being precise and that you
must not read more than CONTENT_LENGTH. If CONTENT_LENGTH isn't
provided, WSGI says you are supposed to take it as meaning no data.

For WSGI at least, means you can't have mutating input filters unless
the input filter buffers up all the request content after doing what
it does and recalculates CONTENT_LENGTH and sends through modified
value. In practice input filters don't do this.

Anyway, don't know if this is at all relevant to FASTCGI. As you point
out though, the CONTENT_LENGTH requirement does at least prevent
FASTCGI from handling chunked request content. WSGI specification has
same stupid limitation.

If things were defined so as to simply read until all input exhausted
and for CONTENT_LENGTH really only to be used as a hint or in
determining if original request body may be too large, wouldn't be
such a pain.

Graham

ef-lists at email

Nov 25, 2009, 2:37 AM

Post #14 of 27 (2167 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

2009/11/25 Graham Dumpleton <graham.dumpleton [at] gmail>
> 2009/11/25 Edgar Frank <ef-lists [at] email>:
> > While delving into the FCGI and CGI spec, I encountered another reason not
> > to stream client data directly. CGI wants an explicitly set CONTENT_LENGTH
> > and FCGI enforces than rather obsoletes this (last sentence in 6.2 of the
> > FCGI spec).
> > If the client sends for any reason a message body with no CONTENT_LENGTH
> > set or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to
> > read the full message body to determine the correct content length
> > which should be transferred to the backend.
>
> Things can get worse. Even if CONTENT_LENGTH is sent, if you have
> requests with compressed content which is decompressed by mod_deflate,
> the amount of content will not actually match what CONTENT_LENGTH says
> there will be as it reflects how things are before content is
> decompressed.

I implied this by originally meaning "read the full message body
through all input filters". Thanks for pointing this out.

> Don't know about FASTCGI in general, but for WSGI (Python higher level
> interface that can sit on CGI or FASTCGI) they have the stupid
> requirement that you take CONTENT_LENGTH as being precise and that you
> must not read more than CONTENT_LENGTH. If CONTENT_LENGTH isn't
> provided, WSGI says you are supposed to take it as meaning no data.
>
> [...]
>
> Anyway, don't know if this is at all relevant to FASTCGI. As you point
> out though, the CONTENT_LENGTH requirement does at least prevent
> FASTCGI from handling chunked request content. WSGI specification has
> same stupid limitation.

At least if you adhere strictly to the spec, you have to do it this way for
FastCGI, too. Although FastCGI provides the means to explicitly tell the
backend when the end-of-stream is hit.
I can't say if this is relevant in the real world, as there is still a chance
of more intelligent backends. I'll try it with PHP as soon as I find time for
this.

Maybe, in implementing this in mod_fcgid and making it configurable, Apache
can serve more intelligent backends better.

Regards,
Edgar

olafvdspek at gmail

Nov 25, 2009, 2:41 AM

Post #15 of 27 (2162 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Wed, Nov 25, 2009 at 11:37 AM, Edgar Frank <ef-lists [at] email> wrote:
> Maybe, in implementing this in mod_fcgid and making it configurable, Apache
> can serve more intelligent backends better.

Wouldn't it be better to have the backend tell the frontend that it
supports this feature? Manual configuration should be avoided if
possible.

Olaf

ef-lists at email

Nov 25, 2009, 3:17 AM

Post #16 of 27 (2158 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

2009/11/26 Olaf van der Spek <olafvdspek [at] gmail>
> On Wed, Nov 25, 2009 at 11:37 AM, Edgar Frank <ef-lists [at] email> wrote:
> > Maybe, in implementing this in mod_fcgid and making it configurable,
> > Apache can serve more intelligent backends better.
>
> Wouldn't it be better to have the backend tell the frontend that it
> supports this feature? Manual configuration should be avoided if
> possible.

Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
arbitrary name-value-pairs. Unfortunately there is no standard way to tell the
frontend that this feature is supported. Maybe, making the name (and expected
value) of this name-value-pair configurable in mod_fcgid could be a reasonable
way.

Edgar

olafvdspek at gmail

Nov 25, 2009, 3:22 AM

Post #17 of 27 (2157 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Wed, Nov 25, 2009 at 12:17 PM, Edgar Frank <ef-lists [at] email> wrote:
>> Wouldn't it be better to have the backend tell the frontend that it
>> supports this feature? Manual configuration should be avoided if
>> possible.
>
> Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
> arbitrary name-value-pairs. Unfortunately there is no standard way to tell the
> frontend that this feature is supported. Maybe, making the name (and expected
> value) of this name-value-pair configurable in mod_fcgid could be a reasonable
> way.

Doesn't sound reasonable either. If you introduce such a feature, it
should simply be coordinated with other FastCGI stakeholders.

Olaf

trawick at gmail

Nov 25, 2009, 3:34 AM

Post #18 of 27 (2154 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009 at 11:08 AM, Olaf van der Spek
<olafvdspek [at] gmail> wrote:
> On Tue, Nov 24, 2009 at 5:03 PM, Jeff Trawick <trawick [at] gmail> wrote:
>>> What advantages does fcgid have over proxy_fcgi (except being ready)?
>>
>> integrated, on-demand process management
>
> How valuable is that?
> In most cases a static number of backends seems fine.

compared with mod_proxy_fcgi, the little or no required
configuration/management of application processes with mod_fcgid makes
it easier for newbies and/or casual users; at the same time it is
sufficient for most sites, though perhaps with a little more config
tweaking to allow higher spawn rates or larger pools per application

>
>>> mod_fcgid isn't in 2.2, right?
>>
>> mod_fcgid is actually not bundled with the HTTP server. �It is
>> released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk
>> (future httpd 2.4.x) with one delivery.
>
> Ah, nice. What's the reason it's not bundled though?

I expect to see relatively high activity (compared with any particular
bundled module) in mod_fcgid over the next 6 months or so. Given
that,

* bundling means considerable extra work to get fixes into both httpd
trunk and the separate mod_fcgid tree that would continue to support
httpd 2.0.x/2.2.x; that gets worse when httpd 2.4 is GA, as a fix
could apply to httpd trunk, httpd 2.4.x branch, and the separate
mod_fcgid tree
* releasing of mod_fcgid fixes would be held up by the httpd release cycle

>
> In this case, I'd love to see support for TCP/IP backends too.
> Shouldn't be too hard to implement.
>
>>> So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi
>>> expected to be not ready for 2.4?
>>
>> mod_fcgid will support 2.4. �proxy-fcgi folk(s), care to speak up on your baby?
>
> Olaf
>

ef-lists at email

Nov 25, 2009, 3:54 AM

Post #19 of 27 (2160 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

2009/11/25 Olaf van der Spek <olafvdspek [at] gmail>
> > Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
> > arbitrary name-value-pairs. Unfortunately there is no standard way to tell
> > the frontend that this feature is supported. Maybe, making the name (and
> > expected value) of this name-value-pair configurable in mod_fcgid could
> > be a reasonable way.
>
> Doesn't sound reasonable either. If you introduce such a feature, it
> should simply be coordinated with other FastCGI stakeholders.

You're right, again. I'm just wondering if such a change is likely to happen.
Last update was 2002. I'd like to propose a change to the FastCGI
stakeholders, if this makes any sense from a single, unrelated person.

Edgar

olafvdspek at gmail

Nov 25, 2009, 3:57 AM

Post #20 of 27 (2151 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Wed, Nov 25, 2009 at 12:54 PM, Edgar Frank <ef-lists [at] email> wrote:
> 2009/11/25 Olaf van der Spek <olafvdspek [at] gmail>
>> > Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
>> > arbitrary name-value-pairs. Unfortunately there is no standard way to tell
>> > the frontend that this feature is supported. Maybe, making the name (and
>> > expected value) of this name-value-pair configurable in mod_fcgid could
>> > be a reasonable way.
>>
>> Doesn't sound reasonable either. If you introduce such a feature, it
>> should simply be coordinated with other FastCGI stakeholders.
>
> You're right, again. I'm just wondering if such a change is likely to happen.
> Last update was 2002. I'd like to propose a change to the FastCGI
> stakeholders, if this makes any sense from a single, unrelated person.

The official spec is unlikely to change, so you'd have to coordinate
with other web server and backend developers.

Olaf

ef-lists at email

Nov 26, 2009, 12:26 AM

Post #21 of 27 (2111 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Tue, Nov 24, 2009, Jeff Trawick <trawick [at] gmail> wrote:
> On Tue, Nov 24, 2009 , Edgar Frank <ef-lists [at] email> wrote:
> > (1)
> > mod_fcgid should be capable of specifying an external FCGI server.
> > (2)
> > In conjunction with (1), mod_fcgid should be able to select the backend
> > server based on request data.
>
> I'd much rather see effort put into mod_proxy_fcgi to support this use
> case. I wish somebody, perhaps myself, had time to work on it. It
> doesn't seem that hard a task.

Just an idea, I though about - what would you think about pulling
mod_proxy_fcgi up to the FCGI-code base of mod_fcgid? Could be kind of
difficult, as mod_fcgid is maintained separately at the moment, but IMHO
mod_fcgid has a much more sophisticated code in FCGI-communication (e.g. using
own bucket types) and adhering to the CGI standard.

If, in theory, both were sitting on the same code base, any fixes/changes/
enhancements in FCGI handling would affect and improve mod_proxy_fcgi, too.
This way, mod_proxy_fcgi would be the superior choice for externally spawned
workers (where dynamic worker selection really starts to make any sense) while
mod_fcgid cares about local workers and process management - and every module
would serve its very own purpose.

Okay, this has some downsides, too, like increased testing overhead, but in
general I like the idea.

I would be glad to hear your thoughts.

Regards,
Edgar

olafvdspek at gmail

Nov 26, 2009, 2:49 AM

Post #22 of 27 (2104 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Thu, Nov 26, 2009 at 9:26 AM, Edgar Frank <ef-lists [at] email> wrote:
>> I'd much rather see effort put into mod_proxy_fcgi to support this use
>> case. I wish somebody, perhaps myself, had time to work on it. It
>> doesn't seem that hard a task.
>
> Just an idea, I though about - what would you think about pulling
> mod_proxy_fcgi up to the FCGI-code base of mod_fcgid? Could be kind of
> difficult, as mod_fcgid is maintained separately at the moment, but IMHO
> mod_fcgid has a much more sophisticated code in FCGI-communication (e.g. using
> own bucket types) and adhering to the CGI standard.
>
> If, in theory, both were sitting on the same code base, any fixes/changes/
> enhancements in FCGI handling would affect and improve mod_proxy_fcgi, too.
> This way, mod_proxy_fcgi would be the superior choice for externally spawned
> workers (where dynamic worker selection really starts to make any sense) while
> mod_fcgid cares about local workers and process management - and every module
> would serve its very own purpose.
>
> Okay, this has some downsides, too, like increased testing overhead, but in
> general I like the idea.
>
> I would be glad to hear your thoughts.

In an ideal situation you don't have two separate modules. So don't go
that way. ;)

Spawning is nice but IMO not that important and in an ideal case you
might want to run the backend with a different user ID than the
frontend.

Olaf

barry.scott at onelan

Dec 3, 2009, 2:57 AM

Post #23 of 27 (1808 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

Jeff Trawick wrote:
> On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank <ef-lists [at] email> wrote:
>
>
> In the interim, is mod_fastcgi really that bad?
>
>
mod_fastcgi is fine for handling GET/POST requests, but it fails to
implement
Authorization or Authenication.

So yes mod_fastcgi is really bad.

mod_fcgid is a very welcome as a supported httpd module.

Barry

covener at gmail

Dec 3, 2009, 4:34 AM

Post #24 of 27 (1815 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott <barry.scott [at] onelan> wrote:
> Jeff Trawick wrote:
>>
>> On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank <ef-lists [at] email> wrote:
>>
>> In the interim, is mod_fastcgi really that bad?
>>
>
> mod_fastcgi is fine for handling GET/POST requests, but it fails to
> implement
> Authorization or Authenication.
>
> So yes mod_fastcgi is really bad.

mod_fastcgi has supported this for many years:

http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer
http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator

--
Eric Covener
covener [at] gmail

barry.scott at onelan

Dec 4, 2009, 2:30 AM

Post #25 of 27 (1779 views)
Permalink

Re: [mod_fcgid] Feedback / Suggestions [In reply to]

Eric Covener wrote:
> On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott <barry.scott [at] onelan> wrote:
>
>> Jeff Trawick wrote:
>>
>>> On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank <ef-lists [at] email> wrote:
>>>
>>> In the interim, is mod_fastcgi really that bad?
>>>
>>>
>> mod_fastcgi is fine for handling GET/POST requests, but it fails to
>> implement
>> Authorization or Authenication.
>>
>> So yes mod_fastcgi is really bad.
>>
>
> mod_fastcgi has supported this for many years:
>
> http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer
> http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator
>
>
It does not work or I'd have used it. And I tried to make it work.
There is a lot of missing code, compare to mod_fcgid implementation
of the same.

Barry

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads