rst's votes on the current patches-for-0.2

["Robert S. Thau" <rs...@ai.mit.edu>]

B18_redirect: +1
   Tried it, it works, it's overdue.  ;-).
   (BTW, Eric, this fixes the three-second-pause braindeath).

B27_XBITHACK_scripts.txt: +1

B39_CRLF...: 0
   David says this is as yet half baked; RobH. says it represents a
   step in the right direction regardless.  IMHO, they're both right.
   Paul, is this the sort of problem that the FreeBSD group is
   finessing with CVS?  If so, we may need it quicker than I thought
   ;-).  But in the meantime, I'll just stay out of it.

B40_trailing_slash: +1
   I take bug reports in my code seriously, but this seems to be
   working for a *whole* lot of people, and I can't duplicate the
   reported problem here.

B41_NCSA_security: +1
   Overdue.  Enough said.

E25_custom_error_responses: -1, until we've looked over the NCSA code
   and decided what to do about it.

   NCSA 1.4 has what looks like a more general version of this; it
   uses process_get to send the custom errors.  This has more
   overhead, but should let you do things like use a CGI script to
   construct custom messages on the fly.  My only concern with that
   would be treatment of errors in the "GETs" of the error files, but
   that is a solvable problem.  (If you're already trying to send a
   custom error message, further custom errors should be suppressed;
   this may be happening already (I haven't checked) but a quick
   once-over doesn't show code for it).

   However, if there's some good reason why the NCSA approach is the
   wrong thing to do, I could be persuaded to change this vote.

E37_load_cutoff: 0
   Come on, Rob --- you blackball an flock()ing nameserver cache for
   portability, and then you give us *this* ;-)?  (Not that I'm
   defending the use of flock() overmuch --- Dave may actually have a
   better approach to P12).

E38-alias_malloc_3: +1
   Good idea, tried it, it works.

P12-nscache-3: -0.5 [read that as a -1 which is HIGHLY likely to be
   reversed next week, but given the heat of discussion, I'm not sure
   it's the right thing to commit to a particular approach just yet].

   I like the general approach taken in this code, but I'd prefer to
   see a little more work on it.  (FWIW, the parameter choices
   wouldn't work well for me --- a 100-entry cache is way low, giving
   a ~70% hit rate, as opposed for the ~90% I get with 250).

and th'th'th'th'th'th'th'th'th'that's all folks!

rst