You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2001/10/17 18:34:00 UTC

[PROPOSAL] ApacheHTTPD -- WIN32

Greetings,

I'll try to change the approach a little bit :)
This month I've posted a couple of add-ons, patches, proposals, etc... and
for most of them didn't get the (even a 'f**k off')answer.
Well, I don't mind but it would be nice to get some feedback.

ApacheHTTPD.

The ApacheHTTPD is GUI (WinMain) application used instead of apache.exe in
some conditions.
One of the obvious one is WIN9x and the other is NT in non-service mode.
Basically we are needing main() (console) only on WINNT+ platforms when
running as service.
In all other cases the GUI would be much better solution.
I'm thinking to wrap the stdout/stderr and stdin, put some icon in the try
with the popup window (console simulation).
My proposal is to add to the main a simple global variable that will signal
if the apache is running as console or GUI application, of course calls to
CreateProcess will be overridden by that variable.
IMO that will Win9xConHook made unnecessary, and the NT+ platforms will
benefit from the concept.
I mean by that if the apache is run as service, it could call the
ApacheHTTPD as 'redirector' for I/O. That way we could override the SSL
password entry for example pushing some dialog box, or see the current
server status.

Does community has some comments on that?

MT.


Re: [PROPOSAL] ApacheHTTPD -- WIN32

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Mladen Turk" <mt...@mappingsoft.com>
Sent: Wednesday, October 17, 2001 11:34 AM

> Greetings,
> 
> I'll try to change the approach a little bit :)
> This month I've posted a couple of add-ons, patches, proposals, etc... and
> for most of them didn't get the (even a 'f**k off')answer.
> Well, I don't mind but it would be nice to get some feedback.

Mladen;

  Only a few of us are attacking patches, and writing our own.  Can I offer some
observations and constructive criticizm that might help you (and other current
and potential contributors) out with navigating dev@httpd?  

Observations;

  1. Even regulars don't get feedback till the break things.  This isn't
     a good thing, it just reflects the state-of-the-state in dev@httpd.
     Frankly, it p!ss*s me off too.  I try to follow and comment on threads
     that relate to what interests me, but my mental bandwidth sometimes 
     isn't sufficient to follow all the lists I track.

  2. Only a handful of us seem remotely interested in htdbm/dbmmangage (not
     the first time.)  Probably makes sense to drop mod_auth_db/dbm unless 
     some more developers are willing to comment.  Same scenario as mod_proxy,
     it was initially pulled from 2.0, mostly because nobody listened to even 
     the patches submitted to bugs or dev@httpd, never mind bug reports.

  3. Your idea of positing a suggestion here first is absolutely the right
     way to go, to avoid later frustration!!!  I have not forgotten the few
     we've discussed on list, they are in one of my trees.

Constructive (?) Criticizm on htpasswd;

  1. Your patch to htpasswd seems way overboard.  It makes it impossible to
     follow the growth of this utility from Apache 1.3 to 2.0, and that
     makes a mess for someone coming in later, trying to divine why "It worked
     in 1.3, why is 2.0 broken?".  Couldn't this be done less dramatically
     with some precision, to follow the original code?  [I've been guilty of
     this and had dozens of my early patches rejected, for exactly this reason.]

  2. I'm not clear why it was necessary to wipe out significant comments 
     about never suexec'ing it or adding your credit tag (note many of us have 
     contributed mega-amounts of code, we don't do so and I intend to embark on
     trying to pull out inappropriate credits, paying due attention to copyright
     and confirming credit was given in CHANGES and CVS.)  

     Companies contribute between a bit and oogles of developer $$$s to keep 
     moving Apache forward, but patches are credited to developers, not their
     employeers.  In fact, the only acceptable company tagline is your email 
     address, reflecting whatever email account the patch is mailed-from.

     CHANGES and CVS logs provide the credit where credit is due, please advise
     if I've ever shortchanged you due credit for your patches.  Eventually,
     reliable contributors are granted CVS access, then potentially Project
     Management membership, and finally they may be nomiated for ASF membership.
     These aren't handed out trivially, see dev.apache.org about the process.

  3. Your patches do need review [I needed to bandaid the date calculation in
     your rotatelogs patch before committing.]  That takes some developer's
     time to do, and I've had issues finding enough time for a life, never mind
     all the very good patches to this list lately.

Those are really my only objections to committing your htpasswd changes as
posted to the list, it needs to be a cleaner patch, comments should be appropriate,
and I need free time to test.

Take John Sterling's patch yesterday morning.  One line, with a _very_ clear
explanation of what and why.  Committed in 10 minutes.  Take Aaron's patches,
very large, difficult to understand, but necessary to commit as a unit.  Took
weeks to get those reviewed, critiqued and committed.  Don't get downhearted
if big patches or new code takes time to thoroughly review.  mod_auth_ldap was
just made into a subproject for just that reason, many on this list feel there
hasn't been sufficient review to put that module into the main tree.

It's a struggle for contributors and committers to keep up with each other and
match each other's needs to work efficiently.  I'm sorry if you've been a bit
frustrated in your efforts, I hope others pick up on your patches and recognize
some aren't just "that win32 thing."

Thanks for your contributions thus far!!!

Bill



Re: [PROPOSAL] ApacheHTTPD -- WIN32

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "jlwpc1" <jl...@mail.earthlink.net>
Sent: Thursday, October 18, 2001 2:01 PM

.From: "William A. Rowe, Jr." <wr...@covalent.net>

>   3. 9x is gone.  

>We will finally be able
>      to tell users to got to XP (at least the home edition) - same cost as 
>      the old 9x, and at _LEAST_ be working on the NT archtecture.  Throwing 
>      substantial effort at 9x is an utterly bogus waste of time, as it is
>      not an adaquate server architecture (as poor, unexpecting embedded-aol 
>      "Browser" users discover.)
> 

.When will "ASF people" announce
.no Win9x in Apache 2.0 to the rest
.of the world?

Existing 9x functionality will be supported for some time to come.

The Q on the table is extending that ... and that's what I've 
suggested be curtailed.  There are a number of constructs that
require the NT kernel.  There maybe some backwards-broken thunks,
but nothing new and 'inventive'.

IOW... expect about the same from 1.3 to 2.0 on 9x.  Expect much
bigger changed from 1.3 to 2.0 for NT.

Bill



Re: [PROPOSAL] ApacheHTTPD -- WIN32

Posted by jlwpc1 <jl...@mail.earthlink.net>.
From: "William A. Rowe, Jr." <wr...@covalent.net>

>   3. 9x is gone.  

>We will finally be able
>      to tell users to got to XP (at least the home edition) - same cost as 
>      the old 9x, and at _LEAST_ be working on the NT archtecture.  Throwing 
>      substantial effort at 9x is an utterly bogus waste of time, as it is
>      not an adaquate server architecture (as poor, unexpecting embedded-aol 
>      "Browser" users discover.)
> 

When will "ASF people" announce
no Win9x in Apache 2.0 to the rest
of the world?

Seen the newest Netcraft report
concerning Windows having the
largest count of servers on the 
Internet?

Might be good times ahead for
you Windows programmers!

JLW










Re: [PROPOSAL] ApacheHTTPD -- WIN32

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Thursday, October 18, 2001 1:28 PM


> From: "Mladen Turk" <mt...@mappingsoft.com>
> Sent: Thursday, October 18, 2001 12:28 PM
> 
> > 
> > Didn't found something like the thing I had in my mind. Perhaps I was
> > unclear enough.

look for messages from Sep-Dec '99

Jan Just Keijser <KE...@logica.com>



Re: [PROPOSAL] ApacheHTTPD -- WIN32

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Mladen Turk" <mt...@mappingsoft.com>
Sent: Thursday, October 18, 2001 12:28 PM


> Sorry if I'm pain in the ass, 

Not

> but...

> > From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> > Sent: Wednesday, October 17, 2001 9:13 PM
> 
> > > IMO that will Win9xConHook made unnecessary, and the NT+ platforms will
> > > benefit from the concept.
> >
> > Win9xConHook is a _hack_ for an unsupported platform.  I'd sooner dump
> > 9x than attack the problem in this manner.  We have fundemental issues
> > when we 'run-as-service' in 9x that Win9xConHook neatly wraps.  If it's
> > broke, we aught to fix it.  But we've critically broken CGI's many times
> > before trying to get this right.  What we've got, works, well.
> 
> I understand this, after all we are building a server, but don't you think
> that the time has come to make a decision to either drop the WIN9x from
> httpd, or still wasting like you said 200+ hours trying to solve unsolvable.

Agreed, we aren't dumping it, I just don't care to reinvent the wheel again,
or help to maintain such a reinvention.  That said...

> > > I mean by that if the apache is run as service, it could call the
> > > ApacheHTTPD as 'redirector' for I/O. That way we could override the SSL
> > > password entry for example pushing some dialog box, or see the current
> > > server status.
> > >
> > Please review Oct 99 forward for new-httpd and take a look at the history,
> > so at least we aren't wasting time repeating prior discussion.
> 
> Didn't found something like the thing I had in my mind. Perhaps I was
> unclear enough.

Search for messages from J J Ke

> What I was thinking is to put some sort of a hooks in it that will allow one
> to get into the 'run' process itself. I'm not talking here about the modules
> dealing with the MIME or stuffs like that but rather the status of the
> apache itself. One of the simplest applications could be the ApacheHTTPD

Ok.  Forgetting (for the moment) stdin/stdout (which are goodness, as is)...
you want to be able to query to the process.

First, forget about trying to 'interact' with console apache entirely.  I'm
very temped to drop that support once the Service on Win9x is sufficiently
reliable.  Well, 'drop' is a harsh word, but really the console is just for
things like apache -t, testbench, etc.  It isn't ment to be the launch point
it serves as today for many users.

SO... I strongly suggest you look at extending that global hook to add a 
'query' function to Apache, that can do precisely what the WinNT SCM provides 
for us, only under 9x.  That way, we can ask, and have answered, all the usual 
questions (starting?  running?  dying?  not responding?)

Second, we stop and revisit the scoreboard.  Anything beyond those basic Q's
should be answered from shared memory.  Acceptable?  It means I need to jump
on your shmem offering first ;)

> I was inspired to the concept looking at the rotatelogs util. We are
> communicating to that app using pipes and stuffs instead of using something
> like simple hook inside the apache that will intercept all the log
> directives, and if someone wants even send an email to the admin if there is
> more than a 100 requests for a particular page in a minute. Of course one
> could build a rotatelogs clone that deals with such a scenario, but imagine
> the chain of such utilities and the benefit.

I don't see how this has to do with console v.s. win app?  Yes, tee is a wonderful
thing, more folks should use it.

> The ApacheHTTPD proposal IMO was the lead-in thought in the way that the app
> itself would behave in the following way:
> 
> 4. registers for the status signal (quit, restart, whatever...)

That's what I suggest we do with Win9xConHook, answer one more WM_USER message
(registered with the RegisterMessage api) of "What are you up to?"

So you don't need to deal with replacing what works (stdio), but focus on
"what questions can't we get answers to, today?".  Answering a WM_ message with
'hey, I'm alive and running!', getting the pid and grabbing its scoreboard would
solve the 80/20 very quickly.

We aren't replacing stdio in Apache 2.0 :-)

Bill



RE: [PROPOSAL] ApacheHTTPD -- WIN32

Posted by Mladen Turk <mt...@mappingsoft.com>.
Sorry if I'm pain in the ass, but...

> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> Sent: Wednesday, October 17, 2001 9:13 PM
> To: dev@httpd.apache.org
> Subject: Re: [PROPOSAL] ApacheHTTPD -- WIN32

> > IMO that will Win9xConHook made unnecessary, and the NT+ platforms will
> > benefit from the concept.
>
> Win9xConHook is a _hack_ for an unsupported platform.  I'd sooner dump
> 9x than attack the problem in this manner.  We have fundemental issues
> when we 'run-as-service' in 9x that Win9xConHook neatly wraps.  If it's
> broke, we aught to fix it.  But we've critically broken CGI's many times
> before trying to get this right.  What we've got, works, well.

I understand this, after all we are building a server, but don't you think
that the time has come to make a decision to either drop the WIN9x from
httpd, or still wasting like you said 200+ hours trying to solve unsolvable.

> > I mean by that if the apache is run as service, it could call the
> > ApacheHTTPD as 'redirector' for I/O. That way we could override the SSL
> > password entry for example pushing some dialog box, or see the current
> > server status.
> >
> Please review Oct 99 forward for new-httpd and take a look at the history,
> so at least we aren't wasting time repeating prior discussion.

Didn't found something like the thing I had in my mind. Perhaps I was
unclear enough.

For example right now we are having a app that:

1. start
2. print some status or whatever to stdout
3. eventually wait for same user feedback
4. registers for the status signal (quit, restart, whatever...)
5. run
6. print the current status
7. eventually wait for same user feedback
8. do 5 forever

That is more or less the standard application we know.
What I was thinking is to put some sort of a hooks in it that will allow one
to get into the 'run' process itself. I'm not talking here about the modules
dealing with the MIME or stuffs like that but rather the status of the
apache itself. One of the simplest applications could be the ApacheHTTPD
(another exe or a lib perhaps that checks the OS and command line), simply
redirecting I/O to the window instead the console. The reason for that is
IMO that if someone runs the apache in the non-service mode he is obviously
testing something. Don't know how the pipe stuff can (if can at all) be
resolved in that case, but the stdio can (in the same way as the
ApacheMonitor).

I was inspired to the concept looking at the rotatelogs util. We are
communicating to that app using pipes and stuffs instead of using something
like simple hook inside the apache that will intercept all the log
directives, and if someone wants even send an email to the admin if there is
more than a 100 requests for a particular page in a minute. Of course one
could build a rotatelogs clone that deals with such a scenario, but imagine
the chain of such utilities and the benefit.

The ApacheHTTPD proposal IMO was the lead-in thought in the way that the app
itself would behave in the following way:

1. start
1.1. Load all the app hooks
1.2. If we have a start hook run that, else use the old way
2. print the status using start hook's print function
3. eventually wait for some user feedback using startup hook's input
function
4. registers for the status signal (quit, restart, whatever...)
5. run if some hook doesn't object
6. print the current status using some found hook's print function
7. eventually wait for same user feedback using some found hook's input
function
8. do 5 forever

Doing that (at least in the simplest way) wouldn't be IMO such a deal.
I'm preferring the incremental software developement approach, so putting
something like hooks for the printf/fprintf(stdio, ...), os version and
command line should be the first things that need to be done.


MT.


Re: [PROPOSAL] ApacheHTTPD -- WIN32

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Mladen Turk" <mt...@mappingsoft.com>
Sent: Wednesday, October 17, 2001 11:34 AM


> ApacheHTTPD.
> 
> The ApacheHTTPD is GUI (WinMain) application used instead of apache.exe in
> some conditions.

Ok, first off, no more model changes on 1.3 period ... this is 2.0 discussion
only (agreed???)


> One of the obvious one is WIN9x and the other is NT in non-service mode.
> Basically we are needing main() (console) only on WINNT+ platforms when
> running as service.

We have some other, underlying issues.

  1. this can break CGI (pipes are a mess under GUI.)

  2. we have yet two more 'model' to support when we barely have the people
     to support the existing models.

  3. it's been proposed, and rejected, before my time.

  4. beat my head against that wall myself, already, and lost.


> In all other cases the GUI would be much better solution.


I fail to see how.  I understand some of your thoughts, and if we weren't
dealing with compatibility issues left and right, and if the GUI did an OK
job with pipes, then I could bend here.  I don't see the benefit.

> I'm thinking to wrap the stdout/stderr and stdin, put some icon in the try
> with the popup window (console simulation).

  1. Keep the tray icon code in one and only one place, ApacheMonitor.
     [That's a -1 - veto on more tray code.]

  2. What's with trying to reinvent console?  Yes - the 9x console is a
     piece of garbage, but this solution feels wrong.  The NT console is
     actually rather effective.  [Not quite a veto here, but close.]

  3. 9x is gone.  ME was stillborn (poor users.)  We will finally be able
     to tell users to got to XP (at least the home edition) - same cost as 
     the old 9x, and at _LEAST_ be working on the NT archtecture.  Throwing 
     substantial effort at 9x is an utterly bogus waste of time, as it is
     not an adaquate server architecture (as poor, unexpecting embedded-aol 
     "Browser" users discover.)


> My proposal is to add to the main a simple global variable that will signal
> if the apache is running as console or GUI application, of course calls to
> CreateProcess will be overridden by that variable.

Ick.  Now we are going in four directions at once.  That's excessive.


> IMO that will Win9xConHook made unnecessary, and the NT+ platforms will
> benefit from the concept.

Win9xConHook is a _hack_ for an unsupported platform.  I'd sooner dump
9x than attack the problem in this manner.  We have fundemental issues
when we 'run-as-service' in 9x that Win9xConHook neatly wraps.  If it's
broke, we aught to fix it.  But we've critically broken CGI's many times
before trying to get this right.  What we've got, works, well.


> I mean by that if the apache is run as service, it could call the
> ApacheHTTPD as 'redirector' for I/O. That way we could override the SSL
> password entry for example pushing some dialog box, or see the current
> server status.
> 
> Does community has some comments on that?

Yes, I'm not wasting another hour on top of the 200+ hours invested in
'fixing' 9x.  I've gone down every dead end already.  Please trust, this
is not an effective solution for httpd.  You mean well, of course ... but
this means the -group- must support the code.  What we've got solves the
80/20 for Win9x (more like 99/1 based on current bug reports) and those 
remaining users could always keep the console or go to cygwin.

Please review Oct 99 forward for new-httpd and take a look at the history,
so at least we aren't wasting time repeating prior discussion.

Bill