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: 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)
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)
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)
-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: -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)
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)
-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)
-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)
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)
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 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)
-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 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)
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)
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)
-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)
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)
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: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)
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: 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
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)
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...
