Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 10:25 AM, Jim Jagielski wrote:
On Apr 17, 2008, at 10:04 AM, Plüm, Rüdiger, VF-Group wrote:
But sure this could be also fixed in the appropriate canon_handler
hooks of mod_proxy_http and mod_proxy_ajp.
That's what I'm wondering... Treating this "special" inside
of mod_proxy itself, when it's really a protocol issue (and
what is "right" for that protocol) just seems a safer way.
Or, at least, helps to maintain that illusion of abstraction :)
Something like:
Index: mod_proxy_http.c
===
--- mod_proxy_http.c(revision 649076)
+++ mod_proxy_http.c(working copy)
@@ -72,7 +72,9 @@
* has already been decoded. True proxy requests have r->uri
* == r->unparsed_uri, and no others have that property.
*/
-if (r->uri == r->unparsed_uri) {
+if ((r->uri == r->unparsed_uri) ||
+((r->proxyreq == PROXYREQ_REVERSE) &&
+ apr_table_get(r->notes, "proxy-nocanon"))) {
search = strchr(url, '?');
if (search != NULL)
*(search++) = '\0';
ajp and fcgi similarly... :)
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jim Jagielski wrote: This section is the same as that in the bug report (make mod_proxy_ajp aware of the nocanon EnvVar), but the attached patch also includes a workaround for the doubling of any query strings. This 2nd part needs to be addressed but the real fix may not be done by this patch. If you have no query args, then either is fine. We generally have query strings (and have to support the most general case due to the number of quite disparate pages being served), so we'll need the full patch. Thanks. -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 10:48 AM, Jess Holle wrote:
Jim Jagielski wrote:
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 648735)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -72,8 +72,13 @@
search = r->args;
/* process path */
-path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
- r->proxyreq);
+if (apr_table_get(r->notes, "proxy-nocanon")) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r->pool, url, strlen(url),
+ enc_path, 0, r->proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have things set up
to do so), but our engineer who does is slated to test the patch
attached to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
This section is the same as that in the bug report (make mod_proxy_ajp
aware of the nocanon EnvVar), but the attached patch also includes
a workaround for the doubling of any query strings. This 2nd part
needs to be addressed but the real fix may not be done by
this patch. If you have no query args, then either is fine.
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
> -Ursprüngliche Nachricht-
> Von: Jess Holle
> Gesendet: Donnerstag, 17. April 2008 16:50
> An: dev@httpd.apache.org
> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>
> Jess Holle wrote:
> > Jim Jagielski wrote:
> >> Can you try:
> >>
> >> Index: modules/proxy/mod_proxy_ajp.c
> >> ===
> >> --- modules/proxy/mod_proxy_ajp.c(revision 648735)
> >> +++ modules/proxy/mod_proxy_ajp.c(working copy)
> >> @@ -72,8 +72,13 @@
> >> search = r->args;
> >>
> >> /* process path */
> >> -path = ap_proxy_canonenc(r->pool, url, strlen(url),
> enc_path, 0,
> >> - r->proxyreq);
> >> +if (apr_table_get(r->notes, "proxy-nocanon")) {
> >> +path = url; /* this is the raw path */
> >> +}
> >> +else {
> >> +path = ap_proxy_canonenc(r->pool, url, strlen(url),
> >> + enc_path, 0, r->proxyreq);
> >> +}
> >> if (path == NULL)
> >> return HTTP_BAD_REQUEST;
> > I don't do our Apache builds any more (and don't have
> things set up to
> > do so), but our engineer who does is slated to test the
> patch attached
> > to the bug soon.
> >
> > Is this the same as the patch attached to the bug report -- or a
> > different one?
> To be more clear exactly which patch should we be testing?
You better go with the one from the bug report. Otherwise you end up with
doubled query strings.
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jess Holle wrote:
Jim Jagielski wrote:
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 648735)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -72,8 +72,13 @@
search = r->args;
/* process path */
-path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
- r->proxyreq);
+if (apr_table_get(r->notes, "proxy-nocanon")) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r->pool, url, strlen(url),
+ enc_path, 0, r->proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have things set up to
do so), but our engineer who does is slated to test the patch attached
to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
To be more clear exactly which patch should we be testing?
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jim Jagielski wrote:
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c(revision 648735)
+++ modules/proxy/mod_proxy_ajp.c(working copy)
@@ -72,8 +72,13 @@
search = r->args;
/* process path */
-path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
- r->proxyreq);
+if (apr_table_get(r->notes, "proxy-nocanon")) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r->pool, url, strlen(url),
+ enc_path, 0, r->proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have things set up to
do so), but our engineer who does is slated to test the patch attached
to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 10:04 AM, Plüm, Rüdiger, VF-Group wrote: But sure this could be also fixed in the appropriate canon_handler hooks of mod_proxy_http and mod_proxy_ajp. That's what I'm wondering... Treating this "special" inside of mod_proxy itself, when it's really a protocol issue (and what is "right" for that protocol) just seems a safer way. Or, at least, helps to maintain that illusion of abstraction :)
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
> -Ursprüngliche Nachricht- > Von: Jim Jagielski > Gesendet: Donnerstag, 17. April 2008 15:16 > An: dev@httpd.apache.org > Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) > > > On Apr 17, 2008, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote: > > But the patch I just attached to PR44803 should fix this: > > > > https://issues.apache.org/bugzilla/attachment.cgi?id=21826 > > > > :) > > Obviously, +1 on the mod_proxy_ajp patch (within minutes > we had the same idea). Mulling over the impacts of the Yep :-) > up_uri_wout_query part though... The query string was present twice (one from unparsed_uri which still contains the query string and one that was added via r->query later when running the canon_handler hook). But sure this could be also fixed in the appropriate canon_handler hooks of mod_proxy_http and mod_proxy_ajp. Regards Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote: But the patch I just attached to PR44803 should fix this: https://issues.apache.org/bugzilla/attachment.cgi?id=21826 :) Obviously, +1 on the mod_proxy_ajp patch (within minutes we had the same idea). Mulling over the impacts of the up_uri_wout_query part though...
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 7:59 AM, Jess Holle wrote:
jean-frederic clere wrote:
IMHO we already forward them escaped. The problem is that things get
unescaped first and for reserved characters like ';' this process
cannot be reverted. So if the original URL contained an escaped ';'
the forwarded one will contain a literal ';'.
With mod_proxy or better ProxyPass you already can get around this
by specifying the nocanon option which causes the the original
URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
No nocanon doesn't do that. it use url (in which the %3B is already
converted in ;) instead the r->unparsed_uri.
And that would be JK_OPT_FWDURICOMPATUNPARSED and not
ForwardURIEscaped.
To get ForwardURIEscaped we could call ap_escape_uri() on url.
I can confirm that using ProxyPass and nocanon does not solve the
problem -- I just tested this.
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c (revision 648735)
+++ modules/proxy/mod_proxy_ajp.c (working copy)
@@ -72,8 +72,13 @@
search = r->args;
/* process path */
-path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
- r->proxyreq);
+if (apr_table_get(r->notes, "proxy-nocanon")) {
+path = url; /* this is the raw path */
+}
+else {
+path = ap_proxy_canonenc(r->pool, url, strlen(url),
+ enc_path, 0, r->proxyreq);
+}
if (path == NULL)
return HTTP_BAD_REQUEST;
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 17, 2008, at 7:59 AM, Jess Holle wrote: jean-frederic clere wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r->unparsed_uri. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. I can confirm that using ProxyPass and nocanon does not solve the problem -- I just tested this. Hmmm mod_proxy_http is aware, but methinks mod_proxy_ajp may not be at this point :/
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
> -Ursprüngliche Nachricht- > Von: Jess Holle > Gesendet: Donnerstag, 17. April 2008 13:59 > An: dev@httpd.apache.org > Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) > > jean-frederic clere wrote: > >> IMHO we already forward them escaped. The problem is that > things get > >> unescaped first and for reserved characters like ';' this process > >> cannot be reverted. So if the original URL contained an escaped ';' > >> the forwarded one will contain a literal ';'. > >> With mod_proxy or better ProxyPass you already can get around this > >> by specifying the nocanon option which causes the the original > >> URL to be forwarded (much like JkOptions > +ForwardURICompatUnparsed). > > No nocanon doesn't do that. it use url (in which the %3B is already > > converted in ;) instead the r->unparsed_uri. > > And that would be JK_OPT_FWDURICOMPATUNPARSED and not > ForwardURIEscaped. > > To get ForwardURIEscaped we could call ap_escape_uri() on url. > I can confirm that using ProxyPass and nocanon does not solve the > problem -- I just tested this. I jsut retested with trunk again (/test/foo%3Bbar?spaz=bot). In the nocanon case we sent /test/foo%253Bbar%3Fspaz=bot via AJP (network sniff) and in the case without noncanon we sent /test/foo;bar So in the first case we escape too often and in the second we do not escape enough. But the patch I just attached to PR44803 should fix this: https://issues.apache.org/bugzilla/attachment.cgi?id=21826 So ProxyPassMatch does now work as desired (with option nocanon of course). Regards Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
> -Ursprüngliche Nachricht- > Von: jean-frederic clere > Gesendet: Donnerstag, 17. April 2008 13:39 > An: dev@httpd.apache.org > Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) > > Plüm wrote: > > > > > >> -Ursprüngliche Nachricht- > >> Von: jean-frederic clere > >> Gesendet: Donnerstag, 17. April 2008 11:02 > >> An: dev@httpd.apache.org > >> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) > >> > >> Jim Jagielski wrote: > >>> On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: > >>>> On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: > >>>>> Jim Jagielski wrote: > >>>>>> Plus, every 3 months would coincide with the > >> report-to-board cycle, > >>>>>> making it easier for everyone to follow :) Next is due > in May, so > >>>>>> if we release this month, then we can follow a "Release before > >>>>>> the board report" or else "Release at board report" cycle (with > >>>>>> the caveat I noted before ;) ) > >>>>>> > >>>>>> As noted (and as I pinged a few people about in Amsterdam), I'm > >>>>>> looking to push for a 2.2.9 soon. We have enough for sure > >>>>>> warrant it... There is the "ship 1.3.0 with 2.2.9" > >> thread going on, > >>>>>> but I do not want 2.2.9 to hold off too long for that... > >>>>>> > >>>>>> So I'd like to propose 2.2.9 for the end of this month. > >>>>> Sorry to butt in, but is there any hope of getting issue #44803 > >>>>> addressed in that timeframe? > >>>>> > >>>> Possibly, yes. > >>>> > >>> Quick look: We need to re-adjust this post fixups, since this > >>> should be a setting ala flushpackets, etc... > >>> > >>> > >> I have looked to #44803 in fact we need something like JkOptions > >> +ForwardURIEscaped which means something that requires > > > > IMHO we already forward them escaped. The problem is that things get > > unescaped first and for reserved characters like ';' this process > > cannot be reverted. So if the original URL contained an escaped ';' > > the forwarded one will contain a literal ';'. > > With mod_proxy or better ProxyPass you already can get around this > > by specifying the nocanon option which causes the the original > > URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). > > No nocanon doesn't do that. it use url (in which the %3B is already > converted in ;) instead the r->unparsed_uri. No. It does use r->unparsed_uri if r->uri and r->unparsed_uri both match the ProxyPass(Match) condition. > And that would be JK_OPT_FWDURICOMPATUNPARSED and not > ForwardURIEscaped. > To get ForwardURIEscaped we could call ap_escape_uri() on url. We don't need to as we already call ap_proxy_canonenc on the URL which does this. Regards Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
jean-frederic clere wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r->unparsed_uri. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. I can confirm that using ProxyPass and nocanon does not solve the problem -- I just tested this. -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Plüm wrote: -Ursprüngliche Nachricht- Von: jean-frederic clere [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. April 2008 11:02 An: dev@httpd.apache.org Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) Jim Jagielski wrote: On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a "Release before the board report" or else "Release at board report" cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. Quick look: We need to re-adjust this post fixups, since this should be a setting ala flushpackets, etc... I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). No nocanon doesn't do that. it use url (in which the %3B is already converted in ;) instead the r->unparsed_uri. And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped. To get ForwardURIEscaped we could call ap_escape_uri() on url. Cheers Jean-Frederic Regards Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
> -Ursprüngliche Nachricht- > Von: Jess Holle [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 17. April 2008 12:36 > An: dev@httpd.apache.org > Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) > > Plüm wrote: > > IMHO we already forward them escaped. The problem is that things get > > unescaped first and for reserved characters like ';' this process > > cannot be reverted. So if the original URL contained an escaped ';' > > the forwarded one will contain a literal ';'. > > With mod_proxy or better ProxyPass you already can get around this > > by specifying the nocanon option which causes the the original > > URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). > > > That makes sense -- as we're only having issues with ";" to > the best of > my knowledge. > > That said, we need to use the rewrite stuff shown in the bug (unless > there's another way we're missing) to forward just the appropriate > requests to Tomcat. Is there a way we're missing (that would > ideally be > clearly documented...) to avoid running into issues with ";" > when using > mod_proxy and mod_rewrite as we are? If not, then one is > really needed > for ";". Have your tried something like ProxyPassMatch (^/somewhere/.*jsp$) http://backend$1 nocanon ? Regards Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Plüm wrote: IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). That makes sense -- as we're only having issues with ";" to the best of my knowledge. That said, we need to use the rewrite stuff shown in the bug (unless there's another way we're missing) to forward just the appropriate requests to Tomcat. Is there a way we're missing (that would ideally be clearly documented...) to avoid running into issues with ";" when using mod_proxy and mod_rewrite as we are? If not, then one is really needed for ";". -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
jean-frederic clere wrote: I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires changes in both mod_rewrite and mod_proxy. I will propose a patch soon. Thank you! -- Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
> -Ursprüngliche Nachricht- > Von: jean-frederic clere [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 17. April 2008 11:02 > An: dev@httpd.apache.org > Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases) > > Jim Jagielski wrote: > > > > On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: > >> > >> On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: > >>> Jim Jagielski wrote: > >>>> Plus, every 3 months would coincide with the > report-to-board cycle, > >>>> making it easier for everyone to follow :) Next is due in May, so > >>>> if we release this month, then we can follow a "Release before > >>>> the board report" or else "Release at board report" cycle (with > >>>> the caveat I noted before ;) ) > >>>> > >>>> As noted (and as I pinged a few people about in Amsterdam), I'm > >>>> looking to push for a 2.2.9 soon. We have enough for sure > >>>> warrant it... There is the "ship 1.3.0 with 2.2.9" > thread going on, > >>>> but I do not want 2.2.9 to hold off too long for that... > >>>> > >>>> So I'd like to propose 2.2.9 for the end of this month. > >>> Sorry to butt in, but is there any hope of getting issue #44803 > >>> addressed in that timeframe? > >>> > >> > >> Possibly, yes. > >> > > > > Quick look: We need to re-adjust this post fixups, since this > > should be a setting ala flushpackets, etc... > > > > > > I have looked to #44803 in fact we need something like JkOptions > +ForwardURIEscaped which means something that requires IMHO we already forward them escaped. The problem is that things get unescaped first and for reserved characters like ';' this process cannot be reverted. So if the original URL contained an escaped ';' the forwarded one will contain a literal ';'. With mod_proxy or better ProxyPass you already can get around this by specifying the nocanon option which causes the the original URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed). Regards Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jim Jagielski wrote: On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a "Release before the board report" or else "Release at board report" cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. Quick look: We need to re-adjust this post fixups, since this should be a setting ala flushpackets, etc... I have looked to #44803 in fact we need something like JkOptions +ForwardURIEscaped which means something that requires changes in both mod_rewrite and mod_proxy. I will propose a patch soon. Cheers Jean-Frederic
Re: [PROPOSAL] Time Based Releases
Brad Nicholes wrote: IOW, we may be required to be conservative when it comes to 1.3.x, 2.0.x or 2.2.x, s/be required/desire/ - it's a group consensus. It wasn't this way prior to the 2.0.43 and doesn't have to be that way in the future, but I think it has served our users well, and hasn't gotten in our way until... but the same level of conservatism shouldn't apply to 2.4 or 3.0. ++1 Bill
Configuration was Re: [PROPOSAL] Time Based Releases
On 4/15/08 12:27 PM, "Brad Nicholes" <[EMAIL PROTECTED]> wrote: >IOW, we may be required to be conservative > when it comes to 1.3.x, 2.0.x or 2.2.x, but the same level of conservatism > shouldn't apply to 2.4 or 3.0. Which is one of the reasons I think now is the time to completely redo the configuration scheme. I think Paul would agree with me that we should just embed Lua (not as mod_wombat) and be done with it. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [PROPOSAL] Time Based Releases
>>> On 4/15/2008 at 5:49 AM, in message <[EMAIL PROTECTED]>, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > Jim Jagielski wrote: >> I think what Paul is suggesting (he will for sure correct me >> if I'm wrong) is that it's better to at least have some semblance >> of a schedule than not, and by baselining every X months for a release, >> it provides us, as volunteers, to better allocate time. It does >> not mean, imo, that we rush out packages that aren't ready or >> release something just because "we have a schedule to keep"... >> we all have day jobs that force that on us, and we don't want >> that kind of pressure here as well. >> >> However, looking over things, I think that we have enough active >> activity such that a ~3month "cycle" might be workable... > > IOW, if we declare a 2 month cycle, we end up with releases every > three months ;-) I believe that it would benefit the project to do releases a little more frequently than we have in the past, I would just rather see the project release because a release is warranted. Not because a schedule dictates that we do it. I guess I have always liked the fact that Apache does things because it is the right thing to do, not because there is some artificial requirement. If Paul wants to release every two months, more power to him and to the project. Just do it, we shouldn't have to take a vote or change any of our existing written or unwritten policies. Maybe the real problem is that the Apache httpd project has lost some of the passion that it used to have. I think that is what Roy was saying in the Keynote slides that Paul forwarded to the list. Maybe the problem is that we have all become a little too conservative when it comes to releases because we have all realized just how much people depend on this little piece of software. However that conservative attitude only applies to the past, it shouldn't apply to the future. IOW, we may be required to be conservative when it comes to 1.3.x, 2.0.x or 2.2.x, but the same level of conservatism shouldn't apply to 2.4 or 3.0. It's been 3 1/2 years since we started the last major release cycle of the httpd server and 2 1/2 years since the last major release of the web server. That's longer than many if not most commercial products. So what, if some of the 2.3 features are not fully baked or if some things may not work quite right. Why should that stop the project from releasing something anyway, whatever that something might be. If it is adopted and accepted, then great. If it falls on its face then we know what not to do the next time. I know, I am probably preaching to the choir and it may even sound like I am arguing both sides of the subject line above. But if we want to get the passion back in the project, then it might be time for the project to take some more risks. Release because it is the right thing to do. Brad
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
I've just updated STATUS to reflect that I'm hoping for us to drive towards a 2.2.9 release by the end of this month...
Re: [PROPOSAL] Time Based Releases
Jim Jagielski wrote: I think what Paul is suggesting (he will for sure correct me if I'm wrong) is that it's better to at least have some semblance of a schedule than not, and by baselining every X months for a release, it provides us, as volunteers, to better allocate time. It does not mean, imo, that we rush out packages that aren't ready or release something just because "we have a schedule to keep"... we all have day jobs that force that on us, and we don't want that kind of pressure here as well. However, looking over things, I think that we have enough active activity such that a ~3month "cycle" might be workable... IOW, if we declare a 2 month cycle, we end up with releases every three months ;-)
Re: [PROPOSAL] Time Based Releases
On Mon, Apr 14, 2008 at 12:46:43PM -0400, Jim Jagielski wrote: > I think what Paul is suggesting (he will for sure correct me > if I'm wrong) is that it's better to at least have some semblance > of a schedule than not, and by baselining every X months for a release, > it provides us, as volunteers, to better allocate time. It does > not mean, imo, that we rush out packages that aren't ready or > release something just because "we have a schedule to keep"... > we all have day jobs that force that on us, and we don't want > that kind of pressure here as well. > TBH, I'm not too keen on the idea of releasing just because we're suddenly hitting a specific date - if there's no changes worth releasing... Yeah, I'd like to see it happen more often than every 6-8 months, but every 2-3 months is just going to create unnecessary work fort the admins out there. Going down this route, I think the bare minimum way of playing nice would be to very clearly mark releases as either security, feature or just that time of the month releases. > However, looking over things, I think that we have enough active > activity such that a ~3month "cycle" might be workable... How many branches are we talking about? the whole 2.x bunch or? just my $.02 Mads Toftum -- http://soulfood.dk
Re: [PROPOSAL] Time Based Releases
I think what Paul is suggesting (he will for sure correct me if I'm wrong) is that it's better to at least have some semblance of a schedule than not, and by baselining every X months for a release, it provides us, as volunteers, to better allocate time. It does not mean, imo, that we rush out packages that aren't ready or release something just because "we have a schedule to keep"... we all have day jobs that force that on us, and we don't want that kind of pressure here as well. However, looking over things, I think that we have enough active activity such that a ~3month "cycle" might be workable...
Re: [PROPOSAL] Time Based Releases
> -Ursprüngliche Nachricht- > Von: Brad Nicholes [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 14. April 2008 17:44 > An: dev@httpd.apache.org > Betreff: Re: [PROPOSAL] Time Based Releases > > >>> On 4/12/2008 at 11:20 AM, in message > <[EMAIL PROTECTED]>, Paul > Querna <[EMAIL PROTECTED]> wrote: > > This is something I have been thinking about for awhile, > and discussed > > with a few other http server people before. > > > > I think that for the 'stable' branch, we should move to > time based releases. > > > > My proposal is for every 2 months, we do a release of the > main stable > > branch, which at this time is 2.2.x. > > > > Security Issues of great importance of course would trigger > an immediate > > release. Depending on the nearness to a scheduled release, > we may or > > may not scrap the next time based release. > > > > I guess I am not sure what setting a schedule is trying to > accomplish. Can't you do this already? If somebody wants to > release every 2 months, that person can call for the release > and be the RM every two months. In other words, as long as > there is somebody willing to do the work, then the work will > happen. If a release isn't required, ie. no real appreciable > improvement since the previous release, then why require > everyone to mobilize for very little gain. I guess I am > looking for the problem that a hard schedule resolves when we > can already release as early or as often as desired. Well put. Reminds me of André's question "What problem are we trying to solve?" The only benefit I can see in the schedule is that it gives all of us a gentle reminder every x month that we should think about a new release. If there are not enough people then that think that a release makes sense then there will be no release. So my point in proposing a longer period than the two month is that I want to increase the likelyhood that enough people think that a release makes sense. IMHO it would be a pity if the RM puts its valueable time in creating a release tarball that fails to get the needed votes. Even if gets enough votes I think it would be bad if the testing is limited due to a tough schedule which could lower the quality of the release. Regards Rüdiger
Re: [PROPOSAL] Time Based Releases
>>> On 4/12/2008 at 11:20 AM, in message <[EMAIL PROTECTED]>, Paul Querna <[EMAIL PROTECTED]> wrote: > This is something I have been thinking about for awhile, and discussed > with a few other http server people before. > > I think that for the 'stable' branch, we should move to time based releases. > > My proposal is for every 2 months, we do a release of the main stable > branch, which at this time is 2.2.x. > > Security Issues of great importance of course would trigger an immediate > release. Depending on the nearness to a scheduled release, we may or > may not scrap the next time based release. > I guess I am not sure what setting a schedule is trying to accomplish. Can't you do this already? If somebody wants to release every 2 months, that person can call for the release and be the RM every two months. In other words, as long as there is somebody willing to do the work, then the work will happen. If a release isn't required, ie. no real appreciable improvement since the previous release, then why require everyone to mobilize for very little gain. I guess I am looking for the problem that a hard schedule resolves when we can already release as early or as often as desired. Brad
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote: On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a "Release before the board report" or else "Release at board report" cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. Quick look: We need to re-adjust this post fixups, since this should be a setting ala flushpackets, etc...
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 14, 2008, at 10:00 AM, Jess Holle wrote: Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a "Release before the board report" or else "Release at board report" cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? Possibly, yes. The feedback on the "real" gap between mod_jk and mod_proxy_ajp is stuff we really appreciate! Thanks!
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Jim Jagielski wrote: Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a "Release before the board report" or else "Release at board report" cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month. Sorry to butt in, but is there any hope of getting issue #44803 addressed in that timeframe? [The gap between mod_jk and mod_proxy_ajp in this and other areas (I don't believe it can set a longer packet size than 8K yet) is a bit troubling...] -- Jess Holle
2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
On Apr 13, 2008, at 3:32 AM, Justin Erenkrantz wrote: On Sat, Apr 12, 2008 at 9:52 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote: My proposal is for every 2 months, we do a release of the main stable branch, which at this time is 2.2.x. I would like to go for 3 month, so four times per year or once each quarter. I think it's a good idea - except I think 2 months is a little too frequent as well. That means 1 week out of every 8 that we're spending checking and testing the release. 1 out of 12 weeks eases it a bit...so +1 for every three months. -- justin Plus, every 3 months would coincide with the report-to-board cycle, making it easier for everyone to follow :) Next is due in May, so if we release this month, then we can follow a "Release before the board report" or else "Release at board report" cycle (with the caveat I noted before ;) ) As noted (and as I pinged a few people about in Amsterdam), I'm looking to push for a 2.2.9 soon. We have enough for sure warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on, but I do not want 2.2.9 to hold off too long for that... So I'd like to propose 2.2.9 for the end of this month.
Re: [PROPOSAL] Time Based Releases
On Apr 12, 2008, at 1:20 PM, Paul Querna wrote:
This is something I have been thinking about for awhile, and
discussed with a few other http server people before.
I think that for the 'stable' branch, we should move to time based
releases.
My proposal is for every 2 months, we do a release of the main
stable branch, which at this time is 2.2.x.
I also volunteer to be the Release Manager for the first couple
releases, assuming no one else really wants to do them :-)
Thoughts?
As the person who's been pushing the last several releases out, I'm
+1 on having a set schedule, assuming, of course, that we aren't holding
ourselves to it ("it's done when it's done" after all), and I'm still
planning on calling for a 2.2.9 release soon and will continue to
offer to RM.
Re: [PROPOSAL] Time Based Releases
On Sat, 12 Apr 2008, Paul Querna wrote:
This is something I have been thinking about for awhile, and discussed with a
few other http server people before.
I think that for the 'stable' branch, we should move to time based releases.
Sounds sane. Even though there might only be small bugfixes it's a
good thing to release rather often to reduce the risk of having so
many new fixes and features that we trigger some weird bug in each
release that makes it unusable.
I suspect that this should really affect APR too since we have
examples of bugs that's fixed in APR trunk (or newer releases), an
example would be that for httpd 2.2.8 the included APR is broken wrt
bucket brigades and LFS on 32bit platforms...
My proposal is for every 2 months, we do a release of the main stable branch,
which at this time is 2.2.x.
+1, including the concerns that 3 months might be a more suitable goal
for releases (meaning that tagging 2 months after the last release
seems reasonable :) and that we should not write this in stone but
be flexible when needed.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---
I'd love to, but I'm too young for that stuff.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [PROPOSAL] Time Based Releases
On Apr 13, 2008, at 11:05 AM, Lars Eilebrecht wrote: According to Paul: My proposal is for every 2 months, we do a release of the main stable branch, which at this time is 2.2.x. +1 on the concept, but in my opinion 2 month is too short. 3-4 month would be better. If two months is too short for some folks, I recommend you test every other release instead of every one -- there's no sense slowing us down if we have plenty of folks capable of testing any given release. If it really turns out to be too short, we just won't have enough +1s. Roy
Re: [PROPOSAL] Time Based Releases
According to Paul: > My proposal is for every 2 months, we do a release of the main stable > branch, which at this time is 2.2.x. +1 on the concept, but in my opinion 2 month is too short. 3-4 month would be better. ciao... -- Lars Eilebrecht [EMAIL PROTECTED]
Re: [PROPOSAL] Time Based Releases
On Sat, Apr 12, 2008 at 9:52 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote: > > My proposal is for every 2 months, we do a release of the main stable > branch, which at this time is 2.2.x. > > > > I would like to go for 3 month, so four times per year or once each > quarter. I think it's a good idea - except I think 2 months is a little too frequent as well. That means 1 week out of every 8 that we're spending checking and testing the release. 1 out of 12 weeks eases it a bit...so +1 for every three months. -- justin
Re: [PROPOSAL] Time Based Releases
Roy T. Fielding wrote: On Apr 12, 2008, at 7:20 PM, Paul Querna wrote: This is something I have been thinking about for awhile, and discussed with a few other http server people before. I think that for the 'stable' branch, we should move to time based releases. My proposal is for every 2 months, we do a release of the main stable branch, which at this time is 2.2.x. Assuming you mean time-based build-a-package and vote-on-it-to-release, then +1. Yes. And TBH, I think this will end up with me putting it in my iCal to remind myself to start a release cycle attempt, and if anyone else helps out, that would be a nice bonus. -Paul
Re: [PROPOSAL] Time Based Releases
On Apr 12, 2008, at 7:20 PM, Paul Querna wrote: This is something I have been thinking about for awhile, and discussed with a few other http server people before. I think that for the 'stable' branch, we should move to time based releases. My proposal is for every 2 months, we do a release of the main stable branch, which at this time is 2.2.x. Assuming you mean time-based build-a-package and vote-on-it-to- release, then +1. Roy
Re: [PROPOSAL] Time Based Releases
On 04/12/2008 07:20 PM, Paul Querna wrote: This is something I have been thinking about for awhile, and discussed with a few other http server people before. I think that for the 'stable' branch, we should move to time based releases. I like this if it is seen as some kind of reminder that we really should do a new release. But I would not like to see the timeframe written into stone. It should be possible to - postpone the release if we can't finish up an important patch at this time which should be included in the next release (e.g. a regression) or if we need to wait for an apr / apr-util release which might need / should also follow this schedule then. So quality before rush. - skip a release if there are only very few and not important patches (whatever this means could be subject to an interesting discussion :-), but at least for the number of changes I tend to say <= 3). It lowers the pain for (most) of our users and us, because a release always creates work. My proposal is for every 2 months, we do a release of the main stable branch, which at this time is 2.2.x. I would like to go for 3 month, so four times per year or once each quarter. Security Issues of great importance of course would trigger an immediate release. Depending on the nearness to a scheduled release, we may or may not scrap the next time based release. Sure. Regards Rüdiger
Re: [PROPOSAL] Time Based Releases
* Paul Querna wrote:
> This is something I have been thinking about for awhile, and discussed
> with a few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based
> releases.
This would be the place for ", because [...]" ;-)
So, what problem are you trying to solve?
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord( # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
