The fastcgi handler is ready!

Hi guys!

   Finally, I've managed to fix all the FastCGI issues I found a couple
   of weeks ago.

   Now, it successfully passes all the QA tests using the FastCGI
   handler instead of the phpcgi one for all the PHP related tests.

   I have uploaded a new beta (which I'm currently dogfooding):

      http://www.alobbs.com/tmp/cherokee-0.4.31b10.tar.gz

   If everything goes okay with this beta I will release a new version
   in the next days.  If you have the chance, please, test it out 

--

-- 
Greetings, alo.
http://www.alobbs.com

New project: proxy-cache handler

	Hi there :)

    I'm glad to announce a new sub-project inside the Cherokee project.
    We are about to start working on a proxy-cache handler which will
follow the save architectural bases and philosophy as the rest of
the project: it will be modular, extensible with plug-ins and we
will try to make it as faster as possible.

    The initial idea is to support the following features:

       * Plug-able Caches
       * Writing policy modules
       * Replacement policy cache modules
       * Filtering modules

    It will be a handler for the web server, exactly like the file,
dirlist or fastcgi ones. This will allow to integrate the proxy
functionality with all the previous infrastructure built explicitly
for the web server like encoders, loggers or validators.

    The initial work team will be composed by:

    - Cesar Fernandez: be patient: I'm the newbie one :)

    - Rodrigo Fernandez-Vizarra: that sexy guy you all girls are 
dreaming about... and also wrote Cherokee's Solaris 10 event port 
support and fixed kqueue() as well ;)

    - Alvaro Lopez Ortega (Aka: Alo): who the heck is this guy? 

Re: New project: proxy-cache handler

César Fernández Gago wrote:
> 
> 
>     Hi there :)
> 
>    I'm glad to announce a new sub-project inside the Cherokee project.
>    We are about to start working on a proxy-cache handler which will
> follow the save architectural bases and philosophy as the rest of
> the project: it will be modular, extensible with plug-ins and we
> will try to make it as faster as possible.

err, um, err, having been burned by embedded proxies 
*coff*apachesucks*coff*, I am quite nervous about this feature.  I'm 
using pound because it fails safe unlike *coff* and since it lets me 
sleep at night, I suggest maybe integrating/supporting pound features 
would be a good thing for cherokee.  good solid load balancing proxy 
with a long history of doing things right playing nice with good solid 
web server.  what's not to like?

*coff*fookenpapacheproxy*coff*

---eric

Re: New project: proxy-cache handler

Alvaro Lopez Ortega wrote:
>   I've been working with Rodrigo and Cesar on this idea for a while.
>   I mean, not real working, but brain-storming and discussing. We've
>   filled out a lot of blackboards in order to find the best approach.
>   The conclusion was that Cherokee is flexible enough to accept that
>   sort of handler, and I have to say that I do believe it is really to
>   run the proxy handler.

no doubt.  I will admit that the pluging arch is still a bit unclear to 
me but when it becomes important enough, I'll figure it out.

>   The idea to build it exactly as Cherokee is built. It will be up to
>   you whether you want to cache the content or not, what type and
>   properties it has and so on.
> 
>   I think the proxy-cache handler good idea, and definitely something
>   useful for the project.  For example, Cherokee should support to be
>   on front of a bunch of IIS servers to serve static content and pass
>   the ASP requests to them.
> 
>   If we aren't missing something important, the result will be,
>   hopefully, pretty good 

indeed.  don't forget to deny proxying to port 25 even if the user asks 
for it whether they intended to or not.  also, it would be nice if you 
followed the pound mode of adding the real request source IP to the http 
request: http://www.apsis.ch/pound/

REQUEST LOGGING

Re: New project: proxy-cache handler

Eric S. Johansson wrote:

 >> I'm glad to announce a new sub-project inside the Cherokee project.
 >> We are about to start working on a proxy-cache handler which will
 >> follow the save architectural bases and philosophy as the rest of
 >> the project: it will be modular, extensible with plug-ins and we
 >> will try to make it as faster as possible.
 >
 > err, um, err, having been burned by embedded proxies
 > *coff*apachesucks*coff*, I am quite nervous about this feature.

   I've been working with Rodrigo and Cesar on this idea for a while.
   I mean, not real working, but brain-storming and discussing. We've
   filled out a lot of blackboards in order to find the best approach.
   The conclusion was that Cherokee is flexible enough to accept that
   sort of handler, and I have to say that I do believe it is really to
   run the proxy handler.

 > I'm using pound because it fails safe unlike *coff* and since it
 > lets me sleep at night, I suggest maybe integrating/supporting pound
 > features would be a good thing for cherokee.  good solid load
 > balancing proxy with a long history of doing things right playing
 > nice with good solid web server.  what's not to like?

   The idea to build it exactly as Cherokee is built. It will be up to
   you whether you want to cache the content or not, what type and
   properties it has and so on.

   I think the proxy-cache handler good idea, and definitely something
   useful for the project.  For example, Cherokee should support to be

Re: The fastcgi handler is ready!

On Wed, 01 Mar 2006 22:08:02 +0000
Alvaro Lopez Ortega <alvaro <at> gnu.org> wrote:

>    Finally, I've managed to fix all the FastCGI issues I found a couple
>    of weeks ago.
> 
>    Now, it successfully passes all the QA tests using the FastCGI
>    handler instead of the phpcgi one for all the PHP related tests.
> 
>    I have uploaded a new beta (which I'm currently dogfooding):
> 
>       http://www.alobbs.com/tmp/cherokee-0.4.31b10.tar.gz
> 
>    If everything goes okay with this beta I will release a new version
>    in the next days.  If you have the chance, please, test it out 

  But Trac/FastCGI still doesn't work =) :

$ sudo /usr/sbin/cherokee 

Cherokee Web Server 0.4.31b10: Listening on port 8081, TLS disabled
 IPv6 disable, using epoll, 16384 fds limit, single thread

...
(request http://localhost:8081/projects/ in Firefox)
...

00000000 5374 6174 7573 3a20 3230 300d 0a
fcgi_manager.c:306: Parsing error: unknown version

Re: New project: proxy-cache handler

Eric S. Johansson wrote:

 >>   The idea to build it exactly as Cherokee is built. It will be up
 >>   to you whether you want to cache the content or not, what type
 >>   and properties it has and so on.
 >>
 >>   I think the proxy-cache handler good idea, and definitely something
 >>   useful for the project.  For example, Cherokee should support to be
 >>   on front of a bunch of IIS servers to serve static content and pass
 >>   the ASP requests to them.
 >>
 >>   If we aren't missing something important, the result will be,
 >>   hopefully, pretty good 
 >
 > indeed.  don't forget to deny proxying to port 25 even if the user
 > asks for it whether they intended to or not.  also, it would be nice
 > if you followed the pound mode of adding the real request source IP
 > to the http request: http://www.apsis.ch/pound/

   Yeah, I guess we'll be better citizens if we forbid to use CONNECT
   to the port 25. '

 > REQUEST LOGGING
 >
 > As a general rule, Pound passes all headers as they arrive from the
 > client browser to the back-end server(s). There are two exceptions to
 > this rule: Pound may add information about the SSL client certificate
 > (as described below), and it will add an X-Forwarded-For header. The
 > general format is:
 >

Cherokee + .htaccess

Hi

 Will cherokee support per user .htaccess files some time in the future?
I would love to use it, but without per-user rewrite rules it's unusable
on webhostingplattform IMHO.

My second question: Will there be something like mod_php for cherokee?
(php interpretation without cgi)

greetings
fabian zeindl

--

-- 
I prefer signed/encrypted Mail:
Fingerprint: E654 8A99 94C2 FC96 7DFD  00E4 8599 0FF9 F14C 7BB9

_______________________________________________
Cherokee mailing list
Cherokee <at> www.0x50.org
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee

Re: Cherokee + .htaccess

Hi Fabian,

 >  Will cherokee support per user .htaccess files some time in the
 > future?  I would love to use it, but without per-user rewrite rules
 > it's unusable on webhostingplattform IMHO.

   Currently it doesn't support anything like the Apache's .htaccess.
   In fact, we haven't done any kind of work in that direction.

   However, I have some plans to make a bunch of changes in the
   configuration system, and.. why not? we may try to make your
   proposal fit into those changes.

   Lets *imagine* something like this:

=====
UserDir public_html {
   Allow UserConf
   Directory /cgi-bin {
     DocumentRoot /usr/lib/cgi-bin/
   }
}
=====

   So, if "UserConf" is allowed, the server could look for some kind of
   local configuration file..   would that be enough?

 > My second question: Will there be something like mod_php for
 > cherokee?  (php interpretation without cgi)

Re: Cherokee + .htaccess

Alvaro Lopez Ortega wrote:
> Hi Fabian,
> 
>>  Will cherokee support per user .htaccess files some time in the
>> future?  I would love to use it, but without per-user rewrite rules
>> it's unusable on webhostingplattform IMHO.
> 
>   Currently it doesn't support anything like the Apache's .htaccess.
>   In fact, we haven't done any kind of work in that direction.
> 
>   However, I have some plans to make a bunch of changes in the
>   configuration system, and.. why not? we may try to make your
>   proposal fit into those changes.
> 
>   Lets *imagine* something like this:
> 
> =====
> UserDir public_html {
>   Allow UserConf
>   Directory /cgi-bin {
>     DocumentRoot /usr/lib/cgi-bin/
>   }
> }
> =====
> 
>   So, if "UserConf" is allowed, the server could look for some kind of
>   local configuration file..   would that be enough?

Yes, I think that would be fine. All I need is the possibility for users
to rewrite accesses to their pages, and I think that could be done like