Re: Broken 2.4 ./configure

2015-12-04 Thread William A Rowe Jr
On Wed, Dec 2, 2015 at 5:24 PM, Stefan Eissing  wrote:

> I put it on my TODO for friday, maybe I can conf/ifdef around it without
> too much pain.
>
> Am 02.12.2015 um 23:16 schrieb William A Rowe Jr :
>
> On Wed, Dec 2, 2015 at 3:06 PM, Reindl Harald 
> wrote:
>
>>
>> Am 02.12.2015 um 21:53 schrieb William A Rowe Jr:
>>
>>> It seems nghttp2 1.2.1 is no longer supported?  If we are missing an
>>> #include, let's fix, and if we want to drop support, that's fine too, but
>>> ./configure needs to reject the invalid version of nghttp2.
>>
>>
> Note that we couldn't normally drop support for an older nghttp2,
> but mod_http2 was clearly tagged as experimental, so packagers
> who pick it up and enable it are responsible for keeping up.
>
> Reindl identifies one distribution that will be immediately burned
> by picking up 2.4.18 without also bumping nghttp2 to 1.3 or later...
>
> This is the version shipping on FC22...
>>> nghttp2.x86_64   1.2.1-1.fc22
>>>
>>
>> unconfirmed
>>
>> [builduser@buildserver:~]$ rpm -q httpd
>> httpd-2.4.17-2.fc22.20151012.rh.x86_64
>>
>
> We are on two different pages, I'm speaking of branches/2.4.x at
> 2.4.18-dev,
> based on current backports.  I wasn't commenting on the previous release.
>
>
I'm glad you can look at this over the weekend. I am just fine with
demanding a different version of nghttp2, or deciding on a baseline
and then offering "more correct" functionality on another rev level.
I expect most of dev@httpd will agree since we declared this all
experimental.

Off topic, can you explain why core Upgrade requests are dealt with
as a 'handler', since they are protocol layer details? the "core upgrade"
''handler'' is sort of oxymoronic, since upgrade is one protocol to another
in the course of a specific received request, and it the implementation
appears to break all http rfcs?  There is no way to incorporate the
prior/initial TLS/n.n upgrade, per spec, in this current schema as
implemented.

I hope we can revert/fix/enhance prior to 2.4.18 'working' release?

Cheers,

Bill


Re: Broken 2.4 ./configure

2015-12-04 Thread Stefan Eissing
mod_http2 in /trunk now checks for a minimum nghttp2 version of 1.2.1 and 
#ifdefs code accordingly. Will backport to 2.4.x later together with other 
changes.

> Am 04.12.2015 um 09:19 schrieb William A Rowe Jr :
> 
> On Wed, Dec 2, 2015 at 5:24 PM, Stefan Eissing  
> wrote:
> I put it on my TODO for friday, maybe I can conf/ifdef around it without too 
> much pain. 
> 
> Am 02.12.2015 um 23:16 schrieb William A Rowe Jr :
> 
>> On Wed, Dec 2, 2015 at 3:06 PM, Reindl Harald  wrote:
>> 
>> Am 02.12.2015 um 21:53 schrieb William A Rowe Jr:
>> It seems nghttp2 1.2.1 is no longer supported?  If we are missing an
>> #include, let's fix, and if we want to drop support, that's fine too, but
>> ./configure needs to reject the invalid version of nghttp2.
>>  
>> Note that we couldn't normally drop support for an older nghttp2, 
>> but mod_http2 was clearly tagged as experimental, so packagers
>> who pick it up and enable it are responsible for keeping up.
>> 
>> Reindl identifies one distribution that will be immediately burned
>> by picking up 2.4.18 without also bumping nghttp2 to 1.3 or later...
>> 
>> This is the version shipping on FC22...
>> nghttp2.x86_64   1.2.1-1.fc22
>> 
>> unconfirmed
>> 
>> [builduser@buildserver:~]$ rpm -q httpd
>> httpd-2.4.17-2.fc22.20151012.rh.x86_64
>> 
>> We are on two different pages, I'm speaking of branches/2.4.x at 2.4.18-dev,
>> based on current backports.  I wasn't commenting on the previous release. 
>> 
> 
> I'm glad you can look at this over the weekend. I am just fine with
> demanding a different version of nghttp2, or deciding on a baseline
> and then offering "more correct" functionality on another rev level.
> I expect most of dev@httpd will agree since we declared this all
> experimental.
> 
> Off topic, can you explain why core Upgrade requests are dealt with
> as a 'handler', since they are protocol layer details? the "core upgrade"
> ''handler'' is sort of oxymoronic, since upgrade is one protocol to another
> in the course of a specific received request, and it the implementation
> appears to break all http rfcs?  There is no way to incorporate the 
> prior/initial TLS/n.n upgrade, per spec, in this current schema as
> implemented.
> 
> I hope we can revert/fix/enhance prior to 2.4.18 'working' release?
> 
> Cheers,
> 
> Bill
> 
> 



Broken 2.4 ./configure

2015-12-02 Thread William A Rowe Jr
It seems nghttp2 1.2.1 is no longer supported?  If we are missing an
#include,
let's fix, and if we want to drop support, that's fine too, but ./configure
needs
to reject the invalid version of nghttp2.  This is the version shipping on
FC22...
nghttp2.x86_64   1.2.1-1.fc22


checking for nghttp2... checking for user-provided nghttp2 base
directory... none
checking for pkg-config along ...   setting MOD_CFLAGS to ""
  setting ab_CFLAGS to ""
  setting MOD_LDFLAGS to ""
  setting MOD_LDFLAGS to ""
checking for nghttp2 version >= 1.0.0... OK
  setting MOD_LDFLAGS to "-lnghttp2   -luuid -lrt -lcrypt  -lpthread -ldl"
  setting LIBS to "-lnghttp2   -luuid -lrt -lcrypt  -lpthread -ldl"
  forcing ab_LDFLAGS to "-lnghttp2   -luuid -lrt -lcrypt  -lpthread -ldl"
checking nghttp2/nghttp2.h usability... yes
checking nghttp2/nghttp2.h presence... yes
checking for nghttp2/nghttp2.h... yes
checking for nghttp2_session_server_new2... yes
checking for nghttp2_session_change_stream_priority... no
yes
  setting MOD_HTTP2_LDADD to "-export-symbols-regex http2_module"
checking whether to enable mod_http2... shared (all)


/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c:104:31: error: unknown
type name 'nghttp2_stream'
 static int spri_cmp(int sid1, nghttp2_stream *s1,
   ^
/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c:105:31: error: unknown
type name 'nghttp2_stream'
 int sid2, nghttp2_stream *s2, h2_session *session)
   ^
/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c: In function
'stream_pri_cmp':
/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c:133:5: error: unknown
type name 'nghttp2_stream'
 nghttp2_stream *s1, *s2;
 ^
/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c:135:10: warning:
implicit declaration of function 'nghttp2_session_find_stream'
[-Wimplicit-function-declaration]
 s1 = nghttp2_session_find_stream(session->ngh2, sid1);
  ^
/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c:135:8: warning:
assignment makes pointer from integer without a cast [-Wint-conversion]
 s1 = nghttp2_session_find_stream(session->ngh2, sid1);
^
/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c:136:8: warning:
assignment makes pointer from integer without a cast [-Wint-conversion]
 s2 = nghttp2_session_find_stream(session->ngh2, sid2);
^
/home/wrowe/dev/httpd-2.4/modules/http2/h2_session.c:147:12: warning:
implicit declaration of function 'spri_cmp'
[-Wimplicit-function-declaration]
 return spri_cmp(sid1, s1, sid2, s2, session);
^
/home/wrowe/dev/build/httpd24-apr15-ossl102/build/rules.mk:212: recipe for
target 'h2_session.slo' failed


Re: Broken 2.4 ./configure

2015-12-02 Thread Reindl Harald



Am 02.12.2015 um 21:53 schrieb William A Rowe Jr:

It seems nghttp2 1.2.1 is no longer supported?  If we are missing an
#include,
let's fix, and if we want to drop support, that's fine too, but
./configure needs
to reject the invalid version of nghttp2.  This is the version shipping
on FC22...
nghttp2.x86_64   1.2.1-1.fc22


unconfirmed

[builduser@buildserver:~]$ rpm -q httpd
httpd-2.4.17-2.fc22.20151012.rh.x86_64

[builduser@buildserver:~]$ rpm -q libnghttp2-devel
libnghttp2-devel-1.2.1-1.fc22.x86_64

[builduser@buildserver:~]$ ls 
/repo/fc22/x86_64/mod_http2-2.4.17-2.fc22.20151012.rh.x86_64.rpm
-rw-r--r-- 1 builduser builduser 81K 2015-10-12 12:44 
/repo/fc22/x86_64/mod_http2-2.4.17-2.fc22.20151012.rh.x86_64.rpm


[builduser@buildserver:~]$ cat /rpmbuild/SPECS/httpd.spec | grep http2
BuildRequires: libnghttp2-devel
%package -nmod_http2
Summary:   mod_http2 for the Apache HTTP Server
Provides:  mod_http2 = %{version}-%{release}
%description -nmod_http2
%files -n mod_http2
%{_libdir}/%{name}/modules/mod_http2.so



signature.asc
Description: OpenPGP digital signature


Re: Broken 2.4 ./configure

2015-12-02 Thread William A Rowe Jr
On Wed, Dec 2, 2015 at 3:06 PM, Reindl Harald 
wrote:

>
> Am 02.12.2015 um 21:53 schrieb William A Rowe Jr:
>
>> It seems nghttp2 1.2.1 is no longer supported?  If we are missing an
>> #include, let's fix, and if we want to drop support, that's fine too, but
>> ./configure needs to reject the invalid version of nghttp2.
>
>
Note that we couldn't normally drop support for an older nghttp2,
but mod_http2 was clearly tagged as experimental, so packagers
who pick it up and enable it are responsible for keeping up.

Reindl identifies one distribution that will be immediately burned
by picking up 2.4.18 without also bumping nghttp2 to 1.3 or later...

This is the version shipping on FC22...
>> nghttp2.x86_64   1.2.1-1.fc22
>>
>
> unconfirmed
>
> [builduser@buildserver:~]$ rpm -q httpd
> httpd-2.4.17-2.fc22.20151012.rh.x86_64
>

We are on two different pages, I'm speaking of branches/2.4.x at 2.4.18-dev,
based on current backports.  I wasn't commenting on the previous release.


Re: Broken 2.4 ./configure

2015-12-02 Thread William A Rowe Jr
On Dec 2, 2015 17:25, "Stefan Eissing"  wrote:
>
> I put it on my TODO for friday, maybe I can conf/ifdef around it without
too much pain.

If we lose functionality between nghttp2 1.x (bare minimum) and 1.y
(optimal, supports all mod_http2 functionality), we might set the minimum
rev 1.x allowed to enable mod_http2, but emit a stderr warning at configure
(and perhaps compilation) if version 1.y is not detected.


Re: Broken 2.4 ./configure

2015-12-02 Thread Stefan Eissing
I put it on my TODO for friday, maybe I can conf/ifdef around it without too 
much pain. 

> Am 02.12.2015 um 23:16 schrieb William A Rowe Jr :
> 
>> On Wed, Dec 2, 2015 at 3:06 PM, Reindl Harald  wrote:
>> 
>>> Am 02.12.2015 um 21:53 schrieb William A Rowe Jr:
>>> It seems nghttp2 1.2.1 is no longer supported?  If we are missing an
>>> #include, let's fix, and if we want to drop support, that's fine too, but
>>> ./configure needs to reject the invalid version of nghttp2.
>  
> Note that we couldn't normally drop support for an older nghttp2, 
> but mod_http2 was clearly tagged as experimental, so packagers
> who pick it up and enable it are responsible for keeping up.
> 
> Reindl identifies one distribution that will be immediately burned
> by picking up 2.4.18 without also bumping nghttp2 to 1.3 or later...
> 
>>> This is the version shipping on FC22...
>>> nghttp2.x86_64   1.2.1-1.fc22
>> 
>> unconfirmed
>> 
>> [builduser@buildserver:~]$ rpm -q httpd
>> httpd-2.4.17-2.fc22.20151012.rh.x86_64
> 
> We are on two different pages, I'm speaking of branches/2.4.x at 2.4.18-dev,
> based on current backports.  I wasn't commenting on the previous release. 
>