Re: nghttp2 warning - what is this?

2015-09-16 Thread Michael Felt
well, correction on building nghttp. Seems it only expects to work in a GNU
rte and I do not have the time to verify an environment that will support
"POSIX" and GNU requirements. My experience is "small", i.e., not saying it
cannot be done - but anytime I have tried to build a library that insisted
on gcc I could not get it to work reliably with packages built using the
IBM compiler and the default AIX libc (et al) .rte filesets. Basically, I
need to add all the libraries that gcc needs to compile something.

Oh well. In any case, not tonight.

(p.s. gcc 4.7.X implies a standard compiler might work - if I understand
correctly that there is a break with standard C starting with gcc 4.8)

On Wed, Sep 16, 2015 at 6:31 PM, Michael Felt  wrote:

> well, just built it again, with --enable-maintainer-mode added, so now
> have:
>
> It was created by configure, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>
>   $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config
> --with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all
> --enable-mods-shared=all --disable-lua --enable-load-all-modules
> --enable-maintainer-mode
>
> I guess it will "complain" if I try to do anything. re: SSL - it is
> special, especially with the likes of libressl (aka "others" out there) -
> so maybe not the best test code - copying the test for pcre may be better.
> That caught me asap when I first started.
>
> And I shall go look for the library and get it built. Thanks for your
> quick reply!
>
>
>
> Slightly off topic - not sure if relevent considering the -Werror changes
> (whatever that is suppossed to mean in gcc land) here are the warning
> messages that are getting sent by XLC to stderr (there are more/others
> going to stdout):
>
> "util_expr_eval.c", line 1767.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1768.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1769.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1771.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1772.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1773.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1774.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1775.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1776.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1777.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1778.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1779.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
> is not allowed.
> "util_expr_eval.c", line 1780.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
> is not allowed.
> "util_expr_eval.c", line 1781.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
> is not allowed.
> "util_expr_eval.c", line 1782.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1783.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1784.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1785.7: 1506-196 (W) Initialization between types
> "const void* const" and "const char*(*)(struct {...}*,const void*,const
> char*)" is not allowed.
> "util_expr_eval.c", line 1789.7: 1506-196 (W) Initi

Re: nghttp2 warning - what is this?

2015-09-16 Thread Michael Felt
well, just built it again, with --enable-maintainer-mode added, so now have:

It was created by configure, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --enable-layout=AIX --with-apr=/opt/bin/apr-1-config
--with-apr-util=/opt/bin/apu-1-config --enable-mpms-shared=all
--enable-mods-shared=all --disable-lua --enable-load-all-modules
--enable-maintainer-mode

I guess it will "complain" if I try to do anything. re: SSL - it is
special, especially with the likes of libressl (aka "others" out there) -
so maybe not the best test code - copying the test for pcre may be better.
That caught me asap when I first started.

And I shall go look for the library and get it built. Thanks for your quick
reply!



Slightly off topic - not sure if relevent considering the -Werror changes
(whatever that is suppossed to mean in gcc land) here are the warning
messages that are getting sent by XLC to stderr (there are more/others
going to stdout):

"util_expr_eval.c", line 1767.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1768.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1769.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1771.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1772.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1773.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1774.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1775.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1776.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1777.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1778.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1779.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
is not allowed.
"util_expr_eval.c", line 1780.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
is not allowed.
"util_expr_eval.c", line 1781.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,char*)"
is not allowed.
"util_expr_eval.c", line 1782.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1783.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1784.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1785.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
char*)" is not allowed.
"util_expr_eval.c", line 1789.7: 1506-196 (W) Initialization between types
"const void* const" and "const char*(*)(struct {...}*,const void*,const
struct apr_array_header_t*)" is not allowed.
"util_expr_eval.c", line 1794.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1795.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1796.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1797.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct {...}*,const void*,const char*)" is
not allowed.
"util_expr_eval.c", line 1798.7: 1506-196 (W) Initialization between types
"const void* const" and "int(*)(struct

Re: svn commit: r1703415 - in /httpd/test/framework/trunk/c-modules: authany/mod_authany.c test_session/mod_test_session.c

2015-09-16 Thread Yann Ylavic
On Wed, Sep 16, 2015 at 5:08 PM, Jim Jagielski  wrote:
> All this is due to changes mode with the mainter-mode and
> which causes build stop error and stop for these kinds
> of warnings. These are simple 'squash warning' patches.

Since the stack may be corrupted on 32bit systems (quite hard to
diagnose), I committed a fix in r1703433.


Re: nghttp2 warning - what is this?

2015-09-16 Thread Stefan Eissing
Hi,

if you enable all modules, it will enable mod_h2 and that one needs libnghttp2. 
The warning could be better, if this is missing, admittedly I just copied and 
modified mod_ssl's test for openssl. 

//Stefan



> Am 16.09.2015 um 17:51 schrieb Michael Felt :
> 
> Hello all,
> 
> I have been ignoring building httpd-2.5.x and thought it was about time to 
> start taking notice. And I see a bunch of new messages - one of which may be 
> a drift in time between my AIX server and the NFS server I keep all the files 
> on.
> 
> But the first WARNING I saw was from nghttp2 - which perhaps I do not have at 
> all! Is this something extra, like pcre or apr that I need to have as a 
> library first? If so, the WARNING about it being too old is not correct - 
> because I do not have it at all.
> 
> However, if it is a module within httpd-2.5.x - how could it be too old when 
> I have just refreshed from the SVN repository?
> 
> Snip
> 
> + ./configure 
> --enable-layout=AIX 
> --with-apr=/opt/bin/apr-1-config 
> --with-apr-util=/opt/bin/apu-1-config 
> --enable-mpms-shared=all 
> --enable-mods-shared=all 
> --disable-lua > build/aix/configure.out
> configure: WARNING: apr/apr-util is compiled without ldap support
> configure: WARNING: nghttp2 version is too old
> configure: WARNING: apr/apr-util is compiled without ldap support
> configure: WARNING: Your system does not support Journald.
> configure: WARNING: Your system does not support systemd.
> + make > build/aix/make.out
> make: Warning: File '/data/prj/apache/httpd/httpd-2.5.x/.deps' has 
> modification time 118 s in the future
> 


nghttp2 warning - what is this?

2015-09-16 Thread Michael Felt
Hello all,

I have been ignoring building httpd-2.5.x and thought it was about time to
start taking notice. And I see a bunch of new messages - one of which may
be a drift in time between my AIX server and the NFS server I keep all the
files on.

But the first WARNING I saw was from nghttp2 - which perhaps I do not have
at all! Is this something extra, like pcre or apr that I need to have as a
library first? If so, the WARNING about it being too old is not correct -
because I do not have it at all.

However, if it is a module within httpd-2.5.x - how could it be too old
when I have just refreshed from the SVN repository?

Snip

+ ./configure
--enable-layout=AIX
--with-apr=/opt/bin/apr-1-config
--with-apr-util=/opt/bin/apu-1-config
--enable-mpms-shared=all
--enable-mods-shared=all
--disable-lua > build/aix/configure.out
configure: WARNING: apr/apr-util is compiled without ldap support
configure: WARNING: nghttp2 version is too old
configure: WARNING: apr/apr-util is compiled without ldap support
configure: WARNING: Your system does not support Journald.
configure: WARNING: Your system does not support systemd.
+ make > build/aix/make.out
make: Warning: File '/data/prj/apache/httpd/httpd-2.5.x/.deps' has
modification time 118 s in the future


Re: svn commit: r1703415 - in /httpd/test/framework/trunk/c-modules: authany/mod_authany.c test_session/mod_test_session.c

2015-09-16 Thread Greg Stein
Yeah... I do like -Werror, so that forces a clean build, so that *real*
warnings don't get buried in a bunch of useless warnings.

On Wed, Sep 16, 2015 at 10:08 AM, Jim Jagielski  wrote:

> All this is due to changes mode with the mainter-mode and
> which causes build stop error and stop for these kinds
> of warnings. These are simple 'squash warning' patches.
>
> > On Sep 16, 2015, at 10:50 AM, Greg Stein  wrote:
> >
> > On Wed, Sep 16, 2015 at 9:18 AM,  wrote:
> > Author: jim
> > Date: Wed Sep 16 14:18:49 2015
> > New Revision: 1703415
> > >...
> > Modified:
> httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> > URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c?rev=1703415&r1=1703414&r2=1703415&view=diff
> >
> ==
> > --- httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> (original)
> > +++ httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> Wed Sep 16 14:18:49 2015
> > @@ -149,7 +149,6 @@ static apr_status_t test_session_encode(
> >
> >  static apr_status_t test_session_decode(request_rec * r, session_rec *
> z)
> >  {
> > -apr_status_t result = OK;
> >  const size_t prefix_len = strlen(TEST_SESSION_ENCODING_PREFIX);
> >  test_session_dcfg_t *dconf = ap_get_module_config(r->per_dir_config,
> >
> &test_session_module);
> > @@ -203,7 +202,7 @@ static int test_session_handler(request_
> >  return DECLINED;
> >
> >  /* Copy the header for SessionHeader from the request to the
> response. */
> > -if (overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER))
> > +if ((overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER)))
> >  apr_table_setn(r->headers_out, TEST_SESSION_HEADER, overrides);
> >
> >  /* Additional commands to test the session API via POST. */
> > @@ -240,15 +239,15 @@ static int test_session_handler(request_
> >  }
> >  else if (!strcmp(pair->name, "name")) {
> >  apr_size_t len;
> > -apr_brigade_length(pair->value, 1, &len);
> > +apr_brigade_length(pair->value, 1, (apr_off_t *)&len);
> >
> > This seems really dangerous. Aren't there cases where sizeof(apr_size_t)
> != sizeof(apr_off_t) ??
> >
> >  fieldName = apr_pcalloc(r->pool, sizeof(char) * len +
> 1);
> > -result = apr_brigade_flatten(pair->value, fieldName,
> &len);
> > +result = apr_brigade_flatten(pair->value, fieldName,
> (apr_size_t *)&len);
> >
> > This seems unnecessary. &len should already be apr_size_t *
> >
> >  }
> >  else if (!strcmp(pair->name, "value")) {
> >  apr_size_t len;
> > -apr_brigade_length(pair->value, 1, &len);
> > +apr_brigade_length(pair->value, 1, (apr_off_t *)&len);
> >  fieldValue = apr_pcalloc(r->pool, sizeof(char) * len +
> 1);
> > -result = apr_brigade_flatten(pair->value, fieldValue,
> &len);
> > +result = apr_brigade_flatten(pair->value, fieldValue,
> (apr_size_t *)&len);
> >
> > These two, same as above.
> >
> > Heh. I haven't reviewed httpd code for years. But I saw a change to
> mod_authany.c and thought "what is that? isn't that module crazy stable?"
> ... curiosity :-P
> >
> > Cheers,
> > -g
> >
>
>


Re: svn commit: r1703415 - in /httpd/test/framework/trunk/c-modules: authany/mod_authany.c test_session/mod_test_session.c

2015-09-16 Thread Jim Jagielski
All this is due to changes mode with the mainter-mode and
which causes build stop error and stop for these kinds
of warnings. These are simple 'squash warning' patches.

> On Sep 16, 2015, at 10:50 AM, Greg Stein  wrote:
> 
> On Wed, Sep 16, 2015 at 9:18 AM,  wrote:
> Author: jim
> Date: Wed Sep 16 14:18:49 2015
> New Revision: 1703415
> >... 
> Modified: httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> URL: 
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c?rev=1703415&r1=1703414&r2=1703415&view=diff
> ==
> --- httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c 
> (original)
> +++ httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c Wed 
> Sep 16 14:18:49 2015
> @@ -149,7 +149,6 @@ static apr_status_t test_session_encode(
> 
>  static apr_status_t test_session_decode(request_rec * r, session_rec * z)
>  {
> -apr_status_t result = OK;
>  const size_t prefix_len = strlen(TEST_SESSION_ENCODING_PREFIX);
>  test_session_dcfg_t *dconf = ap_get_module_config(r->per_dir_config,
>&test_session_module);
> @@ -203,7 +202,7 @@ static int test_session_handler(request_
>  return DECLINED;
> 
>  /* Copy the header for SessionHeader from the request to the response. */
> -if (overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER))
> +if ((overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER)))
>  apr_table_setn(r->headers_out, TEST_SESSION_HEADER, overrides);
> 
>  /* Additional commands to test the session API via POST. */
> @@ -240,15 +239,15 @@ static int test_session_handler(request_
>  }
>  else if (!strcmp(pair->name, "name")) {
>  apr_size_t len;
> -apr_brigade_length(pair->value, 1, &len);
> +apr_brigade_length(pair->value, 1, (apr_off_t *)&len);
> 
> This seems really dangerous. Aren't there cases where sizeof(apr_size_t) != 
> sizeof(apr_off_t) ??
>  
>  fieldName = apr_pcalloc(r->pool, sizeof(char) * len + 1);
> -result = apr_brigade_flatten(pair->value, fieldName, &len);
> +result = apr_brigade_flatten(pair->value, fieldName, 
> (apr_size_t *)&len);
> 
> This seems unnecessary. &len should already be apr_size_t *
>  
>  }
>  else if (!strcmp(pair->name, "value")) {
>  apr_size_t len;
> -apr_brigade_length(pair->value, 1, &len);
> +apr_brigade_length(pair->value, 1, (apr_off_t *)&len);
>  fieldValue = apr_pcalloc(r->pool, sizeof(char) * len + 1);
> -result = apr_brigade_flatten(pair->value, fieldValue, &len);
> +result = apr_brigade_flatten(pair->value, fieldValue, 
> (apr_size_t *)&len);
> 
> These two, same as above.
> 
> Heh. I haven't reviewed httpd code for years. But I saw a change to 
> mod_authany.c and thought "what is that? isn't that module crazy stable?" ... 
> curiosity :-P
> 
> Cheers,
> -g
> 



Re: svn commit: r1703415 - in /httpd/test/framework/trunk/c-modules: authany/mod_authany.c test_session/mod_test_session.c

2015-09-16 Thread Greg Stein
On Wed, Sep 16, 2015 at 9:18 AM,  wrote:

> Author: jim
> Date: Wed Sep 16 14:18:49 2015
> New Revision: 1703415
>
>...

> Modified:
> httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c?rev=1703415&r1=1703414&r2=1703415&view=diff
>
> ==
> --- httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> (original)
> +++ httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> Wed Sep 16 14:18:49 2015
> @@ -149,7 +149,6 @@ static apr_status_t test_session_encode(
>
>  static apr_status_t test_session_decode(request_rec * r, session_rec * z)
>  {
> -apr_status_t result = OK;
>  const size_t prefix_len = strlen(TEST_SESSION_ENCODING_PREFIX);
>  test_session_dcfg_t *dconf = ap_get_module_config(r->per_dir_config,
>
>  &test_session_module);
> @@ -203,7 +202,7 @@ static int test_session_handler(request_
>  return DECLINED;
>
>  /* Copy the header for SessionHeader from the request to the
> response. */
> -if (overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER))
> +if ((overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER)))
>  apr_table_setn(r->headers_out, TEST_SESSION_HEADER, overrides);
>
>  /* Additional commands to test the session API via POST. */
> @@ -240,15 +239,15 @@ static int test_session_handler(request_
>  }
>  else if (!strcmp(pair->name, "name")) {
>  apr_size_t len;
> -apr_brigade_length(pair->value, 1, &len);
> +apr_brigade_length(pair->value, 1, (apr_off_t *)&len);
>

This seems really dangerous. Aren't there cases where sizeof(apr_size_t) !=
sizeof(apr_off_t) ??


>  fieldName = apr_pcalloc(r->pool, sizeof(char) * len + 1);
> -result = apr_brigade_flatten(pair->value, fieldName,
> &len);
> +result = apr_brigade_flatten(pair->value, fieldName,
> (apr_size_t *)&len);
>

This seems unnecessary. &len should already be apr_size_t *


>  }
>  else if (!strcmp(pair->name, "value")) {
>  apr_size_t len;
> -apr_brigade_length(pair->value, 1, &len);
> +apr_brigade_length(pair->value, 1, (apr_off_t *)&len);
>  fieldValue = apr_pcalloc(r->pool, sizeof(char) * len + 1);
> -result = apr_brigade_flatten(pair->value, fieldValue,
> &len);
> +result = apr_brigade_flatten(pair->value, fieldValue,
> (apr_size_t *)&len);
>

These two, same as above.

Heh. I haven't reviewed httpd code for years. But I saw a change to
mod_authany.c and thought "what is that? isn't that module crazy stable?"
... curiosity :-P

Cheers,
-g


Re: 2.4.17-protocols-http2/ - SNI issue

2015-09-16 Thread Ruediger Pluem


On 09/16/2015 12:16 PM, Yann Ylavic wrote:
> On Wed, Sep 16, 2015 at 12:04 PM, Plüm, Rüdiger, Vodafone Group
>  wrote:
>>
 Am 16.09.2015 um 11:36 schrieb Yann Ylavic :

 ISTM that the test should be:
if (strcasecmp(host, servername)
|| (sslconn->server
&& !ssl_util_vhost_matches(host, sslconn->server)))

 instead of:
   if (strcasecmp(host, servername)
|| !sslconn->server
|| !ssl_util_vhost_matches(host, sslconn->server))

 Not sure sslconn->server isn't NULL here for the first request.
>>
>> I shouldn't be.
> 
> Right, the issue is possibly here:
> 
> Index: modules/ssl/ssl_engine_kernel.c
> ===
> --- modules/ssl/ssl_engine_kernel.c(revision 1703149)
> +++ modules/ssl/ssl_engine_kernel.c(working copy)
> @@ -1937,7 +1937,7 @@ static apr_status_t init_vhost(conn_rec *c, SSL *s
>  if (c) {
>  SSLConnRec *sslcon = myConnConfig(c);
> 
> -if (sslcon->server != c->base_server) {
> +if (sslcon->server && sslcon->server != c->base_server) {
>  /* already found the vhost */
>  return APR_SUCCESS;
>  }
> --

I don't think that this is the issue, because of (from mod_ssl.c):

static SSLConnRec *ssl_init_connection_ctx(conn_rec *c)
{
SSLConnRec *sslconn = myConnConfig(c);

if (sslconn) {
return sslconn;
}

sslconn = apr_pcalloc(c->pool, sizeof(*sslconn));

sslconn->server = c->base_server;
sslconn->verify_depth = UNSET;

myConnConfigSet(c, sslconn);

return sslconn;
}


Regards

Rüdiger


Re: 2.4.17-protocols-http2/ - SNI issue

2015-09-16 Thread Yann Ylavic
On Wed, Sep 16, 2015 at 12:04 PM, Plüm, Rüdiger, Vodafone Group
 wrote:
>
>> > Am 16.09.2015 um 11:36 schrieb Yann Ylavic :
>> >
>> > ISTM that the test should be:
>> >if (strcasecmp(host, servername)
>> >|| (sslconn->server
>> >&& !ssl_util_vhost_matches(host, sslconn->server)))
>> >
>> > instead of:
>> >   if (strcasecmp(host, servername)
>> >|| !sslconn->server
>> >|| !ssl_util_vhost_matches(host, sslconn->server))
>> >
>> > Not sure sslconn->server isn't NULL here for the first request.
>
> I shouldn't be.

Right, the issue is possibly here:

Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c(revision 1703149)
+++ modules/ssl/ssl_engine_kernel.c(working copy)
@@ -1937,7 +1937,7 @@ static apr_status_t init_vhost(conn_rec *c, SSL *s
 if (c) {
 SSLConnRec *sslcon = myConnConfig(c);

-if (sslcon->server != c->base_server) {
+if (sslcon->server && sslcon->server != c->base_server) {
 /* already found the vhost */
 return APR_SUCCESS;
 }
--

> Maybe setting the loglevel to Debug could help to see the other SNI stuff 
> that was going on before and if it correctly identified the correct vhost via 
> SNI.

+1


RE: 2.4.17-protocols-http2/ - SNI issue

2015-09-16 Thread Plüm , Rüdiger , Vodafone Group


> -Original Message-
> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: Mittwoch, 16. September 2015 11:38
> To: dev@httpd.apache.org
> Subject: Re: 2.4.17-protocols-http2/ - SNI issue
> 
> Good point. Limited online today. If someone wants to give this a shot,
> please.
> 
> > Am 16.09.2015 um 11:36 schrieb Yann Ylavic :
> >
> > On Wed, Sep 16, 2015 at 11:24 AM, Plüm, Rüdiger, Vodafone Group
> >  wrote:
> >>
> >>> -Original Message-
> >>> From: Steffen
> >>> Sent: Mittwoch, 16. September 2015 11:14
> >>> To: dev@httpd.apache.org
> >>> Subject: 2.4.17-protocols-http2/ - SNI issue
> > []
> >>>
> >>> [ssl:error] [pid 3428:tid 3952] AH02032: Hostname www.apachelounge.com
> >>> provided via SNI and hostname www.apachelounge.com provided via HTTP
> >>> are different
> >>
> >> The above is very weird as both times we see www.apachelounge.com. Can
> you please check the logs with some kind of hex tool if there is really no
> difference between both strings? The logic to detect a difference in the
> code is just a usual strcasecmp. So I sense some hidden characters
> somewhere, which might give us a hint where things go really wrong.

Ahh I did miss that he used Stefans branch and not the 2.4.x branch.

> >
> > ISTM that the test should be:
> >if (strcasecmp(host, servername)
> >|| (sslconn->server
> >&& !ssl_util_vhost_matches(host, sslconn->server)))
> >
> > instead of:
> >   if (strcasecmp(host, servername)
> >|| !sslconn->server
> >|| !ssl_util_vhost_matches(host, sslconn->server))
> >
> > Not sure sslconn->server isn't NULL here for the first request.

I shouldn't be. Maybe setting the loglevel to Debug could help to see the other 
SNI stuff that was going on before and if it correctly identified the correct 
vhost via SNI.

Regards

Rüdiger


Re: 2.4.17-protocols-http2/ - SNI issue

2015-09-16 Thread Stefan Eissing
Good point. Limited online today. If someone wants to give this a shot, please. 

> Am 16.09.2015 um 11:36 schrieb Yann Ylavic :
> 
> On Wed, Sep 16, 2015 at 11:24 AM, Plüm, Rüdiger, Vodafone Group
>  wrote:
>> 
>>> -Original Message-
>>> From: Steffen
>>> Sent: Mittwoch, 16. September 2015 11:14
>>> To: dev@httpd.apache.org
>>> Subject: 2.4.17-protocols-http2/ - SNI issue
> []
>>> 
>>> [ssl:error] [pid 3428:tid 3952] AH02032: Hostname www.apachelounge.com
>>> provided via SNI and hostname www.apachelounge.com provided via HTTP
>>> are different
>> 
>> The above is very weird as both times we see www.apachelounge.com. Can you 
>> please check the logs with some kind of hex tool if there is really no 
>> difference between both strings? The logic to detect a difference in the 
>> code is just a usual strcasecmp. So I sense some hidden characters 
>> somewhere, which might give us a hint where things go really wrong.
> 
> ISTM that the test should be:
>if (strcasecmp(host, servername)
>|| (sslconn->server
>&& !ssl_util_vhost_matches(host, sslconn->server)))
> 
> instead of:
>   if (strcasecmp(host, servername)
>|| !sslconn->server
>|| !ssl_util_vhost_matches(host, sslconn->server))
> 
> Not sure sslconn->server isn't NULL here for the first request.
> 
> Regards,
> Yann.


Re: 2.4.17-protocols-http2/ - SNI issue

2015-09-16 Thread Yann Ylavic
On Wed, Sep 16, 2015 at 11:24 AM, Plüm, Rüdiger, Vodafone Group
 wrote:
>
>> -Original Message-
>> From: Steffen
>> Sent: Mittwoch, 16. September 2015 11:14
>> To: dev@httpd.apache.org
>> Subject: 2.4.17-protocols-http2/ - SNI issue
[]
>>
>> [ssl:error] [pid 3428:tid 3952] AH02032: Hostname www.apachelounge.com
>> provided via SNI and hostname www.apachelounge.com provided via HTTP
>> are different
>
> The above is very weird as both times we see www.apachelounge.com. Can you 
> please check the logs with some kind of hex tool if there is really no 
> difference between both strings? The logic to detect a difference in the code 
> is just a usual strcasecmp. So I sense some hidden characters somewhere, 
> which might give us a hint where things go really wrong.

ISTM that the test should be:
if (strcasecmp(host, servername)
|| (sslconn->server
&& !ssl_util_vhost_matches(host, sslconn->server)))

instead of:
   if (strcasecmp(host, servername)
|| !sslconn->server
|| !ssl_util_vhost_matches(host, sslconn->server))

Not sure sslconn->server isn't NULL here for the first request.

Regards,
Yann.


RE: 2.4.17-protocols-http2/ - SNI issue

2015-09-16 Thread Plüm , Rüdiger , Vodafone Group


> -Original Message-
> From: Steffen 
> Sent: Mittwoch, 16. September 2015 11:14
> To: dev@httpd.apache.org
> Subject: 2.4.17-protocols-http2/ - SNI issue
> 
> 
> Build under Windows /httpd/httpd/branches/2.4.17-protocols-http2
> (Revision: 1703138) with nghttp2 v1.3.1
> 
> Was building fine, but running no go.
> 
> Using latest Chrome browser to test.
> 
> Using exact the same config as with 2.4.16, only added in server
> config:
> 
> 
> LoadModule h2_module modules/mod_h2.so
> 
> 
>   ProtocolsHonorOrder On
>   Protocols h2c h2 http/1.1
>  
> 
> I get this error in Chrome now, with 2.4.16 all fine:
> 
> 
> Misdirected Request. The client needs a new connection for this
> request as the requested host name does not match the Server Name
> Indication (SNI) in use for this connection.
> 
> Chrome shows it is using the H2 protocol.
> 
> 
> In the error and access log:
> 
> 
> 
> [ssl:error] [pid 3428:tid 3952] AH02032: Hostname www.apachelounge.com
> provided via SNI and hostname www.apachelounge.com provided via HTTP
> are different

The above is very weird as both times we see www.apachelounge.com. Can you 
please check the logs with some kind of hex tool if there is really no 
difference between both strings? The logic to detect a difference in the code 
is just a usual strcasecmp. So I sense some hidden characters somewhere, which 
might give us a hint where things go really wrong.

Regards

Rüdiger



2.4.17-protocols-http2/ - SNI issue

2015-09-16 Thread Steffen


Build under Windows /httpd/httpd/branches/2.4.17-protocols-http2 
(Revision: 1703138) with nghttp2 v1.3.1


Was building fine, but running no go.

Using latest Chrome browser to test.

Using exact the same config as with 2.4.16, only added in server 
config:



LoadModule h2_module modules/mod_h2.so


 ProtocolsHonorOrder On
 Protocols h2c h2 http/1.1


I get this error in Chrome now, with 2.4.16 all fine:


Misdirected Request. The client needs a new connection for this 
request as the requested host name does not match the Server Name 
Indication (SNI) in use for this connection.


Chrome shows it is using the H2 protocol.


In the error and access log:



[ssl:error] [pid 3428:tid 3952] AH02032: Hostname www.apachelounge.com 
provided via SNI and hostname www.apachelounge.com provided via HTTP 
are different


www.apachelounge.com 66.249.78.32 - - [16/Sep/2015:10:06:35 +0200] 
TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /viewtopic.php?p=1 
HTTP/1.1" 421 322 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; 
+http://www.google.com/bot.html)"



When I run with with the IP Chrome all looks fine, Chrome shoes  it is 
using the H2 protocol.



https://[2001:980:a510:1:d571:caed:72a0:9e9b]/  looks good
https://www.apachelounge.com/  above error