Bug report for Apache httpd-2 [2016/12/25]
+---+ | 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 | | | | | | | | 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |11294|New|Enh|2002-07-30|desired vhost_alias option| |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long| |13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences| |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| |14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst| |14922|Inf|Enh|2002-11-28| is currently hardcoded to 'apache2' | |15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne| |16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config | |16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.| |17107|New|Min|2003-02-16|Windows should not install printenv | |17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make| |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| |18325|New|Enh|2003-03-25|PAM support for suEXEC| |18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L| |19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw| |20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment | |21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced ! | |21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut| |21935|Opn|Nor|2003-07-28|r->parsed_uri->query isn't updated after execution| |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 | |23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util| |23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an| |23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl| |23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s| |23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54| |24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin| |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| |25014|New|Enh|2003-11-26|A flexible interface for mod_log_config | |25201|New|Enh|2003-12-04|Provide Cache Purge operation | |25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information| |25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice| |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 | |25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers| |25667|New|Nor|2003-12-19|Memory leak in function ssl_scache_dbm_retrieve().| |25863|New|Enh|2004-01-02|new per-host initialization hooks | |26005|New|Nor|2004-01-08|SERVER_NAME incorrect when using IPv6 address in U| |26142|New|Maj|2004-01-14|EnableSendFile Off for Windows XP Home| |26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability | |26368|New|Min|2004-01-23|File extensions in AddDescription treated as part | |26446|New|Nor|2004-01-26|flush buckets followed by eos bucket emit multiple| |26478|New|Enh|
Re: Post 2.4.25
> On 24 Dec 2016, at 16:32, Eric Covener wrote: > >> I'm not saying we don't do one so we can do the other; I'm >> saying we do both, at the same time, in parallel. I still >> don't understand why that concept is such an anathema to some >> people. > > I also worry about our ability to deliver a 3.0 with enough > re-architecture for us and and function for users, vs a more > continuous delivery (apologies for bringing buzzaords to dev@httpd) > cadence on 2.4 as we've been in. If you can find a way with limited resources, I would encourage doing both in parallel as well. What are the 2.6/3.0 re-architecture goals/vision out of curiosity? - Mark
Re: Post 2.4.25
> I'm not saying we don't do one so we can do the other; I'm > saying we do both, at the same time, in parallel. I still > don't understand why that concept is such an anathema to some > people. I also worry about our ability to deliver a 3.0 with enough re-architecture for us and and function for users, vs a more continuous delivery (apologies for bringing buzzaords to dev@httpd) cadence on 2.4 as we've been in.
Re: Post 2.4.25
On Dec 24, 2016 10:57, "Jim Jagielski" wrote: Yeah, right now the way we are "doing marketing" is by continually adding features and enhancements to 2.4... It is what keeps 2.4 relevant and is what either keeps current httpd users using httpd or maybe help those on the fence decide on httpd instead of nginx/whatever. My point is that even having a 6 month minimal (and that is, IMO, widely optimistic and unrealistic) of "no new features for 2.4" means that we are basically giving people reasons to drop httpd. Oh, sure, I agree with that. Six months of (perceived) inaction would tell the world we're all done. I'm probably answering a different question. :)
Re: Post 2.4.25
> On Dec 24, 2016, at 8:54 AM, Eric Covener wrote: > > On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr > wrote: >> Next step is to actually end enhancements alltogether >> against 2.4 (we've done that some time ago, security >> issues notwithstanding, on 2.2), and push all of the >> enhancement effort towards 3.0 (2.5-dev). Of course, >> we should continue to pick up bug fixes and help those >> still on 2.4 have a good day. >> >> Let those users looking for cool new things pick up >> the 3.0 release. > > What's the carrot for users/developers in a 2.6/3.0? I'm not sure > they'd come along for this ride. To play devils advocate, it seems > like many of the breaking changes could be imposed by having > deprecated fields/accessors (maybe moving to more of the latter) and > preferred alternatives (to avoid major MMN bumps). > Yeah, that is kind of alluded to in my thoughts. For 3.0 to *really* be a major carrot, we are talking (IMO), a major refactoring. A super streamlining of filters, etc. I used to think making use of Serf would be it, but instead I'm thinking libmill/libdill would be better (plus, to be honest, I still can't figure out all the ins and outs of Serf and there's no documentation at all)... In other words, to ensure that people come along for the ride, the ride has to be revolutionary, at least at some level. And that, imo, takes time to architecture, design, implement and test. If we say "no new stuff for 2.4 until then" then, as I have stated, we have given all our current users a great reason and rationale for leaving, and they will. I'm not saying we don't do one so we can do the other; I'm saying we do both, at the same time, in parallel. I still don't understand why that concept is such an anathema to some people. > Anyone with ideas about what they'd want in a new release is > encouraged to add them to the trunk STATUS file, even if they are just > wishlist items -- it's not a commitment. Added some of mine already :)
Re: Post 2.4.25
> On Dec 24, 2016, at 8:29 AM, Rich Bowen wrote: > > > > On 12/23/2016 03:52 PM, Jim Jagielski wrote: >> Personally, I don't think that backporting stuff to >> 2.4 prevents or disallows development on 2.6/3.0. In >> fact, I think it helps. We can easily do both... >> after all, we are still "working" on 2.2. >> >> As I have also stated, my personal belief is that >> 2.4 is finally reaching some traction, and if we >> "turn off" development/enhancement of 2.4, we will >> stop the uptake of 2.4 in its track. We need to keep >> 2.4 viable and worthwhile we, at the same time, work >> on 2.6/3.0. I think we all understand that getting >> 2.6/3.0 out will not be a quick and/or painless >> action. > > From my perspective, watching Nginx gain traction through superior > marketing, and channeling Dilbert's Pointy Haired Boss in assuming that > everything which I have never done must be simple, I, for one, would > like to see us release a 2.6, and more generally, to release a 2.x every > 2 years, or less, rather than every 4 years, or more. > > My opinion on this, I would emphasize, is 100% marketing, and 0% > technical. I realize we "don't do" marketing, but if we want to still ve > having the fun of doing this in another 20 years, it may be necessary to > get our name out there a little more frequently in terms of doing new > things. We are frankly not great at telling the world about the cool new > things we're doing. > Yeah, right now the way we are "doing marketing" is by continually adding features and enhancements to 2.4... It is what keeps 2.4 relevant and is what either keeps current httpd users using httpd or maybe help those on the fence decide on httpd instead of nginx/whatever. My point is that even having a 6 month minimal (and that is, IMO, widely optimistic and unrealistic) of "no new features for 2.4" means that we are basically giving people reasons to drop httpd. It would be a widely different story if (1) trunk was ready to release and (2) we "committed" to releasing trunk quickly by focusing on low-hanging fruit which would make lives happier and better for our end-users. As I said, my fear is that we will not be able to "control" ourselves in limiting what is in 2.6, which will push the actual release far past the point where it is even relevant. To be clear, if our goal was "Fork trunk as 2.5 NOW, polish and tune 2.5 'as-is' with minimal major refactoring with the goal of getting 2.6 out ASAP" then yeah, sure, the idea of "no new features in 2.4" would have some merit. But based on current conversation, it's obvious that, at least to me, that won't happen and we will be continually refactoring 2.6 to make it a 3.0. Again, you don't "stop" development on a current release until the next release is ready or, at least, "this close" to being ready. You don't sacrifice the present, nor do you leave your users in that limbo.
Re: Post 2.4.25
On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr wrote: > Next step is to actually end enhancements alltogether > against 2.4 (we've done that some time ago, security > issues notwithstanding, on 2.2), and push all of the > enhancement effort towards 3.0 (2.5-dev). Of course, > we should continue to pick up bug fixes and help those > still on 2.4 have a good day. > > Let those users looking for cool new things pick up > the 3.0 release. What's the carrot for users/developers in a 2.6/3.0? I'm not sure they'd come along for this ride. To play devils advocate, it seems like many of the breaking changes could be imposed by having deprecated fields/accessors (maybe moving to more of the latter) and preferred alternatives (to avoid major MMN bumps). Anyone with ideas about what they'd want in a new release is encouraged to add them to the trunk STATUS file, even if they are just wishlist items -- it's not a commitment.
Re: Post 2.4.25
On 12/23/2016 03:52 PM, Jim Jagielski wrote: > Personally, I don't think that backporting stuff to > 2.4 prevents or disallows development on 2.6/3.0. In > fact, I think it helps. We can easily do both... > after all, we are still "working" on 2.2. > > As I have also stated, my personal belief is that > 2.4 is finally reaching some traction, and if we > "turn off" development/enhancement of 2.4, we will > stop the uptake of 2.4 in its track. We need to keep > 2.4 viable and worthwhile we, at the same time, work > on 2.6/3.0. I think we all understand that getting > 2.6/3.0 out will not be a quick and/or painless > action. From my perspective, watching Nginx gain traction through superior marketing, and channeling Dilbert's Pointy Haired Boss in assuming that everything which I have never done must be simple, I, for one, would like to see us release a 2.6, and more generally, to release a 2.x every 2 years, or less, rather than every 4 years, or more. My opinion on this, I would emphasize, is 100% marketing, and 0% technical. I realize we "don't do" marketing, but if we want to still ve having the fun of doing this in another 20 years, it may be necessary to get our name out there a little more frequently in terms of doing new things. We are frankly not great at telling the world about the cool new things we're doing. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon signature.asc Description: OpenPGP digital signature
