Patch 62

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

I'm at WWW4, so I really don't have time to do a full patch evaluation.
Accordingly, I have no opinion on the escape_html patch for inclusion in
the 1.1 tree.  However, I vote -1 on it for 1.0.x --- its effect is to
reintroduce code which was commented out of the original NCSA directory
indexing because it caused problems.  I'm not sure I know what those
problems are, but given the amount of time we've had to look it over and
test it (i.e., none), it seems clear that the only way we're going to
find out is the hard way, and that is not the sort of thing I want in
a 1.0.x release.  (It seems clear that in at least one reasonable person's
judgment in the past, Rob McCool's, these problems that it causes, whatever
they are, are worse than the problems it cures).

To put it another way, I think that further 1.0.x releases should be for
*critical* bugfixes only, and this simply does not meed my threshold for
criticality.  If you don't like it, get started on 1.1.

rst

Re: Patch 62

[Rob McCool <ro...@netscape.com>]

Robert S. Thau wrote:
> Accordingly, I have no opinion on the escape_html patch for inclusion
> in the 1.1 tree.  However, I vote -1 on it for 1.0.x --- its effect is
> to reintroduce code which was commented out of the original NCSA
> directory indexing because it caused problems.  I'm not sure I know
> what those problems are, but given the amount of time we've had to
> look it over and test it (i.e., none), it seems clear that the only
> way we're going to find out is the hard way, and that is not the sort
> of thing I want in a 1.0.x release.  (It seems clear that in at least
> one reasonable person's judgment in the past, Rob McCool's, these
> problems that it causes, whatever they are, are worse than the
> problems it cures).

That assumes that the reason was reasonable... 

If I'm remembering my ancient history correctly, you're talking about
the code that went through and replaced > with > and & with &,
the reason it's commented out is really stupid. The code that calls that
uses the length of the string to decide where to terminate long file
names. So when &> got turned into &> the code would think that
the file name was 9 characters long instead of 2. So things wouldn't
line up anymore and filenames would be terminated prematurely. I always
meant to go back and do that properly, but never got to it (it wasn't
exactly a high priority item).

--
Rob McCool, robm@netscape.com
Stunt Programmer, Netscape Communications Corporation
It was working ten minutes ago, I swear...
<a href="http://home.netscape.com/people/robm/">A must see.</a>