httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sameer <>
Subject Re: Hello.. and why stick with NCSA config format?
Date Thu, 09 Jan 1997 18:08:00 GMT
(Ben's patch is actually US legal with SSLeay if you link SSLeay with
RSAREF. It doesn't do SSLv3, but that's just because SSLeay
doesn't.. which will change shortly, I should know. =) )

	wtf respect to the API stuff... I am all for a few additional
handlers going in soon, which rings me back to the 1.3 heresy. I am
*completely* against delaying 2.0 development, but I think a 1.3 with
a better API should come out within the next 6 months, well before 2.0
can come out.

	I think the IO handlers are best left for 2.0, actually,
because threading allows for protocol layering, but there might be a
use for it sooner.

> What I wanted to talk to you about though was the possibility of adding a new
> hook for IO Handlers into the module system of apache.  Specificly, 4
> callbacks:
>   initIOHandler()  - called in new_connection()  (no action taken if a module
> doesn't override IO)
>   IOwrite()          - called anywhere write is called.  Responds the same and
> takes
>                           exactly the same parameters as write but calls a
> module based
>                           handler instead.  There would need to be a hook back
> to the
>                           default handler as well if we want to keep this
> thing portable.
>                           (i.e. after SSL or SET or whatever encryption, the
> module calls the
>                            default io handler e.g. write(), but through an
> abstracted interface)
>   IOread()           - Same as IO write except for read()... ;)
>   IOClose()         - This would be called in place of close() on sockets
> anywhere in
>                            Apache.  And would hook back to the IO handler
> module's shutdown
>                            prior to closing the socket.
> Ok..  this is all fine and good, I'm sure you will agree.. its exactly what
> ben did basicly
> except more portable and abstracted and could be included in every version of
> Apache
> weather it supports any encryption or not.  This would also make it absolutely
> simple
> for ben and I to interface our code.. no more patches (and thus, its
> module, and not a separate version of apache.)  I was talking to brian about
> the fact that everyone wants to keep apache as apache for legal (trademark)
> reasons
> so we could drop names like Apache-SSL or Apache-US or whatever and just say,
> oh this is the international SSL module, and this is the US SSL module.. or
> this
> is the SET module...  or whatever other form of IO handling someone wants to
> come up with.
> As far as the configuration goes, does anyone here know of a good reason to
> stick
> with NCSA's config format?  I mean, if there were major changes in the core
> internal
> configuration of some sort would you be opposed to change the config file
> formats
> to be easier to deal with and be more like what the server is actualy doing?
> I'm just mainly wondering...  I've been using Apache for going on 2 years now
> and
> adding my own patches and whatnot all this time (unfortunately in my previous
> job as admin of an internet provider I never had time to finalize any of my
> patches
> for general use.. they were all very specific and down-and-dirty for what we
> needed).
> One thing I think desperately needs to be done is to get rid of the listener
> config,
> and even the main host config.. then just have the global configuration stuff
> for the server itself in httpd.conf with directives of this sort:
> HostConfig conf/myfirsthost
> HostConfig conf/mysecondhost
> <Host mythirdhost>
> Port 80 Clear
> Port 443 SSL-Internation
> Port 444 SSL-US
> Port 446 SET
> ...  # all the rest of the normal stuff you'd have for a virtual host
> </Host>
> HostConfig would let you read in more hosts from separate files (the files
> would be
> just like whatever is inside a <Host> block but without the <Host> tags
> themselves)..
> This would greatly simplify things for people like myself who administer
> commercial
> hosting services.
> Second, Port could be made cumulative.. with a port table of some sort in the
> configuration.. the second option would be a IO handler name.. as registered
> by the IO handler module at load time.  The table should probably include port
> number, handler, default handler port, and default protocol method (i.e. http,
> https)
> We could assume Clear if its left off.
> Ok, now you may be saying "Who is this dolt and why is he trying to tell us
> what
> we should do"... well, I'm "jus zis guy, ya know?"  (sorry, random
> HitchHiker's Guide
> to the Galaxy quote disease).. actualy, these are just suggestions from
> someone
> who's been using Apache and NSCA both for years and who would absolutely
> LOVE to see Apache stay the number 1 web server and eventualy be the fastest
> and best web server available.. and still free, highly extensible and
> customizable.
> Anyways, the only reason I'd say change from <Virtualhost> to <Host> is
> because
> of the gross change in the way configuration is handled.. it would help to
> avoid
> confusion.  Of course we will have to tell the people at microsoft to alter
> their
> Front Page extensions for Apache.. ;)  But even just providing for external
> definitions of virtual hosts would require that.
> I'm not saying you should do any of this.. I just think it would be handy for
> a lot
> of us.  Since you are about to do a major re-write of the core anyways, its
> best
> done now.  I'm open to discussion about any of this.. please give me any
> reason
> you have for why this stuff should or shouldn't be done.  
> Again, don't get mad.. I don't think what I'm saying is necessarily the best
> way or even at all close.. I just am wondering your opinion on it and if you
> like
> it I would be very pleased if something similar showed up in future versions
> of Apache..
> Thanks a bunch.
> Jason Clary

Sameer Parekh					Voice:   510-986-8770
President					FAX:     510-986-8777
C2Net 		    C2Net is having a party:

View raw message