Re: FYI: Looking for a release of 2.4.x soonish
Hi, Is there any update on this? What is the status of https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c1 ? Will the UDS patch make it into this release? Thanks, Yonah On Wed, Jun 25, 2014 at 1:05 AM, Yann Ylavic ylavic@gmail.com wrote: On Tue, Jun 24, 2014 at 8:40 PM, Jim Jagielski j...@jagunet.com wrote: I'm hoping to encourage us to push out the next 2.4 release within the next coupla weeks, maybe after the July 4th US-based holiday. Comments? +1, thanks!
Re: FYI: Looking for a release of 2.4.x soonish
UDS have been supported since 2.4.8, see https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c21 On 08.07.2014, at 11:22, Yonah Russ yonah.r...@gmail.com wrote: Hi, Is there any update on this? What is the status of https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c1 ? Will the UDS patch make it into this release? Thanks, Yonah On Wed, Jun 25, 2014 at 1:05 AM, Yann Ylavic ylavic@gmail.com wrote: On Tue, Jun 24, 2014 at 8:40 PM, Jim Jagielski j...@jagunet.com wrote: I'm hoping to encourage us to push out the next 2.4 release within the next coupla weeks, maybe after the July 4th US-based holiday. Comments? +1, thanks!
Re: svn commit: r1608703 - /httpd/httpd/trunk/server/listen.c
On Tue, Jul 8, 2014 at 11:42 AM, jkal...@apache.org wrote:
@@ -279,8 +279,35 @@ static apr_status_t close_listeners_on_e
#ifdef HAVE_SYSTEMD
+static int find_systemd_socket(process_rec * process, apr_port_t port) {
+int fdcount, fd;
+int sdc = sd_listen_fds(0);
+
+if (sdc 0) {
+ap_log_perror(APLOG_MARK, APLOG_CRIT, sdc, process-pool,
APLOGNO(02486)
+ find_systemd_socket: Error parsing enviroment,
sd_listen_fds returned %d,
+ sdc);
+return 1;
+}
+
+if (sdc == 0) {
+ap_log_perror(APLOG_MARK, APLOG_CRIT, sdc, process-pool,
APLOGNO(02487)
+ find_systemd_socket: At least one socket must be
set.);
+return 1;
+}
Shouldn't these returns be -1?
Re: svn commit: r1608703 - /httpd/httpd/trunk/server/listen.c
On 07/08/2014 02:00 PM, Yann Ylavic wrote:
On Tue, Jul 8, 2014 at 11:42 AM, jkal...@apache.org wrote:
@@ -279,8 +279,35 @@ static apr_status_t close_listeners_on_e
#ifdef HAVE_SYSTEMD
+static int find_systemd_socket(process_rec * process, apr_port_t port) {
+int fdcount, fd;
+int sdc = sd_listen_fds(0);
+
+if (sdc 0) {
+ap_log_perror(APLOG_MARK, APLOG_CRIT, sdc, process-pool,
APLOGNO(02486)
+ find_systemd_socket: Error parsing enviroment, sd_listen_fds
returned %d,
+ sdc);
+return 1;
+}
+
+if (sdc == 0) {
+ap_log_perror(APLOG_MARK, APLOG_CRIT, sdc, process-pool,
APLOGNO(02487)
+ find_systemd_socket: At least one socket must be set.);
+return 1;
+}
Shouldn't these returns be -1?
Yes, good catch, thanks. Fixed in r1608744.
Jan Kaluza
Re: FYI: Looking for a release of 2.4.x soonish
Thanks for clarifying, I saw the comment but it didn't seem very authoritative. Also, since the bug says fixed in trunk, patch available- it was not really clear (at least to me) that the fix had been released. Also there is no mention of the support in the mod_proxy_fcgi docs. I just thought now to check the mod_proxy docs and even there, the documentation for use with mod_proxy_fcgi is at the level of comments. I guess it is sort of mentioned in the 2.4.9 change log but I missed it because it is listed as 2.4.8 change and 2.4.8 wasn't released. Anyway- I look forward to trying it out. Thanks again, Yonah On Tue, Jul 8, 2014 at 2:30 PM, David Zuelke d...@heroku.com wrote: UDS have been supported since 2.4.8, see https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c21 On 08.07.2014, at 11:22, Yonah Russ yonah.r...@gmail.com wrote: Hi, Is there any update on this? What is the status of https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c1 ? Will the UDS patch make it into this release? Thanks, Yonah On Wed, Jun 25, 2014 at 1:05 AM, Yann Ylavic ylavic@gmail.com wrote: On Tue, Jun 24, 2014 at 8:40 PM, Jim Jagielski j...@jagunet.com wrote: I'm hoping to encourage us to push out the next 2.4 release within the next coupla weeks, maybe after the July 4th US-based holiday. Comments? +1, thanks!
Re: FYI: Looking for a release of 2.4.x soonish
On Tue, Jun 24, 2014 at 2:40 PM, Jim Jagielski j...@jagunet.com wrote: I'm hoping to encourage us to push out the next 2.4 release within the next coupla weeks, maybe after the July 4th US-based holiday. Comments? What's the current guestimate? Thanks! -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: svn commit: r1606368 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/winnt/child.c
On Sat, Jun 28, 2014 at 11:01 AM, traw...@apache.org wrote:
@@ -1126,6 +1136,7 @@ void child_main(apr_pool_t *pconf, DWORD
rv = WaitForMultipleObjects(num_events, (HANDLE *)child_events,
FALSE, INFINITE);
cld = rv - WAIT_OBJECT_0;
#else
+/* THIS IS THE EXPECTED BUILD VARIATION */
rv = WaitForMultipleObjects(num_events, (HANDLE *)child_events,
FALSE, 1000);
cld = rv - WAIT_OBJECT_0;
if (rv == WAIT_TIMEOUT) {
Was reviewing for 2.4, what does the comment mean?
--
Eric Covener
cove...@gmail.com
Re: svn commit: r1606368 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/winnt/child.c
On Tue, Jul 8, 2014 at 9:46 AM, Eric Covener cove...@gmail.com wrote:
On Sat, Jun 28, 2014 at 11:01 AM, traw...@apache.org wrote:
@@ -1126,6 +1136,7 @@ void child_main(apr_pool_t *pconf, DWORD
rv = WaitForMultipleObjects(num_events, (HANDLE *)child_events,
FALSE, INFINITE);
cld = rv - WAIT_OBJECT_0;
#else
+/* THIS IS THE EXPECTED BUILD VARIATION */
rv = WaitForMultipleObjects(num_events, (HANDLE *)child_events,
FALSE, 1000);
cld = rv - WAIT_OBJECT_0;
if (rv == WAIT_TIMEOUT) {
Was reviewing for 2.4, what does the comment mean?
--
Eric Covener
cove...@gmail.com
Sorry :)
That #else right before it is part of
#if !APR_HAS_OTHER_CHILD
...
#else
/* THIS IS THE EXPECTED BUILD VARIATION */
...
#endif
and I always forget which is the normal path on Windows.
Does r1608785 help???
(Wow, researching why my first two attempts to reply here failed really
pisses me off. A domain listed in my sig is listed in the Spamhaus
database, and it appears that I have to change my mail configuration for
that domain just to be able to submit a request to remove it :( )
Re: svn commit: r1606368 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/winnt/child.c
On Tue, Jul 8, 2014 at 10:27 AM, Jeff Trawick traw...@gmail.com wrote: Does r1608785 help??? yep, thanks -- Eric Covener cove...@gmail.com
mod_ssl server certificate does NOT include an ID which matches the server name
We have an external load balancer handling client-facing SSL sessions, and Apache httpd uses a single x509 cert for receiving traffic from those load balancers. As such, the Host field in the received content does not match the CN in the certificate the load balancers see when contacting mod_ssl. It does match the hostname the load balancers use to talk to mod_ssl. Everything works correctly, just we get a lot of this warning: mod_ssl server certificate does NOT include an ID which matches the server name I didn't see an existing way to disable this without also dropping another chunk of potentially useful logs. Personally, I think info level might have been a bit more appropriate, anyhow. My proposed solution is a new configuration flag to suppress this warning. There would be no behavior change in the default case. I was thinking something like SSLSupressCNMissmatch (yes, it's ugly) or SSLExternalProxy (in case there are other, future things that should also work at this level). Any suggestions on alternate directive names, different approaches, etc? Should the log threshold on that message stay warn, or move to info? Ideally, I wouldn't be applying a patch to our sources for the next several years. If such a configuration option isn't desired by the community, I'll just comment out the warning in our builds and be done with it. So, that would also be helpful feedback. Thanks in advance for any feedback, Rick Houser PGDS Web Administration (517)367-3516
Re: FYI: Looking for a release of 2.4.x soonish
Anytime... we could do it this week if we wanted... On Jul 8, 2014, at 9:43 AM, Jeff Trawick traw...@gmail.com wrote: On Tue, Jun 24, 2014 at 2:40 PM, Jim Jagielski j...@jagunet.com wrote: I'm hoping to encourage us to push out the next 2.4 release within the next coupla weeks, maybe after the July 4th US-based holiday. Comments? What's the current guestimate? Thanks! -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: Looking for a release of 2.4.x soonish
On 6/24/14 12:35 PM, Bert Huijben wrote: I would really like to see the mod_dav escaping fixes (where breser is looking at) to be backported for this next release. Without those patches Subversion doesn't properly support some special characters inside repository paths. (Regression against 2.0.x, 2.2.x and earlier 2.4.x versions). As soon as these are backported: +2 :-) Nominated if people can vote for them.
Re: svn commit: r1608762 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/proxy/proxy_util.c
Le 08/07/2014 15:16, j...@apache.org a écrit :
Author: jim
Date: Tue Jul 8 13:16:27 2014
New Revision: 1608762
URL: http://svn.apache.org/r1608762
Log:
Merge r1588519 from trunk:
mod_proxy: When ping/pong is configured for a worker, don't send or forward
100 Continue (interim) response to the client if it does not
expect one.
Submitted by: ylavic
Reviewed/backported by: jim
Modified:
httpd/httpd/branches/2.4.x/ (props changed)
httpd/httpd/branches/2.4.x/CHANGES
httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c
Propchange: httpd/httpd/branches/2.4.x/
--
Merged /httpd/httpd/trunk:r1588519
Modified: httpd/httpd/branches/2.4.x/CHANGES
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1608762r1=1608761r2=1608762view=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Tue Jul 8 13:16:27 2014
@@ -2,6 +2,10 @@
Changes with Apache 2.4.10
+ *) mod_proxy: When ping/pong is configured for a worker, don't send or
+ forward 100 Continue (interim) response to the client if it does
+ not expect one. [Yann Ylavic]
+
*) mod_proxy_fcgi: Fix occasional high CPU when handling request bodies.
[Jeff Trawick]
Modified: httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c?rev=1608762r1=1608761r2=1608762view=diff
==
--- httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c Tue Jul 8 13:16:27
2014
@@ -3307,8 +3307,22 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbr
* to backend
*/
if (do_100_continue) {
-apr_table_mergen(r-headers_in, Expect, 100-Continue);
-r-expecting_100 = 1;
+const char *val;
+
+if (!r-expecting_100) {
+/* Don't forward any 100 Continue response if the client is
+ * not expecting it.
+ */
+apr_table_setn(r-subprocess_env, proxy-interim-response,
+ Suppress);
+}
+
+/* Add the Expect header if not already there. */
+if (((val = apr_table_get(r-headers_in, Expect)) == NULL)
+|| (strcasecmp(val, 100-Continue) != 0 // fast path
+ !ap_find_token(r-pool, val, 100-Continue))) {
+apr_table_mergen(r-headers_in, Expect, 100-Continue);
+}
}
/* X-Forwarded-*: handling
Just a few details :
1) Shouldn't we use 100-continue (lowercase c) instead, to more
closely match http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html, §
8.2.3 ?
This would also be consistent with the use of this string in
protocol.c
2) if of any use, in the fast path, strcmp could be used instead of
strcasecmp
3) // fast path, should be /* fast path */
4) in protocol.c, around line 1212 there is:
if (((expect = apr_table_get(r-headers_in, Expect)) != NULL)
(expect[0] != '\0')) {
/*
* The Expect header field was added to HTTP/1.1 after RFC 2068
* as a means to signal when a 100 response is desired and,
* unfortunately, to signal a poor man's mandatory extension that
* the server must understand or return 417 Expectation Failed.
*/
if (strcasecmp(expect, 100-continue) == 0) {
r-expecting_100 = 1;
}
this is not consistent with the code below. Should this be changed to
something like:
if (strcasecmp(expect, 100-continue) == 0 ||
ap_find_token(r-pool, expect, 100-Continue)) {
r-expecting_100 = 1;
}
?
Best regards,
CJ
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.com
