Re: Branching for 6.1.x tomorrow

[Leif Hedstrom]

> On Dec 15, 2015, at 12:02 PM, Leif Hedstrom  wrote:
> 
> Hi all,
> 
> I’m planning on branching 6.1.x tomorrow afternoon, so please take a look at 
> your Jira’s, and update / move them accordingly.

sorry about the wrong dev@ list :-/.

— leif

Branching for 6.1.x tomorrow

[Leif Hedstrom]

Hi all,

I’m planning on branching 6.1.x tomorrow afternoon, so please take a look at 
your Jira’s, and update / move them accordingly.

Cheers,

— leif

Re: async mpms + http2

[Graham Leggett]

On 15 Dec 2015, at 5:44 PM, Stefan Eissing  wrote:

>  However, there is another state in HTTP/2 processing, where a BLOCK_READ is 
> performed: flow control on streaming out responses. Basically, the client has 
> a window of n bytes, the server sends n response bytes and then needs to wait 
> for the client to increase the window again. This would be a good time to 
> resume processing back to the mpm, and initially I did so. But that breaks 
> under load.
> 
>  Under load, the event mpm feels free to close connections in certain states 
> - I think CONN_STATE_CHECK_REQUEST_LINE_READABLE. That is fine for a HTTP/1 
> connection as it always is between requests here. But HTTP/2 would also like 
> to use read events, but unloading a child by closing such connections is not 
> the right thing to do.
> 
>  Is there a way mod_http2 can achieve this or do we need another flag in 
> conn_rec/cs?

Does the CONN_STATE_WRITE_COMPLETION state fit this case?

The WRITE in the above name is a bit of a misnomer, because when mod_ssl 
returns WANTS_READ we return to the CONN_STATE_WRITE_COMPLETION state with the 
sense set to READ. This tells the MPM to block waiting until we’re readable, as 
opposed to block waiting until we’re writable.

> Observation 2: controlled close
>  HTTP/2 would like to send out a last frame when closing a connection in a 
> controlled/timeout way. Do we need another hook for that? Something like 
> "pre_close_connection”?

I’m assuming we would like a module to have control over the sending of that 
frame, if so, it makes sense yes.

> Observation 3: timeouts
>  a. If admins would like to have another Timeout for HTTP/2 connections, they 
> are currently stuck with configuring one Timeout which goes to 
> server_rec->timeout, right? For idle connections, clients already try to keep 
> it open longer. It would be nice to give admins a choice here for different 
> values based on the selected protocol. How to best do this?

Perhaps just as we can override the sense of the connection before returning, 
we might be able to modify the timeout before returning.

>  b. Handling own timeouts: if I want, during processing the connection, a 
> different socket timeout, I can just set it using apr_socket_timeout_set()? 
> Shall I restore it back to server->timeout before returning?

That feels wrong, ideally we want to be formally telling the MPM “give us this 
timeout” rather than doing something sneaky behind it’s back.

>  c. What would be the best way to wait for a file description *and* 
> conditional event simultaneously? mod_http2 has now a sort of pool loop with 
> double backup timer for situations where it needs to watch both client and 
> backend processes.

I’m not sure how portable it is watching for file descriptors. I have used 
libev to do this in the past and it was quite involved. However - if we can 
support this it would be really useful.

Regards,
Graham
—

Re: OpenSSL 0.9.8/1.0.0 on Trunk

[Mike Rumph]

FYI.  Bug 58737 was just opened today for this error.

Thanks,

Mike

On 12/14/2015 10:15 AM, William A Rowe Jr wrote:

W.r.t. http://svn.apache.org/r1719967 - I'm +1 for the backport.
I'd like to propose we remove all support from *trunk* for OpenSSL < 1.0.1
effective now...

https://mta.openssl.org/pipermail/openssl-announce/2014-December/00.html

We don't deprecate support on maintenance branches (e.g. 2.2/2.4),
because we seek to minimize the pain of moving from one subversion
release to another.  If someone wanted to hack a non-fatal warning for
the ./configure phase, that could be a worthwhile patch.

async mpms + http2

[Stefan Eissing]

I just committed a change in mod_http2 that will return idle connections back 
to the mpm, expecting to be invoked again when new data arrives. I learned 
quite something about event (have not looked much at motorz yet) and am 
thinking about improvements. If knowledgeable people could give me a hand here, 
I'd highly appreciate it.

Observation 1: mapping conn_states
  As I understand it, the connection state model, as defined in conn_state_e, 
enables asynchronous processing in two states:
  a. CONN_STATE_CHECK_REQUEST_LINE_READABLE, check read, invoke 
ap_run_process_connection() on data
  b. CONN_STATE_WRITE_COMPLETION, check write, if data is still in out filters

  An invocation of ap_run_process_connection() is expected to return, usually 
in WRITE_COMPLETION state. Then any data is attempted to be written. When this 
succeeds, the next state depends on secondary flags such as c->aborted, 
c->keepalive and c->data_in_input_filters.

  HTTP/2 processing has one state where it fits into this model: when no more 
streams are open. This is what is currently implemented in trunk. 

  However, there is another state in HTTP/2 processing, where a BLOCK_READ is 
performed: flow control on streaming out responses. Basically, the client has a 
window of n bytes, the server sends n response bytes and then needs to wait for 
the client to increase the window again. This would be a good time to resume 
processing back to the mpm, and initially I did so. But that breaks under load.

  Under load, the event mpm feels free to close connections in certain states - 
I think CONN_STATE_CHECK_REQUEST_LINE_READABLE. That is fine for a HTTP/1 
connection as it always is between requests here. But HTTP/2 would also like to 
use read events, but unloading a child by closing such connections is not the 
right thing to do.

  Is there a way mod_http2 can achieve this or do we need another flag in 
conn_rec/cs?

Observation 2: controlled close
  HTTP/2 would like to send out a last frame when closing a connection in a 
controlled/timeout way. Do we need another hook for that? Something like 
"pre_close_connection"?
 
Observation 3: timeouts
  a. If admins would like to have another Timeout for HTTP/2 connections, they 
are currently stuck with configuring one Timeout which goes to 
server_rec->timeout, right? For idle connections, clients already try to keep 
it open longer. It would be nice to give admins a choice here for different 
values based on the selected protocol. How to best do this?

  b. Handling own timeouts: if I want, during processing the connection, a 
different socket timeout, I can just set it using apr_socket_timeout_set()? 
Shall I restore it back to server->timeout before returning?

  c. What would be the best way to wait for a file description *and* 
conditional event simultaneously? mod_http2 has now a sort of pool loop with 
double backup timer for situations where it needs to watch both client and 
backend processes.


Cheers,

  Stefan

Re: OpenSSL 0.9.8/1.0.0 on Trunk

[William A Rowe Jr]

As an alternative, we can flag removing pre openssl 1.0.1 support as a
showstopper in STATUS and leave it be for a while longer to make backports
a bit easier.  Thoughts?
On Dec 14, 2015 12:35, "Ruediger Pluem"  wrote:

>
>
> On 12/14/2015 07:15 PM, William A Rowe Jr wrote:
> > W.r.t. http://svn.apache.org/r1719967 - I'm +1 for the backport.
> > I'd like to propose we remove all support from *trunk* for OpenSSL <
> 1.0.1
> > effective now...
> >
> >
> https://mta.openssl.org/pipermail/openssl-announce/2014-December/00.html
> >
> > We don't deprecate support on maintenance branches (e.g. 2.2/2.4),
> > because we seek to minimize the pain of moving from one subversion
> > release to another.  If someone wanted to hack a non-fatal warning for
> > the ./configure phase, that could be a worthwhile patch.
> >
> >
>
> +1
>
> Regards
>
> Rüdiger
>

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

[Jan Kaluža]

On 12/15/2015 02:16 PM, Yann Ylavic wrote:

Hi Jan,

On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža  wrote:


I think I've just fixed that in . I will
also propose that for 2.4.x and 2.2.x.


Shouldn't we do the same for ecparams below?


Probably yes, I was just checking the arguments which get passed to 
"SSL_CTX_set_*" functions. I think you are right we should call 
EC_GROUP_free there.


Jan Kaluza


Regards,
Yann.

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

[Yann Ylavic]

Hi Jan,

On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža  wrote:
>
> I think I've just fixed that in . I will
> also propose that for 2.4.x and 2.2.x.

Shouldn't we do the same for ecparams below?

Regards,
Yann.

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

[Jan Kaluža]

On 12/14/2015 02:12 PM, jean-frederic clere wrote:

Hi,

I am sure I am doing something wrong, but when using a dummy crypto
device to recreate a customer issue I am getting a similar issue in
httpd-trunk but I am nearly sure someone would have complained here if
that would be the case.


Hi,

I think I've just fixed that in . I will 
also propose that for 2.4.x and 2.2.x.


Regards,
Jan Kaluza


Comments

Jean-Frederic

The stack:
+++
(gdb) bt
#0  0x7fac11198a98 in raise () from /lib64/libc.so.6
#1  0x7fac1119a69a in abort () from /lib64/libc.so.6
#2  0x7fac01f27e33 in dummy_init (e=) at e_dummy.c:146
#3  0x7fac05a69509 in test_rc4_init_key () from /lib64/libcrypto.so.10
#4  0x7fac05b3374c in ?? () from /lib64/libcrypto.so.10
#5  0x7fac0001 in ?? ()
#6  0x00e37138 in ?? ()
#7  0x00e62348 in ?? ()
#8  0x7fac11d9d68a in apr_pool_cleanup_register (p=0x7fac05a6a122
, data=0xfe4678, plain_cleanup_fn=0x1,
child_cleanup_fn=0x7fac05dab5c0)
 at memory/unix/apr_pools.c:2218
#9  0x00f094c0 in ?? ()
#10 0x7fac0625bf60 in ?? () from /home/jfclere/APACHE/modules/mod_ssl.so
#11 0x00e60938 in ?? ()
#12 0x00e62348 in ?? ()
#13 0x7fac05a6ac58 in BUF_memdup () from /lib64/libcrypto.so.10
#14 0x7fac06039af2 in ssl_init_Engine (s=0xe60938,
s@entry=0x7fffb9ad2e90, p=p@entry=0xe37138) at ssl_engine_init.c:386
#15 0x7fac0603bdaf in ssl_init_Module (p=0xe37138, plog=, ptemp=0xf09780, base_server=0x7fffb9ad2e90) at ssl_engine_init.c:242
#16 0x00455153 in ap_run_post_config
(pconf=pconf@entry=0xe37138, plog=0xea0778, ptemp=0xe62348, s=0xe60938)
at config.c:103
#17 0x0042c575 in main (argc=3, argv=0x7fffb9ad3158) at main.c:788
+++