httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Shambhala Modules Musings [network wizard advice sought at bottom]
Date Mon, 03 Jul 1995 12:51:27 GMT
   From: Rob Hartill <hartill@ooo.lanl.gov>
   Date: Mon, 3 Jul 95 10:21:43 MDT

   rst writes,
   > The easiest way to fix this is to change the way that timeouts are
   > handled.  Here's one idea --- instead of doing an immediate longjmp(),
   > just put the connection in an "aborted" state where the server will
   > refuse to do any more I/O on it.  (The easiest thing would be to just
   > close the file descriptor).

   It might sound like an easy way out, but 0.7 would have a child
   which hits a timeout/broken connection exit after logging it... It's
   not as elegant as closing everything down and starting again, but
   at least one doesn't have to worry about handling the signals in a
   portable fashion.

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.

   My Unix guru friend says that anything other than a longjump from
   a signal handler is prone to portability problems. If you do the
   longjump, it has to do all the cleaning up.

My counterproposal amounts to having the signal handler just change a
global variable... that's actually *less* than the longjmp().  



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.

   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.

   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.

   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...

rst

Mime
View raw message