Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

2018-04-22 Thread Alain Toussaint 
Le mercredi 18 avril 2018 à 19:31 -0500, Daniel Ruggeri a écrit :
> On 4/18/2018 1:34 PM, Alain Toussaint wrote:
> > > As an aside - httpd has a —enable-layout option in configure that defines 
> > > where things should
> > > go.
> > > If you patch the following file how you want it and submit it to us, we 
> > > can formally support
> > > LFS
> > > out the box and you can remove the need for your patch:
> > > 
> > > https://svn.apache.org/repos/asf/httpd/sandbox/replacelimit/config.layout
> > > 
> > > Regards,
> > > Graham
> > > —
> > > 
> > 
> > Great idea which I'll submit to the power that be.
> > 
> > Alain
> 
> Minor correction to the URL for latest and greatest:
> https://svn.apache.org/repos/asf/httpd/httpd/trunk/config.layout
> 
> As we love to say, "patches welcome!"
> 
> Feel free to just submit your diff here (since dev@ IS the power that be)
> 

I've been tasked with the patch modification at BLFS. I'll handle it tomorrow 
morning and submit it.

Alain

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

2018-04-22 Thread Greg Stein 
On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri 
wrote:

> Yeah - I think my main concern is really just around the backporting
> process with STATUS and how that will have issues scaling across many
> branches. Further, as each branch deviates, it becomes more of a
> cognitive exercise for developers to figure out if the fix in branch XYZ
> is applicable and the same in ABC.
>
> The more I think about it, the more I *really* like a semver-ish
> approach where major represents the ABI that will not be broken, minor
> represents the feature set (for backwards compatibility) and patch
> represents forward-compatible changes/fixes.


Apache Subversion takes the patch number much more literally. They are
merely fixes to behavior defined in the minor release. The API/ABI is never
touched during a patch release. You could build against 1.7.13, then
install 1.7.0 and your code works against it. Then upgrade svn to 1.7.20
and it still works. Downgrade to 1.7.5 ... you get the picture.

I see several issues with the recent threads of discussion:

* How releases are numbered, and what guarantees are made relative to those
numbers
* What kinds of gating of features/fixes is defined by the process?
* How are branches created/maintained, relative to the above

Classic httpd numbering can certainly be made to work (empirically: it
has). semver is well-documented, understood, and downstream users would not
need to understand our quirks. It does kind of impose decisions on gating
of features, though (Q2 above).

It is unclear what problem is being solved. It seems like the unpredictable
feature set of 2.4.x. And/or when to stop loading features into that, and
start a 2.6.x series. (or 3.0?)

Cheers,
-g

ps. my vote is for semver and strict controls on patch releases. chew
through release numbers. they are cheap. downstream will pick one release
and run with that. it doesn't matter to them if we have a new minor every
six months (which means new features, which distros won't pick those
features from patch releases anyways; may as well move them to a minor)

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

2018-04-22 Thread Eric Covener 
On Sun, Apr 22, 2018 at 2:03 PM, Daniel Ruggeri  wrote:
> Unhelpful for whom? If we ship the latest, secure config from the single 
> release branch, we wouldn't be encumbered by having to use tricks for fixes.

I think we're getting off into the weeds a bit here.  My belief is
that most users extend the configuration, and different users want
different behaviors even if they use the same distribution.  Most
users  at any given time want no changes at all beyond the required
security fixes.

I don't feel like "directives" are even a secondary source of any of
the recent regressions. In reality, gating changes behind directives
would have likely avoided a good deal of the regressions if we had a
different tolerance for such a thing or the impacts could have been
anticipated.

That's why I don't see any benefit in prohibiting new directives in a
reworked service stream being managed as more stable, even without
weighing any of the other tradeoffs. I see only risk in that fixes can
only be delivered when they are safe for 100% of users 100% of the
time.

> In the same vein of thought, if it is disruptive to a config, that signals a 
> minor bump. Patch changes must be forward compatible.

This doesn't really differ from the status quo.

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

2018-04-22 Thread Graham Leggett 
On 19 Apr 2018, at 5:11 PM, Jim Jagielski  wrote:

> With all this in mind, should we try to set things up so that the
> next release cycle uses the concept of RCs?
> 
> If so, and if people like, I can come up with a baseline
> proposal on the process for us to debate and come to
> some consensus on.

What specific problem does this aim to solve?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

2018-04-22 Thread Daniel Ruggeri 
Unhelpful for whom? If we ship the latest, secure config from the single 
release branch, we wouldn't be encumbered by having to use tricks for fixes. 
Most end users who get their custom build from the distros would get the same 
custom directive-level fixes applicable to them (ie:  they know what's in the 
build so don't have to do such gymnastics).

In the same vein of thought, if it is disruptive to a config, that signals a 
minor bump. Patch changes must be forward compatible.
-- 
Daniel Ruggeri

On April 22, 2018 12:32:24 PM CDT, Eric Covener  wrote:
>On Sun, Apr 22, 2018 at 1:31 PM, Eric Covener 
>wrote:
>>> I'd further add that no directives are added in
>>> patch releases, but minor releases would be fair game.
>>
>> I don't think that kind of rule would be helpful, it just pushes
>> configuration into defines, per-request environment variables, etc
>> which are worse (because unlike a directive, you can't tell if
>they're
>> present)
>
>Of fixes which may be disruptive, that is.

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

2018-04-22 Thread Eric Covener 
On Sun, Apr 22, 2018 at 1:31 PM, Eric Covener  wrote:
>> I'd further add that no directives are added in
>> patch releases, but minor releases would be fair game.
>
> I don't think that kind of rule would be helpful, it just pushes
> configuration into defines, per-request environment variables, etc
> which are worse (because unlike a directive, you can't tell if they're
> present)

Of fixes which may be disruptive, that is.

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

2018-04-22 Thread Eric Covener 
> I'd further add that no directives are added in
> patch releases, but minor releases would be fair game.

I don't think that kind of rule would be helpful, it just pushes
configuration into defines, per-request environment variables, etc
which are worse (because unlike a directive, you can't tell if they're
present)

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

2018-04-22 Thread Daniel Ruggeri 
Yeah - I think my main concern is really just around the backporting
process with STATUS and how that will have issues scaling across many
branches. Further, as each branch deviates, it becomes more of a
cognitive exercise for developers to figure out if the fix in branch XYZ
is applicable and the same in ABC.

The more I think about it, the more I *really* like a semver-ish
approach where major represents the ABI that will not be broken, minor
represents the feature set (for backwards compatibility) and patch
represents forward-compatible changes/fixes. This may be, in spirit,
what you are suggesting. I'd further add that no directives are added in
patch releases, but minor releases would be fair game. How we choose to
maintain that behind the scenes is a thought exercise. Given that most
of our users get httpd from distros, I'd be in favor of having only two
long-lived branches: trunk and release. The distros are already taking
the point-release they want and curating fixes/changes for it, so they
will be doing what they do regardless of our direction. For
administrators building httpd themselves, they have control of when to
pull the trigger on a build and what they build, so I don't think they
would be harmed by such a change. Hopefully this isn't considered a
caustic statement (it is not intended to be), but I feel that this would
bring our versioning practices more in line with what most OSS projects
are doing these days and also avoid some of the issues managing several
branches. (I really am digging this idea :-) I'm glad folks have
proposed it...)

-- 
Daniel Ruggeri

On 4/20/2018 12:08 AM, William A Rowe Jr wrote:
> Let me counter with this... Rather than break the API every m.n
> release, what if we roll on to 2.6 with no ABI breakage, or resolve
> with impumity everything wrong in 3.0 with a firm commitment not to
> break it again till 4.0?
>
> This might be the root problem of our trying to !is versioning semantics.
>
>
> On Thu, Apr 19, 2018, 19:39 Daniel Ruggeri  > wrote:
>
> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
>
>
> If we end up with API and feature freeze on branch 2.4, then we'd
> expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a
> release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
>
>
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches
> and a
> bugfix applicable to all (or worse... a security fix that would
> dictate
> all should be released/disclosed at the same time).
>
> -- 
> Daniel Ruggeri
>
> On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> > I don't disagree with RC's entirely, or the mechanism you
> suggest, but
> > that isn't what I read as proposed.
> >
> > Our issue is that every httpd must be distinguished, we won't ship
> > four tarballs all claiming 2.4.34 (GA). Which one is the person
> > complaining about? Are we back to SHA signature of the source
> tarball
> > (that isn't even assuredly what they built the binary from?)
> >
> > We can decorate the rc in the versioning, but that isn't part of
> 2.4.x
> > API, unless we swap out the "-dev" string tag for an "-rc#" value.
> >
> > It is not reasonable to lock a branch for an indeterminate length of
> > time. Branching the RC into what becomes the final release, and
> making
> > it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> > might help discourage disruptive backports, but there is no
> suggestion
> > yet of what is acceptable, either on such a frozen main branch or rc
> > branch.
> >
> > In fact our policy reflects that two competing release candidates is
> > an entire valid and even expected situation, and any process that
> > further blocks this should be firmly rebuffed.
> >
> > As it reads so far the proposal is the way we do things, now
> > conserving subversion numbers as precious, if only to reenforce a
> > stake in the ground that version major and minor numbers are
> similarly
> > precious, (which they are not.)
> >
> > With the addition of freezing changes on 2.4.x branch for a time we
> > succeed in impeading progress towards version .next, while not
> > otherwise changing the status quo.
> >
> > What you suggest is yet another thing, based on forking the RC
> release
>

Re: svn commit: r1829659 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_protocol.h server/protocol.c

2018-04-22 Thread Yann Ylavic 
On Fri, Apr 20, 2018 at 9:01 PM, Ruediger Pluem  wrote:
>
>
> On 04/20/2018 04:30 PM, yla...@apache.org wrote:
>> Author: ylavic
>> Date: Fri Apr 20 14:30:19 2018
>> New Revision: 1829659
>>
>> URL: http://svn.apache.org/viewvc?rev=1829659=rev
>> Log:
>> http: add ap_fgetline() and AP_GETLINE_NONBLOCK flag.
>>
>> It allows to read a line directly from an input filter, in blocking mode
>> or not. Since no request_rec is needed, a pool may be given.
>>
>> Existing ap_[r]getline() function are now based off ap_fgetline() by calling:
>> ap_fgetline(s, n, read, r->proto_input_filters, flags, bb, r->pool);
>>
>> Will follow up with a new ap_get_mime_headers_*() flavor which can be used by
>> any filter that needs non-blocking and not necessarily has a request_rec 
>> (e.g.
>> ap_http_filter() to read proxied response trailers).
>>
>>
>> Modified:
>> httpd/httpd/trunk/include/ap_mmn.h
>> httpd/httpd/trunk/include/http_protocol.h
>> httpd/httpd/trunk/server/protocol.c
>>
>
>> Modified: httpd/httpd/trunk/server/protocol.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1829659=1829658=1829659=diff
>> ==
>> --- httpd/httpd/trunk/server/protocol.c (original)
>> +++ httpd/httpd/trunk/server/protocol.c Fri Apr 20 14:30:19 2018
>
>> @@ -517,10 +522,31 @@ cleanup:
>>  return rv;
>>  }
>>
>> +AP_DECLARE(apr_status_t) ap_fgetline(char **s, apr_size_t n,
>> + apr_size_t *read, ap_filter_t *f,
>> + int flags, apr_bucket_brigade *bb,
>> + apr_pool_t *p)
>> +{
>> +return ap_fgetline_impl(s, n, read, f, flags, bb, p);
>> +}
>> +
>> +/* Same as ap_fgetline(), working on r's pool and protocol input filters.
>> + * Pulls from r->proto_input_filters instead of r->input_filters for
>> + * stricter protocol adherence and better input filter behavior during
>> + * chunked trailer processing (for http).
>> + */
>> +AP_DECLARE(apr_status_t) ap_rgetline_core(char **s, apr_size_t n,
>> +  apr_size_t *read, request_rec *r,
>> +  int flags, apr_bucket_brigade *bb)
>> +{
>> +return ap_fgetline_impl(s, n, read, r->proto_input_filters, flags,
>> +bb, r->pool);
>> +}
>> +
>>  #if APR_CHARSET_EBCDIC
>>  AP_DECLARE(apr_status_t) ap_rgetline(char **s, apr_size_t n,
>>   apr_size_t *read, request_rec *r,
>> - int fold, apr_bucket_brigade *bb)
>> + int flags, apr_bucket_brigade *bb)
>>  {
>>  /* on ASCII boxes, ap_rgetline is a macro which simply invokes
>>   * ap_rgetline_core with the same parms
>> @@ -532,8 +558,9 @@ AP_DECLARE(apr_status_t) ap_rgetline(cha
>>   */
>>  apr_status_t rv;
>>
>> -rv = ap_rgetline_core(s, n, read, r, fold, bb);
>> -if (rv == APR_SUCCESS || APR_STATUS_IS_ENOSPC(rv)) {
>> +rv = ap_fgetline_impl(s, n, read, r->proto_input_filters, flags,
>> +  bb, r->pool);
>> +if (*read) {
>>  ap_xlate_proto_from_ascii(*s, *read);
>>  }
>>  return rv;
>> @@ -542,7 +569,6 @@ AP_DECLARE(apr_status_t) ap_rgetline(cha
>>
>>  AP_DECLARE(int) ap_getline(char *s, int n, request_rec *r, int flags)
>>  {
>> -char *tmp_s = s;
>>  apr_status_t rv;
>>  apr_size_t len;
>>  apr_bucket_brigade *tmp_bb;
>> @@ -553,7 +579,8 @@ AP_DECLARE(int) ap_getline(char *s, int
>>  }
>>
>>  tmp_bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
>> -rv = ap_rgetline(_s, n, , r, flags, tmp_bb);
>> +rv = ap_fgetline_impl(, n, , r->proto_input_filters, flags,
>> +  tmp_bb, r->pool);
>
> Hm, now ap_getline is no longer EBCDIC agnostic. Is this intended?

Nope, it was also missing EBCDIC translation for ap_fgetline() :/

Fixed in r1829789, thanks for the review!

Regards,
Yann.

Bug report for Apache httpd-2 [2018/04/22]

2018-04-22 Thread 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|
|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 |
|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|2004-01-28|mod_dav does not expose a method for setting the D|
|26835|New|Enh|2004-02-10|[PATCH] Mod_status Readability & Browser Side Tabl|