httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: outstanding issues for 1.2 code freeze.
Date Mon, 04 Nov 1996 09:04:08 GMT
Brian Behlendorf wrote:
> 
> 
> There are a number of outstanding patches and bugs and should-do's in the
> current code base.  Do they all have to be released before a beta of 1.2?  In
> my opinion, no, as long as they are fixed by 1.2-final.  We will always find
> another bug or think of another piece of functionality to add, folks; releasing
> code with known and documented but obscure bugs is better than never releasing
> code at all.
> 
> So, please exercise your democratic rights this election season and vote on
> whether you think any or all or none of the following should happen.  If you
> want to focus on one or two patches, please split it out and change the subject
> line.  But I think this marks the state of where things are today.  I've
> crawled through posts to the list and various /incoming directories and
> everything today.
> 
> 
> 
>   Existing Patches:
>   Vote: "+1" is "we should commit this patch to 1.2".
> 
>   1) Adding "+" and "-" functionality to Options, so that subdirectory
>      option-setting can be additive or subtractive.
>      Patch has been posted to the list, has a +1 from someone other
>      than the author, needs another +1 before it can be committed.
>      Patch by Paul Sutton.

+1. You can get badly bitten as it stands.

> 
>   2) RedirectPermanent, RedirectTemp, etc.
>      To implement NCSA-compatible directives for 301 redirection.
>      Path available, needs another +1 before it can be committed.
>      Patch by Paul Sutton.

+1

> 
>   3) Johnh@isi.edu's TCP buffer configuration patch.  I +1 it, and
>      it needs one or two more before I'm comfortable committing it.
>      What do folks think?

Already +1ed.

> 
> 
> 
>   Critical Bugs Which Need Patches before Public Release:
>   Vote: "+1" is "We need to track this down before any public
>         release".
>      
>   1) A kill -HUP after a kill -USR1 results in server death
>      http://www.apache.org/bugdb/full/15

There is a related problem. The old children do not die very rapidly. I've
already explained why this happens but still haven't thought of an elegant
solution.

> 
> 
> 
>   Proposed New Functionality Before Release:
>   Vote: "+1" is "We should implement this before any public
>         release".
> 
>   1) Generalization of BrowserMatch to apply to any header.

+1. Note that, as Roy said, Vary headers MUST be sent (or we ain't 1.1
compliant). This is a little more subtle than meets the eye, as we have to
send Vary even for things that _don't_ match. I'm prepared to put a bit of
thought into making this as easy as poss for modules if there is consensus to
proceed. Also note that BrowserMatch as it stands makes us noncompliant with
1.1, so I guess we have to do something.

BTW, Roy, it occurs to me that a change of server configuration can break
caches (by changing what we Vary over and probably other ways). Perhaps we
should include the date of config files (including .htaccess) as part of the
ETag?

> 
>   2) NCSA-style "Satisfy" functionality.  I thought we had a patch for this
>      but I couldn't find it.  
> 
>   3) Mod_expires should use "Cache-Control".
> 
> 
> 
>   Bugs Which Would Be Really Nice To Fix before Release:
>   Vote: "+1" means "We need to fix this before release".
> 
>   1) parse_htaccess problems due to misconfiguration
>      http://www.apache.org/bugdb/full/14
> 
>   2) Ptime status is always zero in mod_status output.

I thought I'd already explained this one?

> 
>   3) mod_info output never shows "current configuration".
> 
>   4) fix the timeout mechanisms so that reads and responses don't
>      use the same variable.

I thought the problem was that reads/writes used the keepalive timeout if a
keepalive is in progress, which is a major bug.

> 
>   5) Allow the error_log to use pipes, as acess_log does?  There are
>      some odd patches in http://dev.apache.org/incoming related to that.

+1.

>   
>   6) mod_imap should use pools instead of static buffers.
> 
>   7) mod_include shouldn't use rputc, it's slow.

Is it?

> 
> 
> 
> Any others?
> 
> 	Brian (going home to watch Mulder relive a past life)

I hear one of the writers resigned because of the aliens following him around
;-)

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Mime
View raw message