Re: Inclusion of mpm-itk into HEAD

On Sun, 17 Jun 2007 21:47:33 +0200 "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > - mpm-itk is in production use at several sites -- for instance, Isn't that also true of metux? > Two main disadvantages should be noted: Thanks for being clear about these up-front. > - setuid() happens

Re: Inclusion of mpm-itk into HEAD

On Mon, Jun 25, 2007 at 02:36:41PM +1000, Graham Dumpleton wrote: > What specific applications are you running that require things to be > run as a distinct user? Are these applications implemented directly in > C as custom Apache modules, or are you writing stuff in other > languages, ie., such as

Re: Inclusion of mpm-itk into HEAD

On 25/06/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Mon, Jun 25, 2007 at 02:36:41PM +1000, Graham Dumpleton wrote: > What specific applications are you running that require things to be > run as a distinct user? Are these applications implemented directly in > C as custom Apache modul

Re: Inclusion of mpm-itk into HEAD

On Mon, Jun 25, 2007 at 08:08:03PM +1000, Graham Dumpleton wrote: > Or you can use PHP under fastcgi. With fastcgi the code would run in a > separate process and you could have any number of processes > corresponding to whatever virtual hosts you have. Because it is a > separate process it can run

Re: Inclusion of mpm-itk into HEAD

On Mon, Jun 25, 2007 at 09:20:45AM +0100, Nick Kew wrote: >> - mpm-itk is in production use at several sites -- for instance, > Isn't that also true of metux? I don't know. Can you point me to any sites? Does Metux even support SSL yet? > That looks like a serious problem to me. > > First there

Re: Inclusion of mpm-itk into HEAD

On 25/06/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Mon, Jun 25, 2007 at 08:08:03PM +1000, Graham Dumpleton wrote: > Or you can use PHP under fastcgi. With fastcgi the code would run in a > separate process and you could have any number of processes > corresponding to whatever virtual

Re: Inclusion of mpm-itk into HEAD

On Mon, Jun 25, 2007 at 08:47:03PM +1000, Graham Dumpleton wrote: >> Yes, it is obviously an alternative, but FastCGI has its own sets of >> quirks, and PHP under CGI too (as far as I know; I'm no PHP user). > Quirks such as? Am not asking to dispute that there aren't any, just > asking out of igno

Re: Inclusion of mpm-itk into HEAD

On 25/06/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Mon, Jun 25, 2007 at 08:47:03PM +1000, Graham Dumpleton wrote: >> Yes, it is obviously an alternative, but FastCGI has its own sets of >> quirks, and PHP under CGI too (as far as I know; I'm no PHP user). > Quirks such as? Am not ask

HTTP BoF at IETF Chicago

A Birds-of-a-Feather (BoF) session has been scheduled for Tuesday, July 24th, 9am US/Central* at the IETF Chicago meeting www3.ietf.org/meetings/69-IETF.html> to discuss proposed work in revising the HTTP specification. The proposed charter

Re: Inclusion of mpm-itk into HEAD

Nick Kew wrote: > "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > >> - setuid() happens after the request has been parsed, which means >> that the server runs as root up until that point. (However, on a >> system with capabilities, ie. Linux 2.6, almost all superuser >> privileges are dropped

Re: Inclusion of mpm-itk into HEAD

On 6/25/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: That said, have you considered a design where there are separate pools of processes per-user, and these would be dispatched after the headers are processed to the appropriate child? The simplest option is to simply reuse the features

Re: Inclusion of mpm-itk into HEAD

Joshua Slive wrote: > On 6/25/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > >> That said, have you considered a design where there are separate pools >> of processes per-user, and these would be dispatched after the headers >> are processed to the appropriate child? > > The simplest optio

Re: Inclusion of mpm-itk into HEAD

On Mon, Jun 25, 2007 at 11:06:11AM -0500, William A. Rowe, Jr. wrote: > That said, have you considered a design where there are separate pools > of processes per-user, and these would be dispatched after the headers > are processed to the appropriate child? Yes, I have considered it briefly, and i

Re: Inclusion of mpm-itk into HEAD

On Jun 25, 2007, at 3:04 AM, Steinar H. Gunderson wrote: So you've introduced something that looks much the same as the traditional "CGI overhead", but applied it to every request instead of just CGI? Every single _connection_, but yes. How would that work for multiple requests on keptalive

Re: svn commit: r550519 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy.html.en docs/manual/mod/mod_proxy.xml modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_balancer.c

Ok, partly playing a bit of devils advocate below :-). On 06/25/2007 04:42 PM, [EMAIL PROTECTED] wrote: > Author: jfclere > Date: Mon Jun 25 07:42:25 2007 > New Revision: 550519 > > URL: http://svn.apache.org/viewvc?view=rev&rev=550519 > Log: > Add sticky_path to solve PR41897. > > Modified: >

Re: Inclusion of mpm-itk into HEAD

On Mon, Jun 25, 2007 at 12:13:31PM -0700, Sander Temme wrote: > How would that work for multiple requests on keptalive connections? > Wouldn't that allow me to send a sequence like > > GET /yourpage HTTP/1.1 > Host: yourhost.com > Connection: Keep-Alive > ... > > which would be dispatched to r