httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: Shambhala Modules Musings [network wizard advice sought at bottom]
Date Mon, 03 Jul 1995 11:34:33 GMT
> Ah, but one of my not-so-hidden agendas here is that I'm looking
> towards multithreading the thing (I'm not sure how it's possible to
> write a decent HTTP-NG server which *isn't* multithreaded, unless you
> turn the entire thing into a gigantic collage of state machines, which
> generally results in an unreadable mess).  That doesn't give you the
> option of tossing the entire address space any time a timeout on one
> of the twenty-odd requests it might be serving gets aborted; you need
> to find another way out of it.

Sounds good. Will a threads based system be portable ?, I'm thinking
of problems like Rob McCool pointed out, were a Solaris (I beleive)
library was leaking, and hence forced the MaxRequestPerChild approach.
Perhaps these issues are unrelatated, I know nothing about threads.

> On the other subject... this syntax:
>    AddType "text/html; charset=ISO-8859" html
> actually works, though you wouldn't know it because I forgot to make
> the ARENA_BUG_WORKAROUND properly conditional.  (Sigh...).  Actually,
> any "word" in a config file can be delimited by single or double
> quotes, in addition to blanks; backslash escapes should also work more
> or less as you expect.

nice... but see next comment.

>    Also, if AddType is meant to be equivalent to entries in mime.types, then
>    it needs to accept multiple file extensions
>    AddType image/gif; gif GIF
>    AddType test/html; html htm
> Easy enough; change the TAKE2 in the mod_mime command table to
> ITERATE2, and change the wording of the error message in the table to
> indicate that the extensions can be plural.

please read these points not as "how do I make the current version
of Shambhala do this", but as "a future version probably needs to do this".

At this stage I'm not interested in fine tuning the configuration, it
either works as I expect or it doesn't.. I can wait for updates.

>    Now might also be a good time to encourage the omission of "." from
>    the extensions... it'll mean a slight divergence from what's allowed
>    in 1.3, but the "." isn't supposed to be there... a well worded warning
>    message would probably suffice.
> I'm not sure how you conclude what is or isn't "supposed" to exist in
> these cases, but the '.'s *do* exist in a lot of places, and the cost
> of skipping over them if they are present is essentially zero.

The NCSA documentation. I think Randy looked it up at some point.

True, they don't cause any real problems, other than confusing people
as to what the config file options actually do. By having a warning, it
should encourage existing users to clean up their conf files, that way
they don't end up advising others of the incorrect syntax.. which is what
has happened so far with AddType.

Maybe someone will want to have a type which ends   ..html    :-)

>    A bug fix..
>      http_main.c    clen=sizeof(sa_client);
> 			   |
> 			   v
> 		    clen=sizeof(struct sockaddr_in)
> Hmmm... sizeof(*sa_client) is probably what's meant here, though the
> existing code is fairly clearly wrong...

same thing I guess; *sa_client would make it more portable should
sockaddr_in ever be changed for some weird platform.


View raw message