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

2017-03-20 Thread Eric Covener 
On Mon, Mar 20, 2017 at 5:50 PM, Jacob Champion  wrote:
> One last question before I promote -- the "ProxyFCGIBackend FPM" case
> currently just fixes up the SCRIPT_NAME and nothing else. Are you both okay
> with releasing that way, since there's a good chance any further fixups we
> discover will need to live under a separate ProxyFCGIBackend setting for
> compatibility?

I'm not worried, since we can now fix things up easier w/ config vs. code.

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

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

2017-03-20 Thread Jacob Champion 

On 03/15/2017 03:30 PM, cove...@apache.org wrote:

Author: covener
Date: Wed Mar 15 22:30:23 2017
New Revision: 1787104

URL: http://svn.apache.org/viewvc?rev=1787104=rev
Log:
vote


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=1787104=1787103=1787104=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Wed Mar 15 22:30:23 2017
@@ -140,7 +140,7 @@ RELEASE SHOWSTOPPERS:
   http://svn.apache.org/r1782482
   http://svn.apache.org/r1782532
  2.4.x patch: http://home.apache.org/~jim/patches/mod_proxy_fcgi-v3.patch
- +1: jim
+ +1: jim, covener


One last question before I promote -- the "ProxyFCGIBackend FPM" case 
currently just fixes up the SCRIPT_NAME and nothing else. Are you both 
okay with releasing that way, since there's a good chance any further 
fixups we discover will need to live under a separate ProxyFCGIBackend 
setting for compatibility?


(By the way, thanks Jim and Eric for your work on this.)

--Jacob

Re: server-status script donated to ASF

2017-03-20 Thread Marion & Christophe JAILLET 

Hi,

when running, the page get longer 5 seconds or so.

In the JS code, there is:

// resize pane
document.getElementById('leftpane').style.height = 
document.getElementById('wrapper').getBoundingClientRect().height + "px";


I guess that is "growing page" is coming from there.

What it is used for?

CJ

Le 20/03/2017 à 14:01, Daniel Gruno a écrit :

On 03/20/2017 02:01 PM, Jim Jagielski wrote:

Since these are docs, does that mean they can be
CTR'ed into 2.4? :)

probably? :) it's just an example script, nothing that needs compiling
or counts as de facto replacement yet :)


On Mar 20, 2017, at 8:57 AM, Daniel Gruno  wrote:

On 03/20/2017 01:56 PM, Jim Jagielski wrote:

Cool... URL?

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/


On Mar 15, 2017, at 10:23 AM, Daniel Gruno  wrote:

FWIW, the stuff that powers https://httpd.apache.org/server-status has
now been donated to the HTTPd project.

With regards,
Daniel.

Re: server-status script donated to ASF

2017-03-20 Thread Daniel Gruno 
On 03/20/2017 02:01 PM, Jim Jagielski wrote:
> Since these are docs, does that mean they can be
> CTR'ed into 2.4? :)

probably? :) it's just an example script, nothing that needs compiling
or counts as de facto replacement yet :)

> 
>> On Mar 20, 2017, at 8:57 AM, Daniel Gruno  wrote:
>>
>> On 03/20/2017 01:56 PM, Jim Jagielski wrote:
>>> Cool... URL?
>>
>> https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/
>>
>>>
 On Mar 15, 2017, at 10:23 AM, Daniel Gruno  wrote:

 FWIW, the stuff that powers https://httpd.apache.org/server-status has
 now been donated to the HTTPd project.

 With regards,
 Daniel.
>>>
>>
>

Re: server-status script donated to ASF

2017-03-20 Thread Jim Jagielski 
Since these are docs, does that mean they can be
CTR'ed into 2.4? :)

> On Mar 20, 2017, at 8:57 AM, Daniel Gruno  wrote:
> 
> On 03/20/2017 01:56 PM, Jim Jagielski wrote:
>> Cool... URL?
> 
> https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/
> 
>> 
>>> On Mar 15, 2017, at 10:23 AM, Daniel Gruno  wrote:
>>> 
>>> FWIW, the stuff that powers https://httpd.apache.org/server-status has
>>> now been donated to the HTTPd project.
>>> 
>>> With regards,
>>> Daniel.
>> 
>

Re: server-status script donated to ASF

2017-03-20 Thread Daniel Gruno 
On 03/20/2017 01:56 PM, Jim Jagielski wrote:
> Cool... URL?

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/

> 
>> On Mar 15, 2017, at 10:23 AM, Daniel Gruno  wrote:
>>
>> FWIW, the stuff that powers https://httpd.apache.org/server-status has
>> now been donated to the HTTPd project.
>>
>> With regards,
>> Daniel.
>

Re: server-status script donated to ASF

2017-03-20 Thread Jim Jagielski 
Cool... URL?

> On Mar 15, 2017, at 10:23 AM, Daniel Gruno  wrote:
> 
> FWIW, the stuff that powers https://httpd.apache.org/server-status has
> now been donated to the HTTPd project.
> 
> With regards,
> Daniel.

Re: [users@httpd] Problem when using nested if statements in apache 2.4

2017-03-20 Thread Luca Toscano 
2017-03-17 22:33 GMT+01:00 Luca Toscano :

>
>
> 2017-03-09 22:47 GMT+01:00 Luca Toscano :
>
>>
>>
>> 2017-02-24 23:27 GMT+01:00 Luca Toscano :
>>
>>> Hi everybody,
>>>
>>> the following users@ question is interesting in my opinion:
>>>
>>> 2017-02-20 18:17 GMT+01:00 Mike Schlottman :
>>>

 The problem comes when I combine these 2 so that all users except those
 coming from 127.*.*.* or 192.168.*.* see the nice error page.

 

   

 ErrorDocument 404 /errors/404

   

 

 The user from 172.28.1.84 does not get the nice 404 page, but the
 default 404 page.   The IP does not match either of the ranges as observed
 when using the ranges individually, but when combined in this way it does
 not work as expected.



 Any ideas why this is?



>>>
>>> He ended up using a single if with an expression composed by the two
>>> conditions in && to solve the problem, but I started to wonder why this
>>> configuration does not work. I tested the "nested ifs" config with trace8
>>> logging and it seem that only the outermost  expression gets evaluated.
>>>
>>> Is there a specific reason why this happens? I'd expect two possible
>>> outcomes from this configuration, namely either a syntax error while
>>> parsing the config (preferred imho) or a context merge, but not a no-op.
>>>
>>> Any pointers/suggestions about where to look?
>>>
>>>
>> I tried to investigate a bit the problem to write a good explanation in
>> the docs (and also to better understand the httpd internals for fun) but I
>> am still far from a satisfactory result.
>>
>> I tried the following config (inside other containers like Location too):
>>
>> 
>> ErrorDocument 503 "This is a custom 503 inside the outer IF!"
>> 
>>ErrorDocument 503 "This is a custom 503 inside the inner IF!"
>> 
>> 
>>
>> Each time that 503 is generated, I get the "outer IF" 503 response, never
>> the inner one.
>>
>> With gdb it is easy to see that when ap_if_walk is executed,
>> dconf->sec_if->nelts is 1, so only one of the Ifs is evaluated.
>>
>> So I checked how the if sections are parsed and built
>> with 
>> ap_process_config_tree->ap_walk_config->ap_walk_config_sub->invoke_cmd->ifsection
>> and eventually ap_add_if, but I only got that the parent/child relationship
>> is set up correctly.
>>
>> My only goal is to figure out if nested Ifs are not evaluated on purpose
>> and if so why they are allowed by the syntax checker. Eventually it would
>> be really great to update the docs (regular user docs and also
>> https://httpd.apache.org/docs/trunk/developer/request.html).
>>
>>
> This time (hopefully) I think I found what I was looking for, namely why
> nested  blocks are definitely not going to work.
>
> The ap_if_walk (request.c) function gets the core_dir_config settings
> via ap_get_core_module_config(r->per_dir_config), retrieving all the 
> containers using the sec_if field, and then iterating through them to
> evaluate their (apr_expr) conditions.
>
> In order to be able to use nested  blocks ap_if_walk would need to
> check, for each sec_if->elts element of the core's r->per_dir_config, if it
> contains a sec_if blocks too (and restart the process of checking its
> condition etc..). Something like:
>
> AP_DECLARE(int) ap_if_walk(request_rec *r) {
> [..]
> /* Go through the if entries, and check for matches  */
> for (sec_idx = 0; sec_idx < num_sec; ++sec_idx) {
> core_dir_config *entry_core;
> entry_core = ap_get_core_module_config(sec_ent[sec_idx]);
> if(entry_core->sec_if->nelts > 0) { .. /* handling nested s */
> .. }
> [..]
>
> In this way we would allow arbitrary nesting of  blocks in the httpd
> config. I am not advocating for this solution but we should either allow
> nested  blocks or explicitly warn the users when httpd checks its
> config that a nested configuration will be silently ignored (emitting an
> explicit configuration error while parsing the config would be even better
> but probably too invasive for 2.4.x releases).
>

Documentation updated with the current status, plus the following patch
seems to allow nested if blocks (probably not the best one but it is a pof):

http://home.apache.org/~elukey/httpd-trunk-core-nested_if_blocks.patch

 Luca

Re: svn commit: r1787728 - in /httpd/httpd/branches/2.4.x: ./ modules/ssl/ support/

2017-03-20 Thread Ruediger Pluem 
Looks like it is only the wrong commit message that confused me. Maybe wise to 
change it.

Regards

Rüdiger

On 03/20/2017 01:23 PM, Ruediger Pluem wrote:
> Hm. Looks like a lot more was changed that is not related to Lua.
> 
> Regards
> 
> Rüdiger
> 
> 
> On 03/20/2017 01:01 PM, j...@apache.org wrote:
>> Author: jim
>> Date: Mon Mar 20 12:01:16 2017
>> New Revision: 1787728
>>
>> URL: http://svn.apache.org/viewvc?rev=1787728=rev
>> Log:
>> Merge r1785115 from trunk:
>>
>> Look for specific versioned installs of Lua 5.3
>> Reviewed by: jim
>>
>> Modified:
>> httpd/httpd/branches/2.4.x/CHANGES
>> httpd/httpd/branches/2.4.x/STATUS
>> httpd/httpd/branches/2.4.x/acinclude.m4
>> httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_init.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_io.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_kernel.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_ocsp.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_vars.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_private.h
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_scache.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_ssl.c
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_ssl.h
>> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_stapling.c
>> httpd/httpd/branches/2.4.x/support/ab.c
>>
>

Re: svn commit: r1787728 - in /httpd/httpd/branches/2.4.x: ./ modules/ssl/ support/

2017-03-20 Thread Ruediger Pluem 
Hm. Looks like a lot more was changed that is not related to Lua.

Regards

Rüdiger


On 03/20/2017 01:01 PM, j...@apache.org wrote:
> Author: jim
> Date: Mon Mar 20 12:01:16 2017
> New Revision: 1787728
> 
> URL: http://svn.apache.org/viewvc?rev=1787728=rev
> Log:
> Merge r1785115 from trunk:
> 
> Look for specific versioned installs of Lua 5.3
> Reviewed by: jim
> 
> Modified:
> httpd/httpd/branches/2.4.x/CHANGES
> httpd/httpd/branches/2.4.x/STATUS
> httpd/httpd/branches/2.4.x/acinclude.m4
> httpd/httpd/branches/2.4.x/modules/ssl/mod_ssl.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_init.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_io.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_kernel.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_ocsp.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_vars.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_private.h
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_scache.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_ssl.c
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_ssl.h
> httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_stapling.c
> httpd/httpd/branches/2.4.x/support/ab.c
>

Re: svn commit: r1787606 - /httpd/httpd/trunk/server/core.c

2017-03-20 Thread Ruediger Pluem 


On 03/19/2017 11:33 AM, ic...@apache.org wrote:
> Author: icing
> Date: Sun Mar 19 10:33:43 2017
> New Revision: 1787606
> 
> URL: http://svn.apache.org/viewvc?rev=1787606=rev
> Log:
> On the trunk:
> 
> core: avoid socket timeout settings etc. on slave connections.
> 
> 
> Modified:
> httpd/httpd/trunk/server/core.c
> 
> Modified: httpd/httpd/trunk/server/core.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1787606=1787605=1787606=diff
> ==
> --- httpd/httpd/trunk/server/core.c (original)
> +++ httpd/httpd/trunk/server/core.c Sun Mar 19 10:33:43 2017
> @@ -5280,9 +5280,14 @@ static conn_rec *core_create_conn(apr_po
>  
>  static int core_pre_connection(conn_rec *c, void *csd)
>  {
> -core_net_rec *net = apr_palloc(c->pool, sizeof(*net));
> +core_net_rec *net;
>  apr_status_t rv;
>  
> +if (c->master) {
> +return DONE;
> +}
> +
> +net = apr_palloc(c->pool, sizeof(*net));
>  /* The Nagle algorithm says that we should delay sending partial
>   * packets in hopes of getting more data.  We don't want to do
>   * this; we are not telnet.  There are bad interactions between
> 
> 
> 

So you don't need csd set into c->conn_config for slave connections?

5320:

ap_set_core_module_config(net->c->conn_config, csd);


Furthermore the if in 5322 could go away after this change.

Regards

Rüdiger