Re: mod_gzip and static fastcgi applications

Hi,

I suggest you don't compile too much modules with your apache if what you
want is performance. My advise is to compile a FCGI only server, and use a
reverse proxy in front with mod_gzip, that way slow clients won't affect you
and your FCGI environment will be rock stable.

----- Original Message ----- 
From: "Prakash Kailasa" <[email protected]>
To: <fastcgi-developers-xGejAJT2w6yOE5Ap4OspEtHuzzzSOjJt@public.gmane.org>
Sent: Tuesday, November 09, 2004 11:15 AM
Subject: Re: [FASTCGI] mod_gzip and static fastcgi applications


> Hi,
>
> I am sure this list has more important things to talk about, but can I
> get some response to my question? Please?
>
> I just want to know if the modification made to accommodate mod_gzip
> was appropriate and does not break things otherwise. We have been
> testing it without any problems so far, and admittedly this is very
> tiny change, but I don't know fastcgi code well, so I'd feel much
> better if it is approved by the fastcgi developers.
>
> Thanks for your time,
> /prakash
>
> On Thu, Oct 28, 2004 at 12:24:29PM -0400, Prakash Kailasa wrote:
> > Hi,
> >
> > We use fastcgi (at my workplace) for a several perl applications, both
> > static and dynamic. Recently, we added mod_gzip to the mix.
> >
> > The compression works fine in case of dynamically started fastcgi
> > applications, but the output of static fastcgi apps does not go thru
> > the compression stage.
> >
> > After much debugging, I've found that the fixups function in
> > mod_fastcgi.c is setting the value of the handler to
> > FASTCGI_HANDLER_NAME ("fastcgi-script") in case of static
> > applications, replacing the value set by mod_gzip.
> >
> > Here's the relevant part of the code:
> >
> >     if (fcgi_util_fs_get_by_id(r->filename, uid, gid))
> >     {
> >         r->handler = FASTCGI_HANDLER_NAME;
> >         return OK;
> >     }
> >
> > The test above fails for dynamic apps, so there would be no change in
> > the handler (which happened in our case to be mod_gzip_handler) and
> > everything was fine.
> >
> > I looked at the CHANGES file and found this item (under 2.4.0):
> >
> >  *) Eliminate the need for SetHandler or AddHandler with static or
> >     external applications.
> >
> > Not knowing the fastcgi code throughly, I am not sure if this item
> > corresponds to the above code segment. But I am guessing that not
> > having either of these directives would leave the handler unset and
> > the fixups function is fixing this situation.
> >
> > If I change the above test to include an additional check so that the
> > handler is fixed only if it is truly NULL,
> >
> >     if (r->handler == NULL && fcgi_util_fs_get_by_id(r->filename, uid,
gid))
> >
> > gzip compression works in case of static applications as well.
> >
> > My questions: Is this an appropriate fix? Does this break any other
> > situations? If so, what would be the right fix?
> >
> > My environment:
> >     Apache 1.3.28
> >     mod_fastcgi 2.4.0
> >     mod_gzip 1.3.26.1a
> >     Linux 2.4.25
> >
> > I am attaching the patch, if that is of any help.
> >
> > Thanks for your time,
> > /prakash
> >
> > -- 
> > |All language designers are arrogant. Goes with the territory...       |
> > |        -- Larry Wall                                                 |
>
> > --- mod_fastcgi.c.orig 2002-12-22 22:19:14.000000000 -0500
> > +++ mod_fastcgi.c 2004-10-04 16:36:30.000000000 -0400
> > @@ -2812,7 +2812,7 @@
> >
> >      get_request_identity(r, &uid, &gid);
> >
> > -    if (fcgi_util_fs_get_by_id(r->filename, uid, gid))
> > +    if (r->handler == NULL && fcgi_util_fs_get_by_id(r->filename, uid,
gid))
> >      {
> >          r->handler = FASTCGI_HANDLER_NAME;
> >          return OK;
>
> > ___________________________________
> > fastcgi-developers mailing list
> > http://fastcgi.com/fastcgi-developers/
>
>
> -- 
> |Mollison's Bureaucracy Hypothesis:                                    |
> |        If an idea can survive a bureaucratic review and be           |
> |        implemented it wasn't worth doing.                            |
>


----------------------------------------------------------------------------
----


___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/
___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/