Bug report for Apache httpd-2 [2024/02/18]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long| |13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation | |14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR| |16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.| |17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi| |17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header| |20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment | |21260|Opn|Nor|2003-07-02|CacheMaxExpire directive not enforced ! | |21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut| |22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down| |22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7| |22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header | |23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54| |24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32| |24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact| |24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g| |25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files | |25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP | |26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability | |27257|Ass|Enh|2004-02-26|rotatelogs with getopt and setuid | |27715|Ass|Enh|2004-03-16|Client sending misformed Range "bytes = 0-100" ins| |29090|Ass|Enh|2004-05-19|MultiviewsMatch NegotiatedOnly extensions not resp| |29510|Ass|Enh|2004-06-10|ab does not support multiple cookies | |29644|Ver|Nor|2004-06-17|mod_proxy keeps downloading even after the client | |30259|Ass|Enh|2004-07-22|When proxy connects to backend, a DNS lookup is do| |30505|Ass|Enh|2004-08-05|Apache uses 'Error', and not lower level event typ| |31302|Opn|Cri|2004-09-19|suexec doesn't execute commands if they're not in | |31352|Ass|Enh|2004-09-21|RFE, Bind to LDAP server with browser supplier use| |31418|Opn|Nor|2004-09-25|SSLUserName is not usable by other modules| |32328|Opn|Enh|2004-11-19|Make mod_rewrite escaping optional / expose intern| |32750|Ass|Maj|2004-12-17|mod_proxy + Win32DisableAcceptEx = memory leak| |33089|New|Nor|2005-01-13|mod_include: Options +Includes (or IncludesNoExec)| |34519|New|Enh|2005-04-19|Directory index should emit valid XHTML | |35098|Ver|Maj|2005-05-27|Install fails using --prefix | |35154|Opn|Nor|2005-06-01|Support for NID_serialNumber, etc. in SSLUserName | |35652|Opn|Min|2005-07-07|Improve error message: "pcfg_openfile: unable to c| |35768|Opn|Nor|2005-07-17|Missing file logs at far too high of log level| |36676|New|Nor|2005-09-15|time() bug in httpd/os/win32/util_win32.c:wait_for| |36710|Opn|Blk|2005-09-19|CGI output not captured | |37006|Ver|Reg|2005-10-11|"pthread" error when compiling under AIX 5.3 using| |37290|Opn|Min|2005-10-28|DirectoryIndex don't work in scriptaliased directo| |37564|New|Enh|2005-11-19|Suggestion: mod_suexec SuexecUserGroup directive i| |38325|Opn|Nor|2006-01-20|impossible to determine AUTH_TYPE of interpreted r| |38571|New|Enh|2006-02-08|CustomLog directive checked by apachectl configtes| |38995|New|Nor|2006-03-16|httpd tries to communicate with the CGI daemon eve| |39275|Opn|Nor|2006-04-11|slow child_init causes MaxClients warning | |39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn| |39727|Ass|Nor|2006-06-05|Incorrect ETag on gzip:ed content | |39748|New|Enh|2006-06-07|Header and POST support for mod_include |
Re: libapreq subproject roll call
On Fri, Feb 16, 2024, 16:21 Ruediger Pluem wrote: > > > On 2/16/24 2:10 PM, Eric Covener wrote: > >> Will apreq 2.18 still be released? > > > > I think we should, but we need someone to do the release work and 3 > > active PMC members to approve it. Prior to the recent activity, the > > subproject was essentially unchanged and unreleased for 10 years (with > > 1 failed release due to lack of votes) > > > > I would like to understand if libapreq remains viable as a project > > managed by the httpd PMC. We had this conversation last year on the > > private list and the next step is to bring it here. > > I reread the thread on the private list. Did the discussed reach out to > other > PMC's happen? > > > > > It is possible the next release comes with an end-of-life date in the > > future. If this codebase has a community elsewhere, they should join > > us or take it over.If there is anyone out there who wants to get more > > involved, please speak up. > > > > > > I count myself as a release vote of last resort only, but i don't > > think we should be committing to future fixes/releases if nearly > > everyone is in this category. > > I am in that category as well. > I don't have time in the foreseeable future to evaluate if its worth > keeping at least parts of it in trunk to be used for the > locations in httpd where we parse form data (there are some). I guess it > could be beneficial to have this capability in a central > location. > OTOH looking in what we have in trunk I am a bit confused. The trunk code > does not seem to have the perl > glue any longer that is present in the standalone code. Did it go > somewhere else back then? How > would perl users continue to use it even if we would release trunk today > and would close down the > standalone apreq with a terminal release today? > > I would be trying to help with a vote on a terminal release by this PMC if > no one else wants to take over the code base as is, > but we should clearly retire it then. > +1 to letting it RIP (maybe with a note inviting future contributors should there ever be interest in picking it up) There just aren't enough active community members around it anymore IMHO. Issac
