Bug report for Apache httpd-2 [2016/12/25]

[bugzilla]

+---+
| 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|

Re: Post 2.4.25

[Mark Blackman]

> 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

[Eric Covener]

> 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

[Rich Bowen]

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

[Jim Jagielski]

> 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

[Jim Jagielski]

> 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

[Eric Covener]

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

[Rich Bowen]

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