Test framework vs IPv6

[Yann Ylavic]

On my machine (Debian 9/testing, Linux 4.4), both "t/protocol/echo.t"
and "t/security/CVE-2009-3555.t" fail with:
 Connect failed: ; Connection refused at
/home/yle/src/apache/asf/httpd/test/framework/trunk/Apache-Test/lib/Apache/TestRequest.pm
line 297.
 Dubious, test returned 111 (wstat 28416, 0x6f00)

This appears to be due to Perl trying to connect to ::1 (IPv6, as
shown by tcpdump) and failing because httpd Listen-s on 0.0.0.0 (IPv4)
only.
Some other tests do the same (I did not captured all, though) but
somehow they don't fail...

Anyway, I tried to address this by Listen-ing on the port only (hence
any v4 or v6 address), using the attached patch, and indeed the two
tests pass (I first tried to disable IPv6 on my system and that worked
too).
However, there are even more tests failing now...

Anyone ever had this issue?
Why is (our) Perl connecting localhost with IPv6?
Any idea on how to avoid that?

Regards,
Yann.
Index: Apache-Test/lib/Apache/TestConfig.pm
===
--- Apache-Test/lib/Apache/TestConfig.pm	(revision 1735819)
+++ Apache-Test/lib/Apache/TestConfig.pm	(working copy)
@@ -1238,7 +1238,8 @@ sub parse_vhost {
 my @out_config = ();
 if ($self->{vhosts}->{$module}->{namebased} < 2) {
 #extra config that should go *outside* the 
-@out_config = ([Listen => '0.0.0.0:' . $port]);
+#@out_config = ([Listen => '0.0.0.0:' . $port]);
+@out_config = ([Listen => $port]);
 
 if ($self->{vhosts}->{$module}->{namebased}) {
 push @out_config => ["\n".
@@ -2139,7 +2140,8 @@ perl(1), Apache::Test(3)
 
 
 __DATA__
-Listen 0.0.0.0:@Port@
+#Listen 0.0.0.0:@Port@
+Listen @Port@
 
 ServerRoot   "@ServerRoot@"
 DocumentRoot "@DocumentRoot@"
Index: Apache-Test/lib/Apache/TestConfigPerl.pm
===
--- Apache-Test/lib/Apache/TestConfigPerl.pm	(revision 1735819)
+++ Apache-Test/lib/Apache/TestConfigPerl.pm	(working copy)
@@ -270,7 +270,8 @@ sub set_connection_handler {
 my($self, $module, $args) = @_;
 my $port = $self->new_vhost($module);
 my $vars = $self->{vars};
-$self->postamble(Listen => '0.0.0.0:' . $port);
+#$self->postamble(Listen => '0.0.0.0:' . $port);
+$self->postamble(Listen => $port);
 }
 
 my %add_hook_config = (

Re: mod_proxy_hcheck review..

[Yann Ylavic]

On Sat, Mar 19, 2016 at 10:05 PM, Yann Ylavic  wrote:
> The proposed backport patch (v2) does not contain mod_proxy_hcheck.c
> itself, so I took the one from trunk, easy enough :)

My bad, I simply forgot to "svn add" before reviewing "svn diff"...

mod_proxy_hcheck review..

[Yann Ylavic]

The proposed backport patch (v2) does not contain mod_proxy_hcheck.c
itself, so I took the one from trunk, easy enough :)
The (recent) changes around the call to
[ap_proxy_]is_socket_connected() in ap_proxy_connect_backend()) broke
the patch too (minor change).

Regarding the implementation, IIUC, there is a scheduled hc thread per
BalancerMember, each running hc_check().
The threads are somehow run one child at a time, thanks to
mod_watchdog, but I'm not too familiar with it, so I may have
overlooked that...

However, it seems that there are some paths where the worker threads
can allocate on (or use) the server config pool (ctx->p, a subpool of
pconf).
This (AFAICT) concerns hc_get_hcworker(), hc_determine_connection(),
hc_get_backend() (where backend->p == ctx->p ??) and hc_check_http().
Shouldn't we either use a lock or create a subpool there?
Or maybe use ptemp but it looks more like a thread pool, whereas
ctx->p usages seem more related to process wide initialization (once?
via balancer-manager only?)...

Thanks for clarifiying.

Anyway, this is really cool stuff!

Regards,
Yann.

Re: TLS session ticket key (shared) renewal

[Rainer Jung]

Am 18.03.2016 um 15:01 schrieb Yann Ylavic:

On Fri, Mar 18, 2016 at 2:55 PM, Yann Ylavic  wrote:

Currently this can be done by using a (shared) SSLSessionTicketKeyFile
and gracefuly restarting httpd instances, but there is room for
improvements here.

Thoughts?


For the single httpd instance case at least, I'm thinking of
SSLSessionTicketKeyTimeout which could be used for renewing the
key(s), without the need for a scheduled restart.
The key(s) would have to be stored/sync-ed in a SHM (or slotmem)...


Would that mean, that at the points of time of key renewal all old 
tickets immediately loose their validity? In that case you would have a 
regular bump in negotation rates. It would be nice, if one older 
generation of keys would still work for a little time, so some overlap. 
I haven't checked how to do that though.


Any idea about a scheme how to renew the keys between nodes in a farm in 
a synced way? Finding a common point in time to renew would not be the 
problem (assuming synced clocks), but how the regenerate keys 
deterministically starting from one common secret (the 
SSLSessionTicketKeyFile) without ending with keys which are too weak?


Regards,

Rainer

Re: Plan for T of 2.4.19

[fabien]

Hello Yann,


https://svn.apache.org/viewvc?view=revision=1734412


Sounds reasonable, would you add an entry in the STATUS file (at the
root of branches/2.4.x) to start the vote (with your own)?


Ok. I did that as r1735616.

--
Fabien.

Re: Feedback needed: suexec different-owner patch

[Jim Jagielski]

I promise to look deeply into this post 2.4.19 release.

> On Mar 19, 2016, at 1:09 PM, montt...@heavyspace.ca wrote:
> 
> Since its been a while since this issue was mentioned, this patch allows 
> Apache to suexec files by a different (but still restricted by UID) owner, to 
> avoid the security issue where apache forces you to suexec to files it has 
> full chmod access to.
> 
>  Original Message 
> Subject: suexec different-owner patch
> Date: 2016-03-04 18:33
> From: montt...@heavyspace.ca
> To: dev@httpd.apache.org
> Reply-To: dev@httpd.apache.org
> 
> Here is my first try at a patch for my suggestion, modified from httpd 
> 2.2.31.  It works to my satisfaction, able to switch to a UID other than the 
> file's owner, while still strictly matching the UID and GID of the file 
> against known values.  I make no guarantees of correctness or bug-freeness 
> however.  The changes are so simple though, I hope there's nothing flagrantly 
> wrong.
> 
> It uses another option, "SuexecFileGroup", which independently defines the 
> specific user and group the file must belong to.  If you don't define it, it 
> defaults to the old behavior.  I re-used suexec's own sanity checking on the 
> new option where it seemed appropriate.
> 
> Criticisms, please?

TLS session ticket key (shared) renewal

[Yann Ylavic]

Currently this can be done by using a (shared) SSLSessionTicketKeyFile
and gracefuly restarting httpd instances, but there is room for
improvements here.

Thoughts?

Re: svn commit: r1735176 - in /httpd/httpd/trunk: CHANGES modules/http/http_core.c

[Ruediger Pluem]

Weird. It works fine for me again by just reverting r1735176.

Regards

Rüdiger

On 03/16/2016 11:52 AM, Stefan Eissing wrote:
> Reverting that change, it still does not handle h1. Digging...
> 
>> Am 16.03.2016 um 11:47 schrieb Stefan Eissing :
>>
>> Only HTTP/2 connections seem to work right now.
>>
>> I mean, it's hard for me to complain, but that seems a bit much...
>>
>>> Am 16.03.2016 um 10:29 schrieb Ruediger Pluem :
>>>
>>>
>>>
>>> On 03/16/2016 12:13 AM, minf...@apache.org wrote:
 Author: minfrin
 Date: Tue Mar 15 23:13:43 2016
 New Revision: 1735176

 URL: http://svn.apache.org/viewvc?rev=1735176=rev
 Log:
 mod_http: Make sure HTTP filters are added on HTTP requests only.

 Modified:
   httpd/httpd/trunk/CHANGES
   httpd/httpd/trunk/modules/http/http_core.c
>>>
>>> With this change in the test suite doesn't even start any longer but 
>>> directly stalls.
>>>
>>> Regards
>>>
>>> Rüdiger
>>>
>>
> 
> 

Re: Bug with "SetHandler None"

[Michael Kaufmann]

Eric Covener wrote:

On Sat, Mar 19, 2016 at 11:31 AM, Michael Kaufmann
 wrote:

I have found a bug in the current 2.4.x branch: "SetHandler None" does not
work anymore (note the capital letter "N"). This worked with Apache 2.4.18.
Probably this commit has changed the behavior:
http://svn.apache.org/r1729876

Thanks Michael!



Thank you for fixing the bug! :-)

Re: Feedback needed: suexec different-owner patch

[Tim Bannister]

On 19 March 2016, montt...@heavyspace.ca wrote:
>Since its been a while since this issue was mentioned, this patch
>allows 
>Apache to suexec files by a different (but still restricted by UID) 
>owner, to avoid the security issue where apache forces you to suexec to
>files it has full chmod access to.


That patch builds on what I'd consider as a legacy feature. I have not used 
suexec for a long time: it is risky, and on the one recent-ish occasion when I 
wanted something like suexec, I also wanted to chroot() / jail() / otherwise 
separate the CGI application from the main system.

httpd's users do sometimes need to have web content served using processes that 
have different privileges to httpd, and perhaps are also isolated from one 
another. suexec achieves some of this albeit not well.
It feels to me as if some kind of FastCGI process manager, combined with a 
privileged helper, could be used to fill the gap that mpm_itk and suexec don't 
completely cover.

I'll add to my To Do list (and maybe also Bugzilla) a task to see what already 
exists and document how to use that in place of suexec.
If nothing out there already works, then my idea is to code that up as well.

I wish I could say when I might get round to that, but the way if these things 
is that it's easy to start this kind of task and rather more difficult to 
complete them.

As to whether to take the suggested patch: +0. I don't think it will make 
things worse; however, I don't feel qualified to comment on security-critical 
code.

Tim


-- 
Tim Bannister – is...@c8h10n4o2.org.uk

Feedback needed: suexec different-owner patch

[monttyle]

Since its been a while since this issue was mentioned, this patch allows 
Apache to suexec files by a different (but still restricted by UID) 
owner, to avoid the security issue where apache forces you to suexec to 
files it has full chmod access to.


 Original Message 
Subject: suexec different-owner patch
Date: 2016-03-04 18:33
From: montt...@heavyspace.ca
To: dev@httpd.apache.org
Reply-To: dev@httpd.apache.org

Here is my first try at a patch for my suggestion, modified from httpd 
2.2.31.  It works to my satisfaction, able to switch to a UID other than 
the file's owner, while still strictly matching the UID and GID of the 
file against known values.  I make no guarantees of correctness or 
bug-freeness however.  The changes are so simple though, I hope there's 
nothing flagrantly wrong.


It uses another option, "SuexecFileGroup", which independently defines 
the specific user and group the file must belong to.  If you don't 
define it, it defaults to the old behavior.  I re-used suexec's own 
sanity checking on the new option where it seemed appropriate.


Criticisms, please?

specialsuexec.patch.gz
Description: GNU Zip compressed data

Re: Bug with "SetHandler None"

[Eric Covener]

committed and proposed, was just getting these myself.

On Sat, Mar 19, 2016 at 12:44 PM, Yann Ylavic  wrote:
> On Sat, Mar 19, 2016 at 5:37 PM, Eric Covener  wrote:
>>> The bigger question is whether or not 'none' should be case insensitive
>>> or not. IMHO, it should be.
>>
>> yup. Looking now too.
>
> We probably need something like this:
>
> Index: server/core.c
> ===
> --- server/core.c(revision 1735784)
> +++ server/core.c(working copy)
> @@ -4453,16 +4453,14 @@ static int core_override_type(request_rec *r)
>"Can't evaluate handler expression: %s", err);
>  return HTTP_INTERNAL_SERVER_ERROR;
>  }
> +if (val != ap_strstr_c(val, "proxy:unix")) {
> +/* Retained for compatibility --  but not for UDS */
> +char *tmp = apr_pstrdup(r->pool, val);
> +ap_str_tolower(tmp);
> +val = tmp;
> +}
>  if (strcmp(val, "none")) {
> -if (val != ap_strstr_c(val, "proxy:unix")) {
> -/* Retained for compatibility --  but not for UDS */
> -char *tmp = apr_pstrdup(r->pool, val);
> -ap_str_tolower(tmp);
> -r->handler = tmp;
> -}
> -else {
> -r->handler = val;
> -}
> +r->handler = val;
>  }
>  }
>  else if (conf->handler && strcmp(conf->handler, "none")) {
>
> --



-- 
Eric Covener
cove...@gmail.com

Re: Bug with "SetHandler None"

[Eric Covener]

On Sat, Mar 19, 2016 at 11:31 AM, Michael Kaufmann
 wrote:
> I have found a bug in the current 2.4.x branch: "SetHandler None" does not
> work anymore (note the capital letter "N"). This worked with Apache 2.4.18.
> Probably this commit has changed the behavior:
> http://svn.apache.org/r1729876

Thanks Michael!

-- 
Eric Covener
cove...@gmail.com

Re: Bug with "SetHandler None"

[Yann Ylavic]

On Sat, Mar 19, 2016 at 5:37 PM, Eric Covener  wrote:
>> The bigger question is whether or not 'none' should be case insensitive
>> or not. IMHO, it should be.
>
> yup. Looking now too.

We probably need something like this:

Index: server/core.c
===
--- server/core.c(revision 1735784)
+++ server/core.c(working copy)
@@ -4453,16 +4453,14 @@ static int core_override_type(request_rec *r)
   "Can't evaluate handler expression: %s", err);
 return HTTP_INTERNAL_SERVER_ERROR;
 }
+if (val != ap_strstr_c(val, "proxy:unix")) {
+/* Retained for compatibility --  but not for UDS */
+char *tmp = apr_pstrdup(r->pool, val);
+ap_str_tolower(tmp);
+val = tmp;
+}
 if (strcmp(val, "none")) {
-if (val != ap_strstr_c(val, "proxy:unix")) {
-/* Retained for compatibility --  but not for UDS */
-char *tmp = apr_pstrdup(r->pool, val);
-ap_str_tolower(tmp);
-r->handler = tmp;
-}
-else {
-r->handler = val;
-}
+r->handler = val;
 }
 }
 else if (conf->handler && strcmp(conf->handler, "none")) {

--

Re: Bug with "SetHandler None"

[Eric Covener]

On Sat, Mar 19, 2016 at 12:37 PM, Eric Covener  wrote:
> yup. Looking now too.
>

I've got it

-- 
Eric Covener
cove...@gmail.com

Re: Bug with "SetHandler None"

[Eric Covener]

> The bigger question is whether or not 'none' should be case insensitive
> or not. IMHO, it should be.

yup. Looking now too.

Re: Bug with "SetHandler None"

[Jim Jagielski]

Hmmm a rough look doesn't seem to show anyplace where we
used to use strcasecmp and now use strcmp;

The bigger question is whether or not 'none' should be case insensitive
or not. IMHO, it should be.

> On Mar 19, 2016, at 11:31 AM, Michael Kaufmann  
> wrote:
> 
> Hi,
> 
> I have found a bug in the current 2.4.x branch: "SetHandler None" does not 
> work anymore (note the capital letter "N"). This worked with Apache 2.4.18. 
> Probably this commit has changed the behavior: http://svn.apache.org/r1729876
> 
> The documentation at 
> https://httpd.apache.org/docs/2.4/en/mod/core.html#sethandler is 
> inconsistent: In the syntax definition, the value "none" is used, but there 
> is also this sentence: "You can override an earlier defined SetHandler 
> directive by using the value None." So I expect that both "none" and "None" 
> should work.
> 
> Example configuration that shows the problem (the send-as-is handler is not 
> used anymore for asis files):
> 
> 
>SetHandler   None
>AddType  text/html .html .asis
>AddHandler   send-as-is html asis
> 
> 
> Regards,
> Michael

Bug with "SetHandler None"

[Michael Kaufmann]

Hi,

I have found a bug in the current 2.4.x branch: "SetHandler None" does 
not work anymore (note the capital letter "N"). This worked with Apache 
2.4.18. Probably this commit has changed the behavior: 
http://svn.apache.org/r1729876


The documentation at 
https://httpd.apache.org/docs/2.4/en/mod/core.html#sethandler is 
inconsistent: In the syntax definition, the value "none" is used, but 
there is also this sentence: "You can override an earlier defined 
SetHandler directive by using the value None." So I expect that both 
"none" and "None" should work.


Example configuration that shows the problem (the send-as-is handler is 
not used anymore for asis files):



SetHandler   None
AddType  text/html .html .asis
AddHandler   send-as-is html asis


Regards,
Michael

Re: TLS session ticket key (shared) renewal

[Yann Ylavic]

On Fri, Mar 18, 2016 at 5:54 PM, Yann Ylavic  wrote:
>
> Maybe something like the following could work, and maybe also it could
> be secure (any contradictory opinion is of course very welcome :)

Please s/PDKF2/PBKDF2/g in this previous message, too much
unpronounceable letters for me :)

httpd-trunk proxy_http2 NetWare build wants extra sym.

[NormW]

G/M,
A recent addition to trunk mod_proxy_http2 needs an additional export 
from hghttp2 lib, thus:



Index: modules/http2/NWGNUmod_http2
===
--- modules/http2/NWGNUmod_http2(revision 1735506)
+++ modules/http2/NWGNUmod_http2(working copy)
@@ -391,6 +391,7 @@
@echo $(DL) nghttp2_session_callbacks_set_send_callback,$(DL) >> $@
@echo $(DL) nghttp2_session_client_new2,$(DL) >> $@
@echo $(DL) nghttp2_session_consume,$(DL) >> $@
+   @echo $(DL) nghttp2_session_consume_connection,$(DL) >> $@
@echo $(DL) nghttp2_session_del,$(DL) >> $@
@echo $(DL) nghttp2_session_get_remote_settings,$(DL) >> $@
@echo $(DL) nghttp2_session_get_stream_user_data,$(DL) >> $@


Excuse the noise.
Norm
Index: modules/http2/NWGNUmod_http2
===
--- modules/http2/NWGNUmod_http2	(revision 1735506)
+++ modules/http2/NWGNUmod_http2	(working copy)
@@ -391,6 +391,7 @@
 	@echo $(DL) nghttp2_session_callbacks_set_send_callback,$(DL) >> $@
 	@echo $(DL) nghttp2_session_client_new2,$(DL) >> $@
 	@echo $(DL) nghttp2_session_consume,$(DL) >> $@
+	@echo $(DL) nghttp2_session_consume_connection,$(DL) >> $@
 	@echo $(DL) nghttp2_session_del,$(DL) >> $@
 	@echo $(DL) nghttp2_session_get_remote_settings,$(DL) >> $@
 	@echo $(DL) nghttp2_session_get_stream_user_data,$(DL) >> $@

Re: [PATCH] Add "FreeListen" to support IP_FREEBIND

[Jan Kaluža]

On 03/08/2016 11:43 AM, Jan Kaluža wrote:

On 03/08/2016 10:25 AM, Yann Ylavic wrote:

On Tue, Mar 8, 2016 at 9:46 AM, Yann Ylavic  wrote:

On Tue, Mar 8, 2016 at 9:28 AM, Jan Kaluža  wrote:


I have chosen FreeListen over the flags


FWIW, should be take the YAD path, I'd prefer ListenFree (over
FreeListen) to emphasize on the "Listen directive family" with a
prefix...


Thinking more about this, I think I second Jim on the wish to have a
single Listen directive with some parameter like
"options=freebind,backlog:4095,reuseport,...".


Thinking about right syntax for options...

I would personally like something like "Listen [IP-address:]portnumber
[protocol] [option1] [option2] ...". Do we have list of supported
protocols by Listen directive, or we support whatever protocol is there?

If we have explicit list of protocols, then the protocols itself could
become an options.

If not, can it be acceptable, that you always have to define protocol
when you wan to use options?


I've implemented the way described in that question above ^. Please see 
the attached patch and share your opinions.


The syntax to enable IP_FREEBIND currently is:

Listen 192.168.0.1:80 http freebind

Regards,
Jan Kaluza



Otherwise I can always implement Yann's idea with "Listen
[IP-address:]portnumber [protocol] [options=[option1,option2,...]]".

Regards,
Jan Kaluza



We could then whatever (new) IP option more easily (less docs work...)
and maybe deprecate ListenBacklog.

For example, the "reuseport" (SO_REUSEPORT) option seem to be usable
w/o the current buckets mechanism in latest linux kernels, so indeed
we may add more and more options there...





Index: docs/manual/mod/mpm_common.xml
===
--- docs/manual/mod/mpm_common.xml	(revision 1733461)
+++ docs/manual/mod/mpm_common.xml	(working copy)
@@ -171,7 +171,7 @@
 Listen
 IP addresses and ports that the server
 listens to
-Listen [IP-address:]portnumber [protocol]
+Listen [IP-address:]portnumber [protocol] [option] [...]
 server config
 eventworker
 preforkmpm_winnt
@@ -240,6 +240,17 @@
   error message.
 
 
+The optional option arguments are used to configure
+   system specific socket options:
+
+
+OptionDescription
+freebindSets the IP_FREEBIND socket option
+on systems where this option is available. It is therefore possible
+to start the server even when particular IP address set in the
+Listen directive is not configured yet.
+
+
 
 DNS Issues
 Setting which addresses and ports Apache HTTP Server
Index: include/ap_listen.h
===
--- include/ap_listen.h	(revision 1733461)
+++ include/ap_listen.h	(working copy)
@@ -38,6 +38,9 @@
 typedef struct ap_listen_rec ap_listen_rec;
 typedef apr_status_t (*accept_function)(void **csd, ap_listen_rec *lr, apr_pool_t *ptrans);
 
+/* Whether use APR_SO_FREEBIND */
+#define AP_LISTEN_FREEBIND 1
+
 /**
  * @brief Apache's listeners record.
  *
@@ -71,6 +74,10 @@
 const char* protocol;
 
 ap_slave_t *slave;
+/**
+ * Options to configure socket features.
+ */
+int options;
 };
 
 /**
@@ -149,7 +156,7 @@
 AP_INIT_TAKE1("ListenCoresBucketsRatio", ap_set_listencbratio, NULL, RSRC_CONF, \
   "Ratio between the number of CPU cores (online) and the number of listeners buckets"), \
 AP_INIT_TAKE_ARGV("Listen", ap_set_listener, NULL, RSRC_CONF, \
-  "A port number or a numeric IP address and a port number, and an optional protocol"), \
+  "A port number or a numeric IP address and a port number, an optional protocol, and options"), \
 AP_INIT_TAKE1("SendBufferSize", ap_set_send_buffer_size, NULL, RSRC_CONF, \
   "Send buffer size in bytes"), \
 AP_INIT_TAKE1("ReceiveBufferSize", ap_set_receive_buffer_size, NULL, \
Index: server/listen.c
===
--- server/listen.c	(revision 1733461)
+++ server/listen.c	(working copy)
@@ -68,7 +68,8 @@
 #endif
 
 /* TODO: make_sock is just begging and screaming for APR abstraction */
-static apr_status_t make_sock(apr_pool_t *p, ap_listen_rec *server, int do_bind_listen)
+static apr_status_t make_sock(apr_pool_t *p, ap_listen_rec *server,
+  int do_bind_listen)
 {
 apr_socket_t *s = server->sd;
 int one = 1;
@@ -162,6 +163,22 @@
 }
 #endif
 
+   if (server->options & AP_LISTEN_FREEBIND) {
+#if defined(APR_SO_FREEBIND)
+stat = apr_socket_opt_set(s, APR_SO_FREEBIND, one);
+if (stat != APR_SUCCESS) {
+ap_log_perror(APLOG_MARK, APLOG_WARNING, stat, p, APLOGNO()
+  "make_sock: failed to set set IP_FREEBIND socket option");
+return stat;
+}
+#else
+ap_log_perror(APLOG_MARK, APLOG_WARNING, stat, p, APLOGNO()
+"make_sock: 'freebind' Listen option not supported "
+   

Re: svn commit: r1735176 - in /httpd/httpd/trunk: CHANGES modules/http/http_core.c

[Graham Leggett]

On 16 Mar 2016, at 1:08 PM, Stefan Eissing  wrote:

> I needed to revert r1735174 to make HTTP/1.1 work again. I submitted this to 
> trunk since other people are affected too.
> 
> Graham: if you are unable to reproduce this and need any additional data, pls 
> let me know.

The test suite runs clean for me - when it hangs can you confirm where it is 
hanging?

Regards,
Graham
—

Re: svn commit: r1735610 - in /httpd/httpd/branches/2.4.x: ./ modules/http2/

[Marion & Christophe JAILLET]

Le 18/03/2016 15:48, ic...@apache.org a écrit :

Author: icing
Date: Fri Mar 18 14:48:36 2016
New Revision: 1735610

URL: http://svn.apache.org/viewvc?rev=1735610=rev
Log:
Merge of 1735608,1735609 from trunk:

mod_http2: stream cleanup on GOAWAY handling, PUSHes prohibited after client 
GOAWAY.


Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/modules/http2/h2.h
 httpd/httpd/branches/2.4.x/modules/http2/h2_conn_io.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_filter.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_mplx.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_mplx.h
 httpd/httpd/branches/2.4.x/modules/http2/h2_session.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_session.h
 httpd/httpd/branches/2.4.x/modules/http2/h2_version.h


Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1735610=1735609=1735610=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Fri Mar 18 14:48:36 2016
@@ -1,10 +1,7 @@
   -*- coding: utf-8 -*-
  
-Changes with Apache 2.4.19

-
-  *) mod_http2: slave connections are reused for several requests, improved
- performance and better memory use. [Stefan Eissing]
-

Is this removal intentional?

CJ


+  *) mod_http2: disabling PUSH when client sends GOAWAY.
+
*) mod_rewrite: Don't implicitly URL-escape the original query string
   when no substitution has changed it (like PR50447 but server context)
   [Evgeny Kotkov ]

Re: svn commit: r1735216 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_mpm.h include/mpm_common.h modules/proxy/mod_proxy_wstunnel.c server/mpm/event/event.c server/mpm/event/fdqueue.h

[Yann Ylavic]

On Wed, Mar 16, 2016 at 12:06 PM,   wrote:
> Author: icing
> Date: Wed Mar 16 11:06:28 2016
> New Revision: 1735216
>
> URL: http://svn.apache.org/viewvc?rev=1735216=rev
> Log:
> reverting r1735174 as http/1.1 just terminated before response

Hmm, not sure to understand.
Didn't you mean to revert r1735176 instead?

Re: svn commit: r1735216 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_mpm.h include/mpm_common.h modules/proxy/mod_proxy_wstunnel.c server/mpm/event/event.c server/mpm/event/fdqueue.h

[Stefan Eissing]

Testing again to verify...

> Am 16.03.2016 um 13:15 schrieb Yann Ylavic :
> 
> On Wed, Mar 16, 2016 at 12:06 PM,   wrote:
>> Author: icing
>> Date: Wed Mar 16 11:06:28 2016
>> New Revision: 1735216
>> 
>> URL: http://svn.apache.org/viewvc?rev=1735216=rev
>> Log:
>> reverting r1735174 as http/1.1 just terminated before response
> 
> Hmm, not sure to understand.
> Didn't you mean to revert r1735176 instead?

Plan for T of 2.4.19

[Jim Jagielski]

I hope to T 2.4.19 on Mon/Tues with a release on Friday.

There are some backports proposed that would be nice to get
into this release, otherwise I am shooting for a quick release
also around the ACNA time-frame.

Re: svn commit: r1735176 - in /httpd/httpd/trunk: CHANGES modules/http/http_core.c

[Stefan Eissing]

Same on OS X 15.3 as well as my Ubuntu 14.04 image

> Am 16.03.2016 um 13:06 schrieb Stefan Eissing :
> 
> What I see here on a single process server (-X) for simplicity:
> 
> [Wed Mar 16 12:00:25.191155 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> [Wed Mar 16 12:00:26.218216 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> [Wed Mar 16 12:00:27.240436 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> [Wed Mar 16 12:00:28.267453 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> [Wed Mar 16 12:00:29.283653 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> [Wed Mar 16 12:00:30.286473 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 1 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> [Wed Mar 16 12:00:31.306868 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 1 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> [Wed Mar 16 12:00:32.331939 2016] [mpm_event:trace6] [pid 95897:tid 
> 123145323229184] event.c(1779): connections: 1 (clogged: 0 write-completion: 
> 0 keep-alive: 0 lingering: 0 suspended: 0)
> 
> when I connect via curl, but no response comes back:
> 12:59:58 delight:~/projects/httpd/test/mod_h2/trunk> 
> /opt/apache-trunk/bin/curl -vvv http://test.example.org:12345
> * Rebuilt URL to: http://test.example.org:12345/
> *   Trying 127.0.0.1...
> * Connected to test.example.org (127.0.0.1) port 12345 (#0)
>> GET / HTTP/1.1
>> Host: test.example.org:12345
>> User-Agent: curl/7.47.1
>> Accept: */*
>> 
> ^C
> 
> A direct HTTP/2 connection via nghttp works:
> 
> Wed Mar 16 12:02:31.967934 2016] [core:trace6] [pid 95897:tid 
> 123145310887936] util_filter.c(801): [client 127.0.0.1:58729] reinstate empty 
> brigade to full brigade in 'core' output filter
> [Wed Mar 16 12:02:31.967954 2016] [core:trace6] [pid 95897:tid 
> 123145310887936] util_filter.c(884): [client 127.0.0.1:58729] will flush 
> because of FLUSH bucket
> [Wed Mar 16 12:02:31.967959 2016] [core:trace8] [pid 95897:tid 
> 123145310887936] util_filter.c(886): [client 127.0.0.1:58729] seen in brigade 
> so far: bytes: 37, non-file bytes: 37, eor buckets: 0, morphing buckets: 0
> [Wed Mar 16 12:02:31.967964 2016] [core:trace8] [pid 95897:tid 
> 123145310887936] util_filter.c(910): [client 127.0.0.1:58729] brigade 
> contains: bytes: 0, non-file bytes: 0, eor buckets: 0, morphing buckets: 0
> [Wed Mar 16 12:02:31.967980 2016] [core:trace8] [pid 95897:tid 
> 123145310887936] core_filters.c(446): [client 127.0.0.1:58729] flushing now
> [Wed Mar 16 12:02:31.967964 2016] [http:trace4] [pid 95897:tid 
> 123145302839296] http_request.c(398): [client 127.0.0.1:58729] Headers 
> received from client:
> [Wed Mar 16 12:02:31.967998 2016] [http:trace4] [pid 95897:tid 
> 123145302839296] http_request.c(401): [client 127.0.0.1:58729]   Accept: */*
> [Wed Mar 16 12:02:31.968009 2016] [http:trace4] [pid 95897:tid 
> 123145302839296] http_request.c(401): [client 127.0.0.1:58729]   
> Accept-Encoding: gzip, deflate
> [Wed Mar 16 12:02:31.968004 2016] [core:trace8] [pid 95897:tid 
> 123145310887936] core_filters.c(460): [client 127.0.0.1:58729] total bytes 
> written: 37
> [Wed Mar 16 12:02:31.968027 2016] [core:trace8] [pid 95897:tid 
> 123145310887936] core_filters.c(480): [client 127.0.0.1:58729] tried 
> nonblocking write, total bytes written: 37
> [Wed Mar 16 12:02:31.968036 2016] [core:trace6] [pid 95897:tid 
> 123145310887936] util_filter.c(741): [client 127.0.0.1:58729] setaside empty 
> brigade to empty brigade in 'core' output filter
> [Wed Mar 16 12:02:31.968017 2016] [http:trace4] [pid 95897:tid 
> 123145302839296] http_request.c(401): [client 127.0.0.1:58729]   User-Agent: 
> nghttp2/1.8.0
> [Wed Mar 16 12:02:31.968051 2016] [http:trace4] [pid 95897:tid 
> 123145302839296] http_request.c(401): [client 127.0.0.1:58729]   Host: 
> test.example.org:12345
> [Wed Mar 16 12:02:31.968110 2016] [rewrite:trace2] [pid 95897:tid 
> 123145302839296] mod_rewrite.c(485): [client 127.0.0.1:58729] 127.0.0.1 - - 
> [test.example.org/sid#7fd4318a6b78][rid#7fd4318e56a0/initial] init rewrite 
> engine with requested uri /
> [Wed Mar 16 12:02:31.968120 2016] [rewrite:trace3] [pid 95897:tid 
> 123145302839296] mod_rewrite.c(485): [client 127.0.0.1:58729] 127.0.0.1 - - 
> 

Re: svn commit: r1735466 - /httpd/httpd/branches/2.4.x/STATUS

[Stefan Eissing]

Thanks. Changed in 1735748. Updated backport patch.

-Stefan

> Am 18.03.2016 um 22:11 schrieb Christophe JAILLET 
> :
> 
> Le 17/03/2016 18:37, ic...@apache.org a écrit :
>> Author: icing
>> Date: Thu Mar 17 17:37:35 2016
>> New Revision: 1735466
>> 
>> URL: http://svn.apache.org/viewvc?rev=1735466=rev
>> Log:
>> proposal to backport mod_proxy_http2
>> 
>> Modified:
>> httpd/httpd/branches/2.4.x/STATUS
>> 
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1735466=1735465=1735466=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Thu Mar 17 17:37:35 2016
>> @@ -175,7 +175,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>
>> http://home.apache.org/~ylavic/patches/httpd-2.4.x-no_crl_for_cert_ok.patch
>>   +1: ylavic
>>  -
>> +  *) mod_proxy_http2: add http2 proxy support in new, experimental module.
>> + Includes backport of r1729208 to set ALPN protocols for ssl backend
>> + connections.
>> + Trunk version of patch: 
>> + Backport version for 2.4.x of patch: 
>> https://eissing.org/proxy_http2_2.4.patch
>> + +1: icing
>> +
>> +
>>  PATCHES/ISSUES THAT ARE BEING WORKED
>>  *) http: Don't remove the Content-Length of zero from a HEAD response if
>> 
> The following code is spurious:
> +if (APLOGcdebug(session->c)) {
> +ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, session->c,
> +  "h2_proxy_session(%s): submit %s%s -> %d",
> +  session->id, stream->req->authority, stream->req->path,
> +  rv);
> +}
> +else {
> +ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, session->c,
> +  "h2_proxy_session(%s-%d): submit %s%s",
> +  session->id, rv, stream->req->authority, 
> stream->req->path);
> +}
> 
> 
> 

mod_proxy_http2 backport proposal w. patch

[Stefan Eissing]

I propose a backport of mod_proxy_http2 with a 2.4.x patch included in STATUS. 
Kind souls may have a look. Maybe we can get it in for 2.4.19.

Particular attention would be welcome by people who know the differences 
between trunk and 2.4.x architecture. I had to rip out the "detach_backend" 
calls as they are non-existent and am not certain if I overlooked consequences. 
My test suites run fine, though.

Cheers,

  Stefan

Re: Plan for T of 2.4.19

[fabien]

Hello Jim,


I hope to T 2.4.19 on Mon/Tues with a release on Friday.

There are some backports proposed that would be nice to get
into this release,


I would like to suggest backporting:

https://svn.apache.org/viewvc?view=revision=1734412

It is a minor but I think useful feature which does not disrupt much the 
code base, just add a function and a new authorization provider.


Now I'm not sure of the update policy on "bug fix" release, maybe adding a 
feature is too much, in which case apply the policy and do not backport:-)


--
Fabien.

Re: svn commit: r1735176 - in /httpd/httpd/trunk: CHANGES modules/http/http_core.c

[Stefan Eissing]

What I see here on a single process server (-X) for simplicity:

[Wed Mar 16 12:00:25.191155 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)
[Wed Mar 16 12:00:26.218216 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)
[Wed Mar 16 12:00:27.240436 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)
[Wed Mar 16 12:00:28.267453 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)
[Wed Mar 16 12:00:29.283653 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 0 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)
[Wed Mar 16 12:00:30.286473 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 1 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)
[Wed Mar 16 12:00:31.306868 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 1 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)
[Wed Mar 16 12:00:32.331939 2016] [mpm_event:trace6] [pid 95897:tid 
123145323229184] event.c(1779): connections: 1 (clogged: 0 write-completion: 0 
keep-alive: 0 lingering: 0 suspended: 0)

when I connect via curl, but no response comes back:
12:59:58 delight:~/projects/httpd/test/mod_h2/trunk> /opt/apache-trunk/bin/curl 
-vvv http://test.example.org:12345
* Rebuilt URL to: http://test.example.org:12345/
*   Trying 127.0.0.1...
* Connected to test.example.org (127.0.0.1) port 12345 (#0)
> GET / HTTP/1.1
> Host: test.example.org:12345
> User-Agent: curl/7.47.1
> Accept: */*
> 
^C

A direct HTTP/2 connection via nghttp works:

Wed Mar 16 12:02:31.967934 2016] [core:trace6] [pid 95897:tid 123145310887936] 
util_filter.c(801): [client 127.0.0.1:58729] reinstate empty brigade to full 
brigade in 'core' output filter
[Wed Mar 16 12:02:31.967954 2016] [core:trace6] [pid 95897:tid 123145310887936] 
util_filter.c(884): [client 127.0.0.1:58729] will flush because of FLUSH bucket
[Wed Mar 16 12:02:31.967959 2016] [core:trace8] [pid 95897:tid 123145310887936] 
util_filter.c(886): [client 127.0.0.1:58729] seen in brigade so far: bytes: 37, 
non-file bytes: 37, eor buckets: 0, morphing buckets: 0
[Wed Mar 16 12:02:31.967964 2016] [core:trace8] [pid 95897:tid 123145310887936] 
util_filter.c(910): [client 127.0.0.1:58729] brigade contains: bytes: 0, 
non-file bytes: 0, eor buckets: 0, morphing buckets: 0
[Wed Mar 16 12:02:31.967980 2016] [core:trace8] [pid 95897:tid 123145310887936] 
core_filters.c(446): [client 127.0.0.1:58729] flushing now
[Wed Mar 16 12:02:31.967964 2016] [http:trace4] [pid 95897:tid 123145302839296] 
http_request.c(398): [client 127.0.0.1:58729] Headers received from client:
[Wed Mar 16 12:02:31.967998 2016] [http:trace4] [pid 95897:tid 123145302839296] 
http_request.c(401): [client 127.0.0.1:58729]   Accept: */*
[Wed Mar 16 12:02:31.968009 2016] [http:trace4] [pid 95897:tid 123145302839296] 
http_request.c(401): [client 127.0.0.1:58729]   Accept-Encoding: gzip, deflate
[Wed Mar 16 12:02:31.968004 2016] [core:trace8] [pid 95897:tid 123145310887936] 
core_filters.c(460): [client 127.0.0.1:58729] total bytes written: 37
[Wed Mar 16 12:02:31.968027 2016] [core:trace8] [pid 95897:tid 123145310887936] 
core_filters.c(480): [client 127.0.0.1:58729] tried nonblocking write, total 
bytes written: 37
[Wed Mar 16 12:02:31.968036 2016] [core:trace6] [pid 95897:tid 123145310887936] 
util_filter.c(741): [client 127.0.0.1:58729] setaside empty brigade to empty 
brigade in 'core' output filter
[Wed Mar 16 12:02:31.968017 2016] [http:trace4] [pid 95897:tid 123145302839296] 
http_request.c(401): [client 127.0.0.1:58729]   User-Agent: nghttp2/1.8.0
[Wed Mar 16 12:02:31.968051 2016] [http:trace4] [pid 95897:tid 123145302839296] 
http_request.c(401): [client 127.0.0.1:58729]   Host: test.example.org:12345
[Wed Mar 16 12:02:31.968110 2016] [rewrite:trace2] [pid 95897:tid 
123145302839296] mod_rewrite.c(485): [client 127.0.0.1:58729] 127.0.0.1 - - 
[test.example.org/sid#7fd4318a6b78][rid#7fd4318e56a0/initial] init rewrite 
engine with requested uri /
[Wed Mar 16 12:02:31.968120 2016] [rewrite:trace3] [pid 95897:tid 
123145302839296] mod_rewrite.c(485): [client 127.0.0.1:58729] 127.0.0.1 - - 
[test.example.org/sid#7fd4318a6b78][rid#7fd4318e56a0/initial] applying pattern 
'^/latest.tar.gz$' to uri '/'
[Wed Mar 16 12:02:31.968154 2016] [rewrite:trace3] [pid 95897:tid 
123145302839296] mod_rewrite.c(485): [client 127.0.0.1:58729] 127.0.0.1 - - 
[test.example.org/sid#7fd4318a6b78][rid#7fd4318e56a0/initial] applying pattern 
'/rewrite(.*)' to uri '/'
[Wed Mar 

Re: TLS session ticket key (shared) renewal

[Ruediger Pluem]

On 03/18/2016 04:09 PM, Rainer Jung wrote:
> Am 18.03.2016 um 15:01 schrieb Yann Ylavic:
>> On Fri, Mar 18, 2016 at 2:55 PM, Yann Ylavic  wrote:
>>> Currently this can be done by using a (shared) SSLSessionTicketKeyFile
>>> and gracefuly restarting httpd instances, but there is room for
>>> improvements here.
>>>
>>> Thoughts?
>>
>> For the single httpd instance case at least, I'm thinking of
>> SSLSessionTicketKeyTimeout which could be used for renewing the
>> key(s), without the need for a scheduled restart.
>> The key(s) would have to be stored/sync-ed in a SHM (or slotmem)...
> 
> Would that mean, that at the points of time of key renewal all old tickets 
> immediately loose their validity? In that
> case you would have a regular bump in negotation rates. It would be nice, if 
> one older generation of keys would still
> work for a little time, so some overlap. I haven't checked how to do that 
> though.
> 
> Any idea about a scheme how to renew the keys between nodes in a farm in a 
> synced way? Finding a common point in time to
> renew would not be the problem (assuming synced clocks), but how the 
> regenerate keys deterministically starting from one
> common secret (the SSLSessionTicketKeyFile) without ending with keys which 
> are too weak?

My idea would be at high level to leverage approaches that are used for one 
time passwords here.
But I need to admit that I don't know how feasible that is at all and how 
usable these approaches are for generating
a (strong) key.

Regards

Rüdiger

Re: TLS session ticket key (shared) renewal

[Yann Ylavic]

On Fri, Mar 18, 2016 at 4:20 PM, Ruediger Pluem  wrote:
> On 03/18/2016 04:09 PM, Rainer Jung wrote:
>>
>> Any idea about a scheme how to renew the keys between nodes in a farm in a 
>> synced way? Finding a common point in time to
>> renew would not be the problem (assuming synced clocks), but how the 
>> regenerate keys deterministically starting from one
>> common secret (the SSLSessionTicketKeyFile) without ending with keys which 
>> are too weak?
>
> My idea would be at high level to leverage approaches that are used for one 
> time passwords here.
> But I need to admit that I don't know how feasible that is at all and how 
> usable these approaches are for generating
> a (strong) key.

Maybe something like the following could work, and maybe also it could
be secure (any contradictory opinion is of course very welcome :)

Say each instance starts with the same configured passphrase and salt
(same too, but random and large enough, say 128bit).

At startup we generate a master key (MK) from this passphrase/salt
(using PDKF2, maybe with some reasonable #iterations), and we'll use a
derived key (DK) for session tickets.

To derive the MK into DKs (at startup or when the current DK
timeouts), let's again run PDKF2 but now with the current time as salt
(and a single iteration).

This scheme makes the DK deterministic at any time, hence provided
clocks are synchronized, each httpd instance should use the same key.

Since session tickets also need a HMAC key, we would do the same for
it (from another passphrase and salt).

I may be opportunistic about the security of this scheme, though,
please experts ring the bell :p

Regards,
Yann.

Re: svn commit: r1734396 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/ssl/mod_ssl.c

[Jeff Trawick]

On Fri, Mar 18, 2016 at 1:19 PM, Yann Ylavic  wrote:

> On Fri, Mar 18, 2016 at 5:06 PM, Jeff Trawick  wrote:
> > On Thu, Mar 10, 2016 at 7:31 AM,  wrote:
> >>
> >> Author: ylavic
> >> Date: Thu Mar 10 12:31:13 2016
> >> New Revision: 1734396
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1734396=rev
> >> Log:
> >> Merge r1734006 from trunk:
> >>
> >> mod_ssl: Don't lose track of the SSL context if the
> >> ssl_run_pre_handshake()
> >> hook returns an error.
> >
> >
> > The ssl_run_pre_handshake() hook doesn't exist in the 2.4.x branch.  I
> would
> > rather like it to exist there and will propose so after some testing,
> but it
> > isn't yet clear that the CHANGES entry will make sense for httpd 2.4.19.
> > (We'll see.)
>
> I think the backport worth it because in 2.4.x like in trunk, we could
> also (unlikely) fail in SSL_set_session_id_context(), and likewise
> lose track of sslconn->ssl.
>
> Maybe s/ssl_run_pre_handshake/SSL_set_session_id_context/ in CHANGES?
>

+1

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1735466 - /httpd/httpd/branches/2.4.x/STATUS

[Christophe JAILLET]

Le 17/03/2016 18:37, ic...@apache.org a écrit :

Author: icing
Date: Thu Mar 17 17:37:35 2016
New Revision: 1735466

URL: http://svn.apache.org/viewvc?rev=1735466=rev
Log:
proposal to backport mod_proxy_http2

Modified:
 httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1735466=1735465=1735466=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Thu Mar 17 17:37:35 2016
@@ -175,7 +175,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:

http://home.apache.org/~ylavic/patches/httpd-2.4.x-no_crl_for_cert_ok.patch
   +1: ylavic
  
-

+  *) mod_proxy_http2: add http2 proxy support in new, experimental module.
+ Includes backport of r1729208 to set ALPN protocols for ssl backend
+ connections.
+ Trunk version of patch: 
+ Backport version for 2.4.x of patch: 
https://eissing.org/proxy_http2_2.4.patch
+ +1: icing
+
+
  PATCHES/ISSUES THAT ARE BEING WORKED
  
*) http: Don't remove the Content-Length of zero from a HEAD response if



The following code is spurious:
+if (APLOGcdebug(session->c)) {
+ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, session->c,
+  "h2_proxy_session(%s): submit %s%s -> %d",
+  session->id, stream->req->authority, 
stream->req->path,

+  rv);
+}
+else {
+ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, session->c,
+  "h2_proxy_session(%s-%d): submit %s%s",
+  session->id, rv, stream->req->authority, 
stream->req->path);

+}

Re: svn commit: r1734396 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/ssl/mod_ssl.c

[Yann Ylavic]

On Fri, Mar 18, 2016 at 6:24 PM, Jeff Trawick  wrote:
>>
>> Maybe s/ssl_run_pre_handshake/SSL_set_session_id_context/ in CHANGES?
>
>
> +1

I mentioned ssl_init_ssl_connection() instead (the common caller), in r1735650.

Thanks!

Re: svn commit: r1735216 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_mpm.h include/mpm_common.h modules/proxy/mod_proxy_wstunnel.c server/mpm/event/event.c server/mpm/event/fdqueue.h

[Stefan Eissing]

I am very confused right now. Nothing makes sense.

Can someone who is certain check in a trunk that is working for him?

> Am 16.03.2016 um 13:23 schrieb Stefan Eissing :
> 
> Testing again to verify...
> 
>> Am 16.03.2016 um 13:15 schrieb Yann Ylavic :
>> 
>> On Wed, Mar 16, 2016 at 12:06 PM,   wrote:
>>> Author: icing
>>> Date: Wed Mar 16 11:06:28 2016
>>> New Revision: 1735216
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1735216=rev
>>> Log:
>>> reverting r1735174 as http/1.1 just terminated before response
>> 
>> Hmm, not sure to understand.
>> Didn't you mean to revert r1735176 instead?
> 

Re: svn commit: r1735216 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_mpm.h include/mpm_common.h modules/proxy/mod_proxy_wstunnel.c server/mpm/event/event.c server/mpm/event/fdqueue.h

[Ruediger Pluem]

Try svn co -r 1735175 https://svn.apache.org/repos/asf/httpd/httpd/trunk or svn 
up -r 1735175 and see where you end
compiling and testing it.

Regards

Rüdiger

On 03/16/2016 01:49 PM, Stefan Eissing wrote:
> I am very confused right now. Nothing makes sense.
> 
> Can someone who is certain check in a trunk that is working for him?
> 
>> Am 16.03.2016 um 13:23 schrieb Stefan Eissing :
>>
>> Testing again to verify...
>>
>>> Am 16.03.2016 um 13:15 schrieb Yann Ylavic :
>>>
>>> On Wed, Mar 16, 2016 at 12:06 PM,   wrote:
 Author: icing
 Date: Wed Mar 16 11:06:28 2016
 New Revision: 1735216

 URL: http://svn.apache.org/viewvc?rev=1735216=rev
 Log:
 reverting r1735174 as http/1.1 just terminated before response
>>>
>>> Hmm, not sure to understand.
>>> Didn't you mean to revert r1735176 instead?
>>
> 
> 

Re: httpd-2.4.x patches for NetWare build.

[Stefan Eissing]

Applied in r1735459.

> Am 15.03.2016 um 22:52 schrieb NormW :
> 
> G/M,
> Attached two simple patches for httpd-2.4.x tree:
> 
> Add two extra missing symbols for mod_proxy needed to allow a NetWare build 
> at the present time. Once the auto symbols export functionality is 
> backported, this patch would also be removed.
> 
> At the present time 2.4.x waits approval to backport mod_proxy_http2, Until 
> then the attached diff for NWGNUmakefile in modules/http2 is required - a 
> build system vaguery says if there is only only one build target listed in 
> the NWGNUmakefile it will try to build itself and crash. If mod_proxy_http2 
> is backported it becomes the second item in the build list and all remains 
> happy.
> Norm
>