proxy_http:error (20014)Internal error

[Petr Sumbera]

Hi,

we have got several reports similar to:

https://bz.apache.org/bugzilla/show_bug.cgi?id=63229

One is:

Tue Feb 25 09:17:53.486933 2020] [proxy_http:error] [pid 27500:tid 9]
(20014)Internal error (specific information not available): [client
XXX:XXX] AH01102: error reading status line from remote server
XXX:XXX

The other is:

[Thu Mar 12 05:37:57.789117 2020] [proxy:error] [pid 26426:tid 22]
(20014)Internal error (specific information not available): [client
XXX:XXX] AH01084: pass request body failed to XXX:XXX (XXX)
[Thu Mar 12 05:37:57.789171 2020] [proxy:error] [pid 26426:tid 22] [client
XXX:XXX] AH00898: Error during SSL Handshake with remote server
returned by /XXX

I see that the "Internal error" (APR_EGENERAL) is probably coming from 
server/protocol.c and ap_rgetline_core(). But  have no idea what it 
actually can mean.


Any idea or suggestion?

Thank you!

Petr

SSLStrictSNIVHostCheck not being enforced by mod_ssl

[Alex Hautequest]

"SSLStrictSNIVHostCheck On” directive in either _default_ or specific vhost 
entry has no effect: clients not forced to provide SNI data for web site access.

Environment:
- Standard HTTPD 2.4.43 and OpenSSL 1.1.1f builds from Pat Volkerdi’ Slackware 
-current.

Enabled "LogLevel debug”, not seeing *anything* SNI related in the logs.

Ideas?

--
Alex

Re: proxy_http:error (20014)Internal error

[Ruediger Pluem]

On 4/14/20 10:02 PM, Petr Sumbera wrote:
> Hi,
> 
> we have got several reports similar to:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63229
> 
> One is:
> 
> Tue Feb 25 09:17:53.486933 2020] [proxy_http:error] [pid 27500:tid 9]
> (20014)Internal error (specific information not available): [client
> XXX:XXX] AH01102: error reading status line from remote server
> XXX:XXX


Difficult to say what the real root cause is. May require further log lines, 
probably at higher log levels.
So if you don't have them and you cannot reproduce it, it likely remains 
unresolved.

> 
> The other is:
> 
> [Thu Mar 12 05:37:57.789117 2020] [proxy:error] [pid 26426:tid 22]
> (20014)Internal error (specific information not available): [client
> XXX:XXX] AH01084: pass request body failed to XXX:XXX (XXX)
> [Thu Mar 12 05:37:57.789171 2020] [proxy:error] [pid 26426:tid 22] [client
> XXX:XXX] AH00898: Error during SSL Handshake with remote server
> returned by /XXX

In this case the SSL handshake with the backend server failed for some reason.

Regards

Rüdiger

Re: SSLStrictSNIVHostCheck not being enforced by mod_ssl

[Ruediger Pluem]

On 4/15/20 4:50 AM, Alex Hautequest wrote:
> "SSLStrictSNIVHostCheck On” directive in either _default_ or specific vhost 
> entry has no effect: clients not forced to provide SNI
> data for web site access.
> 
> Environment:
> - Standard HTTPD 2.4.43 and OpenSSL 1.1.1f builds from Pat Volkerdi’ 
> Slackware -current.
> 
> Enabled "LogLevel debug”, not seeing *anything* SNI related in the logs.
> 
> Ideas?

Please provide the setup of your virtual hosts (the virtualhost container 
directives and the servername directives within) and a
request that behaves in the wrong way.

Regards

Rüdiger

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Steffen]

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Rainer Jung]

Sorry, that was a bit to fast: looking at the revision, he references file

modules/http2/h2_bucket_beam.h

But in that revision the change was the removal of a struct member at 
the end of the struct. I don't see, how that could lead to a crash in 
case an old header file was used, that would sill contain that - now 
unused - struct member?


Regards,

Rainer

Am 14.04.2020 um 11:05 schrieb Rainer Jung:

Hi Stefen,

I think Stefan refers to his "somehow was partially using the old header 
file". So during the build, there should be no other (from other 
versions) header files from APR, APR-UTIL oder HTTPD anywhere on the 
build system where the build process might find and use them.


He was assuming, that the build that had the crashes was possibly done 
on a system, which did not fulfil this requirement.


Regards,

Rainer

Am 14.04.2020 um 10:13 schrieb Steffen:


What do you mean with a clean rebuild ?

r1874909 (1.15.8) is the one from  httpd 2.4.43 GA.


On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote:
In that revision, I see a change in the header file structure. If 
your build of r1874909 is not clean but somehow was partially using 
the old header file, things might get misaligned.


The other changes in that revision look rather unsuspicious to me.

Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to 
verify? Thanks!


Cheers, Stefan


Am 12.04.2020 um 15:57 schrieb mdrmdr :

With the help of Steffen (he built the Windows binaries for me) I 
can report:


r1861247 - works
r1864126 - works
r1872230 - works
r1873368 - works
r1874286 - works
r1874347 - works
r1874909 (=2.4.43) - fails!



--
Sent from: 
http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html 

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Stefan Eissing]

Thanks Rainer! That's what I meant.

> Am 14.04.2020 um 11:05 schrieb Rainer Jung :
> 
> Hi Stefen,
> 
> I think Stefan refers to his "somehow was partially using the old header 
> file". So during the build, there should be no other (from other versions) 
> header files from APR, APR-UTIL oder HTTPD anywhere on the build system where 
> the build process might find and use them.
> 
> He was assuming, that the build that had the crashes was possibly done on a 
> system, which did not fulfil this requirement.
> 
> Regards,
> 
> Rainer
> 
> Am 14.04.2020 um 10:13 schrieb Steffen:
>> What do you mean with a clean rebuild ?
>> r1874909 (1.15.8) is the one from  httpd 2.4.43 GA.
>> On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote:
>>> In that revision, I see a change in the header file structure. If your 
>>> build of r1874909 is not clean but somehow was partially using the old 
>>> header file, things might get misaligned.
>>> 
>>> The other changes in that revision look rather unsuspicious to me.
>>> 
>>> Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to verify? 
>>> Thanks!
>>> 
>>> Cheers, Stefan
>>> 
 Am 12.04.2020 um 15:57 schrieb mdrmdr :
 
 With the help of Steffen (he built the Windows binaries for me) I can 
 report:
 
 r1861247 - works
 r1864126 - works
 r1872230 - works
 r1873368 - works
 r1874286 - works
 r1874347 - works
 r1874909 (=2.4.43) - fails!
 
 
 
 --
 Sent from: 
 http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Steffen]

Thanks Rainer,

All clean build using the released sources, so a clean build of httpd 
2.4.43 GA gives the crash.


What header file is Stefan referring ?


On Tuesday 14/04/2020 at 11:06, Rainer Jung  wrote:

Hi Stefen,

I think Stefan refers to his "somehow was partially using the old 
header file". So during the build, there should be no other (from 
other versions) header files from APR, APR-UTIL oder HTTPD anywhere on 
the build system where the build process might find and use them.


He was assuming, that the build that had the crashes was possibly done 
on a system, which did not fulfil this requirement.


Regards,

Rainer

Am 14.04.2020 um 10:13 schrieb Steffen:


What do you mean with a clean rebuild ?
r1874909 (1.15.8) is the one from  httpd 2.4.43 GA.
On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote:


In that revision, I see a change in the header file structure. If your 
 build of r1874909 is not clean but somehow was partially using the 
old  header file, things might get misaligned.


The other changes in that revision look rather unsuspicious to me.

Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to  
verify? Thanks!


Cheers, Stefan



Am 12.04.2020 um 15:57 schrieb mdrmdr :

With the help of Steffen (he built the Windows binaries for me) I can  
report:


r1861247 - works
r1864126 - works
r1872230 - works
r1873368 - works
r1874286 - works
r1874347 - works
r1874909 (=2.4.43) - fails!



--
Sent from: 
http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Stefan Eissing]

In that revision, I see a change in the header file structure. If your build of 
r1874909 is not clean but somehow was partially using the old header file, 
things might get misaligned.

The other changes in that revision look rather unsuspicious to me. 

Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to verify? 
Thanks!

Cheers, Stefan

> Am 12.04.2020 um 15:57 schrieb mdrmdr :
> 
> With the help of Steffen (he built the Windows binaries for me) I can report:
> 
> r1861247 - works
> r1864126 - works
> r1872230 - works
> r1873368 - works
> r1874286 - works
> r1874347 - works
> r1874909 (=2.4.43) - fails!
> 
> 
> 
> --
> Sent from: 
> http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Steffen]

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Ruediger Pluem]

On 4/14/20 11:20 AM, Stefan Eissing wrote:
> mdr wrote that you found out the crash came with the change in r1874909. If 
> you build before, it works, if you build with r1874909, it crashes. And I 
> cannot see why...

Does this crash happen outside of Windows e.g. Linux as well?

Regards

Rüdiger

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Steffen]

Few posts above there is a GDB back trace.



On Tuesday 14/04/2020 at 11:38, Ruediger Pluem  wrote:


Did I miss it, or isn't there any stacktrace posted from the Windows 
crashes yet?


Regards

Rüdiger

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Steffen]

This is the post above of backtrace

By accident I've seen that Perl comes with GDB. This might help as 
well.
I called httpd.exe from GDB with "-X -e debug" and then called a Perl 
URL in the browser.


Excerpt below:

Thread 100 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4936.0x23e0]
0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
X:\Apps\Apache24\bin\libhttpd.dll

(gdb) bt
#0  0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
X:\Apps\Apache24\bin\libhttpd.dll
#1  0x7ffbe44d14aa in ?? () from 
X:\Apps\Apache24\modules\mod_cgi.so
#2  0x7ffbe575ee85 in libhttpd!ap_run_handler () from 
X:\Apps\Apache24\bin\libhttpd.dll
#3  0x7ffbe575da7f in libhttpd!ap_invoke_handler () from 
X:\Apps\Apache24\bin\libhttpd.dll
#4  0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () 
from X:\Apps\Apache24\bin\libhttpd.dll
#5  0x7ffbe575a6af in libhttpd!ap_process_request () from 
X:\Apps\Apache24\bin\libhttpd.dll
#6  0x7ffbe22888ef in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#7  0x7ffbe5761545 in libhttpd!ap_run_process_connection () from 
X:\Apps\Apache24\bin\libhttpd.dll
#8  0x7ffbe22885ba in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#9  0x7ffbe228c36e in ?? () from 
X:\Apps\Apache24\modules\mod_http2.so
#10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from 
C:\Windows\System32\ucrtbase.dll
#11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from 
C:\Windows\System32\kernel32.dll
#12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from 
C:\Windows\SYSTEM32\ntdll.dll

#13 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)



On Tuesday 14/04/2020 at 11:57, Rainer Jung  wrote:

Hi Steffen,

I didn't find a stack either, neither in the mail thread here nor in 
the one on you forum. Just the error log lines and the clear text for 
the windows error code.


Regards,

Rainer

Am 14.04.2020 um 11:51 schrieb Steffen:


Few posts above there is a GDB back trace.
On Tuesday 14/04/2020 at 11:38, Ruediger Pluem wrote:



Did I miss it, or isn't there any stacktrace posted from the Windows  
crashes yet?


Regards

Rüdiger

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Stefan Eissing]

mdr wrote that you found out the crash came with the change in r1874909. If you 
build before, it works, if you build with r1874909, it crashes. And I cannot 
see why...

Stefan Eissing

bytes GmbH
Hafenweg 16
48155 Münster
www.greenbytes.de

> Am 14.04.2020 um 11:14 schrieb Steffen :
> 
> 
> 
> Thanks Rainer,
> 
> All clean build using the released sources, so a clean build of httpd 2.4.43 
> GA gives the crash.
> 
> What header file is Stefan referring ?
> 
> 
> On Tuesday 14/04/2020 at 11:06, Rainer Jung  wrote:
>> Hi Stefen,
>> 
>> I think Stefan refers to his "somehow was partially using the old header 
>> file". So during the build, there should be no other (from other versions) 
>> header files from APR, APR-UTIL oder HTTPD anywhere on the build system 
>> where the build process might find and use them.
>> 
>> He was assuming, that the build that had the crashes was possibly done on a 
>> system, which did not fulfil this requirement.
>> 
>> Regards,
>> 
>> Rainer
>> 
>> Am 14.04.2020 um 10:13 schrieb Steffen:
>>> 
>>> What do you mean with a clean rebuild ?
>>> r1874909 (1.15.8) is the one from  httpd 2.4.43 GA.
>>> On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote:
 
 In that revision, I see a change in the header file structure. If your  
 build of r1874909 is not clean but somehow was partially using the old  
 header file, things might get misaligned.
 
 The other changes in that revision look rather unsuspicious to me.
 
 Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to  
 verify? Thanks!
 
 Cheers, Stefan
 
> 
> Am 12.04.2020 um 15:57 schrieb mdrmdr :
> 
> With the help of Steffen (he built the Windows binaries for me) I can  
> report:
> 
> r1861247 - works
> r1864126 - works
> r1872230 - works
> r1873368 - works
> r1874286 - works
> r1874347 - works
> r1874909 (=2.4.43) - fails!
> 
> 
> 
> --
> Sent from: 
> http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
> 
> 
> 

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Ruediger Pluem]

On 4/14/20 11:36 AM, Ruediger Pluem wrote:
> 
> 
> On 4/14/20 11:20 AM, Stefan Eissing wrote:
>> mdr wrote that you found out the crash came with the change in r1874909. If 
>> you build before, it works, if you build with r1874909, it crashes. And I 
>> cannot see why...
> 
> Does this crash happen outside of Windows e.g. Linux as well?
> 

Did I miss it, or isn't there any stacktrace posted from the Windows crashes 
yet?

Regards

Rüdiger

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Rainer Jung]

Hi Steffen,

I didn't find a stack either, neither in the mail thread here nor in the 
one on you forum. Just the error log lines and the clear text for the 
windows error code.


Regards,

Rainer

Am 14.04.2020 um 11:51 schrieb Steffen:

Few posts above there is a GDB back trace.

On Tuesday 14/04/2020 at 11:38, Ruediger Pluem wrote:


Did I miss it, or isn't there any stacktrace posted from the Windows 
crashes yet?


Regards

Rüdiger

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Rainer Jung]

Hi Stefen,

I think Stefan refers to his "somehow was partially using the old header 
file". So during the build, there should be no other (from other 
versions) header files from APR, APR-UTIL oder HTTPD anywhere on the 
build system where the build process might find and use them.


He was assuming, that the build that had the crashes was possibly done 
on a system, which did not fulfil this requirement.


Regards,

Rainer

Am 14.04.2020 um 10:13 schrieb Steffen:


What do you mean with a clean rebuild ?

r1874909 (1.15.8) is the one from  httpd 2.4.43 GA.


On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote:
In that revision, I see a change in the header file structure. If your 
build of r1874909 is not clean but somehow was partially using the old 
header file, things might get misaligned.


The other changes in that revision look rather unsuspicious to me.

Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to 
verify? Thanks!


Cheers, Stefan


Am 12.04.2020 um 15:57 schrieb mdrmdr :

With the help of Steffen (he built the Windows binaries for me) I can 
report:


r1861247 - works
r1864126 - works
r1872230 - works
r1873368 - works
r1874286 - works
r1874347 - works
r1874909 (=2.4.43) - fails!



--
Sent from: 
http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: Building from svn on MacOS

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

William,

On 4/13/20 17:27, William A Rowe Jr wrote:
> On Mon, Apr 13, 2020 at 4:21 PM Christopher Schultz
>  > wrote:
>
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>
> William,
>
>>> I'm having some trouble building 2.4.x directly from svn.
>>>
>>> MacOS 10.14.6 (Mojave)
>>
>> I note you mentioned apr 1.7.0. If you grab and pre build apr,
>> and then apr-util (and openssl and anything else you want to
>> refresh) or install the compiled system package, it should work.
>> Point at them --with-apr plus --with-aprutil.
>
> I'm using brew which is like the missing package manager for
> macos. I've installed apr and apr-util which I thikn are both
> binary packages. I reconfigured with:
>
> $ ./buildconf
> --with-apr=/usr/local/Cellar/apr/1.7.0/bin/apr-1-config -
> --with-apr-util=/usr/local/Cellar/apr-util/1.6.1_3/bin/apu-1-config
>
>  I get this output:
>
> using apr-config version 1.7.0 ./buildconf: line 249: cd:
> /usr/local/Cellar/apr-util/1.6.1_3/bin/apu-1-config: Not a
> directory copying build files
>
>
> That's your answer. It wants the parent path of the apr/apr-util
> installations, not the name of the apr-1-config file. It will work
> out bin/apr-1-config... etc.

Yeah, I tried backing-out with that, too, and buildconf no longer
complained about the missing directory. But configure still failed
with the same error :(

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6VvM4ACgkQHPApP6U8
pFgsShAAgqgAhKOPQsKi+HQRwvyTcZrC89xu5VX2ps3G2oyxWsouSdNOZgBO4ffI
6smRYpUh5sWXz3m0zh21YHtOKPVXaWfibQq7amD/FI/nTdEJ8AZC2E8PiAZ6MC4W
Vz3LvX07zeANHi58USMqmKf2HMdv0Hi1OHEsDHB9Xtp9KG8AyMm+UpPhm1jWo16k
GxqcgNjx8+ad8KQG1KtQxxamxqXIRFgzMj47wLbr4K3R/VOeTp7ekHWSLOW0Ipr4
EO76cFvjVp+1O850uC+1QN4RR8RzFzWuxJRQ0Ft82y9Ca/ZOgb4kMQYC2HqmPZW0
V2LWwKeYYZv2UbcY/Vp3aCwnFReEhi0U165OD4ApDqYb3Bp01kukdsvJQh+NkXB5
YXpMiREI3eR08N0VsI40yFjd62LFZXlx7qsPi4AbbK6ggyoiCVjD3O/c+us+GU+9
UJmlEQ5yxr+aJI7UB53HXn+aze0gVBVOXWobXEk1aNpW0zaNZcYUCKYFPHEItuyA
VUWegPwJ/KZTYmmbebladSq51dj2WsT60+qGo/eW2bTEvtk41zPIqd7SatTdExpQ
TBq3AXDXHuD061w1rGkons1ax0Hl59jDMvCOnNTGrPCONQA1w39eQxkHSlPVIdMf
Y7F9U9K0RRqQaKrY/uYJBxO8lXMI0q5/5WDRiNcZ3TCxSEhaNpQ=
=n8JV
-END PGP SIGNATURE-

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Ruediger Pluem]

On 4/14/20 12:22 PM, Steffen wrote:
> 
> 
> This is the post above of backtrace

Thanks.

> 
> By accident I've seen that Perl comes with GDB. This might help as well.
> I called httpd.exe from GDB with "-X -e debug" and then called a Perl URL in 
> the browser.
> 
> Excerpt below:
> 

Somehow the below wasn't visible in the original mail.

> Thread 100 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 4936.0x23e0]
> 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> (gdb) bt
> #0  0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #1  0x7ffbe44d14aa in ?? () from X:\Apps\Apache24\modules\mod_cgi.so
> #2  0x7ffbe575ee85 in libhttpd!ap_run_handler () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #3  0x7ffbe575da7f in libhttpd!ap_invoke_handler () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #4  0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #5  0x7ffbe575a6af in libhttpd!ap_process_request () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #6  0x7ffbe22888ef in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> #7  0x7ffbe5761545 in libhttpd!ap_run_process_connection () from 
> X:\Apps\Apache24\bin\libhttpd.dll
> #8  0x7ffbe22885ba in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> #9  0x7ffbe228c36e in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> #10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from 
> C:\Windows\System32\ucrtbase.dll
> #11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from 
> C:\Windows\System32\kernel32.dll
> #12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from 
> C:\Windows\SYSTEM32\ntdll.dll
> #13 0x in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
> 


Unfortunately this stacktrace does not help. One reason might be that the 
debugging symbols are missing.
It is very strange that it segfaults in ap_get_server_built, a simple function 
just returning a pointer
to a static string constant. Furthermore ap_get_server_built is not called by 
mod_cgi.
Can the crash be repeated against a binary with debugging symbols that are then 
used to generate the stacktrace?
As I am not a Windows guy, I unfortunately cannot provide any instructions how 
to do this.

Regards

Rüdiger

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Stefan Eissing]

Just to confirm:

Did you build the r1874909 just like the other releases you tested or did you 
use the already built 2.4.43 that crashed originally?

(I know these should all be the same, but I want to make sure that we are not 
looking at some strange side effect.)

Thanks, Stefan

> Am 14.04.2020 um 10:13 schrieb Steffen :
> 
> 
> What do you mean with a clean rebuild ?
> 
> r1874909 (1.15.8) is the one from  httpd 2.4.43 GA.
> 
> 
>  
> On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote:
>> In that revision, I see a change in the header file structure. If your build 
>> of r1874909 is not clean but somehow was partially using the old header 
>> file, things might get misaligned.
>> 
>> The other changes in that revision look rather unsuspicious to me. 
>> 
>> Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to verify? 
>> Thanks!
>> 
>> Cheers, Stefan
>> 
>>> Am 12.04.2020 um 15:57 schrieb mdrmdr :
>>> 
>>> With the help of Steffen (he built the Windows binaries for me) I can 
>>> report:
>>> 
>>> r1861247 - works
>>> r1864126 - works
>>> r1872230 - works
>>> r1873368 - works
>>> r1874286 - works
>>> r1874347 - works
>>> r1874909 (=2.4.43) - fails!
>>> 
>>> 
>>> 
>>> --
>>> Sent from: 
>>> http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
>> 
> 
> 

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Steffen]

All the same. 

> Op 14 apr. 2020 om 15:46 heeft Stefan Eissing  
> het volgende geschreven:
> 
> Just to confirm:
> 
> Did you build the r1874909 just like the other releases you tested or did you 
> use the already built 2.4.43 that crashed originally?
> 
> (I know these should all be the same, but I want to make sure that we are not 
> looking at some strange side effect.)
> 
> Thanks, Stefan
> 
>> Am 14.04.2020 um 10:13 schrieb Steffen :
>> 
>> 
>> What do you mean with a clean rebuild ?
>> 
>> r1874909 (1.15.8) is the one from  httpd 2.4.43 GA.
>> 
>> 
>> 
>>> On Tuesday 14/04/2020 at 09:38, Stefan Eissing wrote:
>>> In that revision, I see a change in the header file structure. If your 
>>> build of r1874909 is not clean but somehow was partially using the old 
>>> header file, things might get misaligned.
>>> 
>>> The other changes in that revision look rather unsuspicious to me. 
>>> 
>>> Steffen: could you make a clean rebuild of mod_http2 for mdrmdr to verify? 
>>> Thanks!
>>> 
>>> Cheers, Stefan
>>> 
 Am 12.04.2020 um 15:57 schrieb mdrmdr :
 
 With the help of Steffen (he built the Windows binaries for me) I can 
 report:
 
 r1861247 - works
 r1864126 - works
 r1872230 - works
 r1873368 - works
 r1874286 - works
 r1874347 - works
 r1874909 (=2.4.43) - fails!
 
 
 
 --
 Sent from: 
 http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
>>> 
>> 
>> 
> 

Re: Building from svn on MacOS

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 4/13/20 18:02, Rainer Jung wrote:
> Am 13.04.2020 um 23:27 schrieb William A Rowe Jr:
>> On Mon, Apr 13, 2020 at 4:21 PM Christopher Schultz
>> > > wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> William,
>>
 I'm having some trouble building 2.4.x directly from svn.

 MacOS 10.14.6 (Mojave)
>>>
>>> I note you mentioned apr 1.7.0. If you grab and pre build apr,
>>> and then apr-util (and openssl and anything else you want to
>>> refresh) or install the compiled system package, it should
>>> work. Point at them --with-apr plus --with-aprutil.
>>
>> I'm using brew which is like the missing package manager for
>> macos. I've installed apr and apr-util which I thikn are both
>> binary packages. I reconfigured with:
>>
>> $ ./buildconf
>> --with-apr=/usr/local/Cellar/apr/1.7.0/bin/apr-1-config -
>> --with-apr-util=/usr/local/Cellar/apr-util/1.6.1_3/bin/apu-1-config
>>
>>
>>
I get this output:
>>
>> using apr-config version 1.7.0 ./buildconf: line 249: cd:
>> /usr/local/Cellar/apr-util/1.6.1_3/bin/apu-1-config: Not a
>> directory copying build files
>>
>>
>> That's your answer. It wants the parent path of the apr/apr-util
>> installations, not the name of the apr-1-config file. It will
>> work out bin/apr-1-config... etc.
>
> The script looks like it should work using the path to
> apr-1-config, but if used in that way it unfortunately does not do
> what it announces, namely ignoring the apr-util setting. What is
> definitely not suppported is using a path to apu-1-config. This
> only works for apr, not apr-util.
>
> I recommend not trying to run buildconf against installed (binary)
> apr / apr-util but instead against an unpacked source download of
> these two. Run it with giving the path to the unpacked sources of
> the two. The script tries to copy a few files from the source tree
> and it is unclear, whether those files actually get packaged by
> people providing a binary distribution.

On the off-change that I had broken my working copy, I went ahead and
checked-out fresh from svn again and "correctly" ran buildconf again.
I still get these errors from buildconf:

cp: /usr/local/opt/apr/libexec/build-1/apr_common.m4: No such file or
directory
cp: /usr/local/opt/apr/libexec/build-1/find_apr.m4: No such file or
directory
cp: /usr/local/opt/apr/libexec/build-1/find_apu.m4: No such file or
directory

And, unsurprisingly, configure fails again with the same messages as
before. I checked, and this is not a path problem with e.g. brew's
installation of APR. Instead, those .m4 files are simply not present
in the distribution.

brew seems to have a "--devel" option, which will install the
"development version" or whatever package you are installing.
Unfortunately, the apr package doesn't have a "development" version
though their package-manager.

So I think I'll have to download the canonical sources as support. Not
a problem; I was just hoping I wouldn't have to do that manually.

I started with apr only, just in case apr-util didn't have the same
problem. Here's what buildconf says:

$ ./buildconf --with-apr=../apr-1.7.0/
- --with-apr-util=/usr/local/Cellar/apr-util/1.6.1_3/
found apr source: ../apr-1.7.0/

You don't have a copy of the apr-util source in srclib/apr-util.
Please get one the source using the following instructions,
or specify the location of the source with
- --with-apr-util=[path to apr-util]:

   svn co http://svn.apache.org/repos/asf/apr/apr-util/branches/1.5.x
srclib/apr-util

That's interesting. When buildconf doesn't find the files it needs in
apr (probably those .m4 files), it, I guess, can't validate the
apr-util installation, either.

Okay, so I'll grab apr-util.

$ ./buildconf --with-apr=../apr-1.7.0/ --with-apr-util=../apr-util-1.6.1
/
found apr source: ../apr-1.7.0/
found apr-util source: ../apr-util-1.6.1/
copying build files
rebuilding include/ap_config_auto.h.in
rebuilding configure
rebuilding rpm spec file
fixing timestamps for ap_expr sources

Huzzah!

$ ./configure
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking build system type... x86_64-apple-darwin18.7.0
checking host system type... x86_64-apple-darwin18.7.0
checking target system type... x86_64-apple-darwin18.7.0
configure:
configure: Configuring Apache Portable Runtime library...
configure:
checking for APR... no
configure: error: APR not found.  Please read the documentation.

LOL

Okay, so maybe I have to *build* apr and apr-util.

Running configure for apr gives me all that lovely configure sauce,
but then at the end:

config.status: executing libtool commands
rm: libtoolT: No such file or directory
config.status: executing default commands

Hmm. I hope libtoolT not being there is okay. Running the build
produces 2 .dylib files (.so's for macos), so I think 

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Eric Covener]

On Tue, Apr 14, 2020 at 8:09 AM Ruediger Pluem  wrote:
>
>
>
> On 4/14/20 12:22 PM, Steffen wrote:
> >
> >
> > This is the post above of backtrace
>
> Thanks.
>
> >
> > By accident I've seen that Perl comes with GDB. This might help as well.
> > I called httpd.exe from GDB with "-X -e debug" and then called a Perl URL 
> > in the browser.
> >
> > Excerpt below:
> >
>
> Somehow the below wasn't visible in the original mail.
>
> > Thread 100 received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 4936.0x23e0]
> > 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
> > X:\Apps\Apache24\bin\libhttpd.dll
> > (gdb) bt
> > #0  0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
> > X:\Apps\Apache24\bin\libhttpd.dll
> > #1  0x7ffbe44d14aa in ?? () from X:\Apps\Apache24\modules\mod_cgi.so
> > #2  0x7ffbe575ee85 in libhttpd!ap_run_handler () from 
> > X:\Apps\Apache24\bin\libhttpd.dll
> > #3  0x7ffbe575da7f in libhttpd!ap_invoke_handler () from 
> > X:\Apps\Apache24\bin\libhttpd.dll
> > #4  0x7ffbe575a62a in libhttpd!ap_internal_redirect_handler () from 
> > X:\Apps\Apache24\bin\libhttpd.dll
> > #5  0x7ffbe575a6af in libhttpd!ap_process_request () from 
> > X:\Apps\Apache24\bin\libhttpd.dll
> > #6  0x7ffbe22888ef in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> > #7  0x7ffbe5761545 in libhttpd!ap_run_process_connection () from 
> > X:\Apps\Apache24\bin\libhttpd.dll
> > #8  0x7ffbe22885ba in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> > #9  0x7ffbe228c36e in ?? () from X:\Apps\Apache24\modules\mod_http2.so
> > #10 0x7ffbe9e30e72 in ucrtbase!_beginthreadex () from 
> > C:\Windows\System32\ucrtbase.dll
> > #11 0x7ffbea107bd4 in KERNEL32!BaseThreadInitThunk () from 
> > C:\Windows\System32\kernel32.dll
> > #12 0x7ffbebecced1 in ntdll!RtlUserThreadStart () from 
> > C:\Windows\SYSTEM32\ntdll.dll
> > #13 0x in ?? ()
> > Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> > (gdb)
> >
>
>
> Unfortunately this stacktrace does not help. One reason might be that the 
> debugging symbols are missing.
> It is very strange that it segfaults in ap_get_server_built, a simple 
> function just returning a pointer
> to a static string constant. Furthermore ap_get_server_built is not called by 
> mod_cgi.
> Can the crash be repeated against a binary with debugging symbols that are 
> then used to generate the stacktrace?
> As I am not a Windows guy, I unfortunately cannot provide any instructions 
> how to do this.

My experience on windows is that if the PDB's are not 110% right you
will get all kinds of misleading stuff above the first ?? in the
displayed backtrace.

Re: mod_http2 crashes libhttpd.dll in 2.4.43

[Stefan Eissing]

Assuming this happens really in thread start of a HTTP/2 worker, the following 
change was made in Revision 1874909. The stacktrace indicates a 64 bit system.

Is someone making assumptions about connection->id content here? winnt mpm? 
Another module that freaks out? Or do I just not see the problem...


--- httpd/httpd/branches/2.4.x/modules/http2/h2_task.c  2020/03/06 16:14:06 
1874908
+++ httpd/httpd/branches/2.4.x/modules/http2/h2_task.c  2020/03/06 16:15:17 
1874909
@@ -555,37 +555,36 @@ apr_status_t h2_task_do(h2_task *task, a
 task->worker_started = 1;
 
 if (c->master) {
-/* Each conn_rec->id is supposed to be unique at a point in time. Since
+/* See the discussion at 
+ *
+ * Each conn_rec->id is supposed to be unique at a point in time. Since
  * some modules (and maybe external code) uses this id as an identifier
  * for the request_rec they handle, it needs to be unique for slave 
  * connections also.
- * The connection id is generated by the MPM and most MPMs use the 
formula
- *id := (child_num * max_threads) + thread_num
- * which means that there is a maximum id of about
- *idmax := max_child_count * max_threads
- * If we assume 2024 child processes with 2048 threads max, we get
- *idmax ~= 2024 * 2048 = 2 ** 22
- * On 32 bit systems, we have not much space left, but on 64 bit 
systems
- * (and higher?) we can use the upper 32 bits without fear of 
collision.
- * 32 bits is just what we need, since a connection can only handle so
- * many streams. 
+ *
+ * The MPM module assigns the connection ids and mod_unique_id is using
+ * that one to generate identifier for requests. While the 
implementation
+ * works for HTTP/1.x, the parallel execution of several requests per
+ * connection will generate duplicate identifiers on load.
+ * 
+ * The original implementation for slave connection identifiers used 
+ * to shift the master connection id up and assign the stream id to 
the 
+ * lower bits. This was cramped on 32 bit systems, but on 64bit there 
was
+ * enough space.
+ * 
+ * As issue 195 showed, mod_unique_id only uses the lower 32 bit of the
+ * connection id, even on 64bit systems. Therefore collisions in 
request ids.
+ *
+ * The way master connection ids are generated, there is some space 
"at the
+ * top" of the lower 32 bits on allmost all systems. If you have a 
setup
+ * with 64k threads per child and 255 child processes, you live on the 
edge.
+ *
+ * The new implementation shifts 8 bits and XORs in the worker
+ * id. This will experience collisions with > 256 h2 workers and heavy
+ * load still. There seems to be no way to solve this in all possible 
+ * configurations by mod_h2 alone. 
  */
-int slave_id, free_bits;
-
-task->id = apr_psprintf(task->pool, "%ld-%d", c->master->id, 
-task->stream_id);
-if (sizeof(unsigned long) >= 8) {
-free_bits = 32;
-slave_id = task->stream_id;
-}
-else {
-/* Assume we have a more limited number of threads/processes
- * and h2 workers on a 32-bit system. Use the worker instead
- * of the stream id. */
-free_bits = 8;
-slave_id = worker_id; 
-}
-task->c->id = (c->master->id << free_bits)^slave_id;
+task->c->id = (c->master->id << 8)^worker_id;
 }
 
 h2_beam_create(>output.beam, c->pool, task->stream_id, "output", 


Stefan Eissing

bytes GmbH
Hafenweg 16
48155 Münster
www.greenbytes.de

> Am 14.04.2020 um 14:12 schrieb Eric Covener :
> 
> On Tue, Apr 14, 2020 at 8:09 AM Ruediger Pluem  wrote:
>> 
>> 
>> 
>> On 4/14/20 12:22 PM, Steffen wrote:
>>> 
>>> 
>>> This is the post above of backtrace
>> 
>> Thanks.
>> 
>>> 
>>> By accident I've seen that Perl comes with GDB. This might help as well.
>>> I called httpd.exe from GDB with "-X -e debug" and then called a Perl URL 
>>> in the browser.
>>> 
>>> Excerpt below:
>>> 
>> 
>> Somehow the below wasn't visible in the original mail.
>> 
>>> Thread 100 received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 4936.0x23e0]
>>> 0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
>>> X:\Apps\Apache24\bin\libhttpd.dll
>>> (gdb) bt
>>> #0  0x7ffbe57515d9 in libhttpd!ap_get_server_built () from 
>>> X:\Apps\Apache24\bin\libhttpd.dll
>>> #1  0x7ffbe44d14aa in ?? () from X:\Apps\Apache24\modules\mod_cgi.so
>>> #2  0x7ffbe575ee85 in libhttpd!ap_run_handler () from 
>>> X:\Apps\Apache24\bin\libhttpd.dll
>>> #3  0x7ffbe575da7f in libhttpd!ap_invoke_handler () from 
>>> 

Re: TCP socket wothout HTTP protocol

[Eric Covener]

On Tue, Apr 14, 2020 at 11:16 AM Sébastien Mizrahi  wrote:
>
> Hi,
>
> For some reasons, I would like to read natively TCP socket in an Apache 
> module. The request is not encapsulated in HTTP protocol end the client send 
> raw data.
> I have already an apache module that manage standard HTTP request and I would 
> like to mutualise the code.
>

The test suite has "weird" modules that are not HTTP that you might
have a look at

https://svn.apache.org/repos/asf/httpd/test/framework/trunk

./c-modules/nntp_like/mod_nntp_like.c is what I was thinking of. Just
from seeing it scroll by.

There is also mod_ftp: https://httpd.apache.org/mod_ftp/

TCP socket wothout HTTP protocol

[Sébastien Mizrahi]

Hi,

For some reasons, I would like to read natively TCP socket in an Apache module. 
The request is not encapsulated in HTTP protocol end the client send raw data.
I have already an apache module that manage standard HTTP request and I would 
like to mutualise the code.

Any idea if that’s possible ?

Sebastien.

Re: TCP socket wothout HTTP protocol

[Sébastien Mizrahi]

Thanks a lor Eric !

Gonna read this :)
Le 14 avr. 2020 à 17:20 +0200, Eric Covener , a écrit :
On Tue, Apr 14, 2020 at 11:16 AM Sébastien Mizrahi  wrote:

Hi,

For some reasons, I would like to read natively TCP socket in an Apache module. 
The request is not encapsulated in HTTP protocol end the client send raw data.
I have already an apache module that manage standard HTTP request and I would 
like to mutualise the code.


The test suite has "weird" modules that are not HTTP that you might
have a look at

https://svn.apache.org/repos/asf/httpd/test/framework/trunk

./c-modules/nntp_like/mod_nntp_like.c is what I was thinking of. Just
from seeing it scroll by.

There is also mod_ftp: https://httpd.apache.org/mod_ftp/

Re: TCP socket wothout HTTP protocol

[Sébastien Mizrahi]

Hey Eric just a feedback to confirm that it just works as expected.
Thanks again !

Client from https://www.geeksforgeeks.org/socket-programming-cc/

Apache module :
int socket_process_connection(conn_rec *req) {
printf(« Conn init\n");
apr_socket_t *asock = ap_get_conn_socket(req);
int fd = 0;
apr_os_sock_get(, asock);
char buffer[1024] = {0};
int valread = read(fd , buffer, 1024);
printf("%s\n", buffer);
return 0;
}

// Apache callback to register our hooks
void register_hooks(apr_pool_t* pool) {
static const char* const mod_ssl_reqtimeout[] = {"mod_ssl.c", 
"mod_reqtimeout.c", NULL};
ap_hook_process_connection(socket_process_connection, NULL, mod_ssl_reqtimeout, 
APR_HOOK_REALLY_FIRST);
}

Sebastien.

Le 14 avr. 2020 à 17:40 +0200, Sébastien Mizrahi , a écrit :
Thanks a lor Eric !

Gonna read this :)
Le 14 avr. 2020 à 17:20 +0200, Eric Covener , a écrit :
On Tue, Apr 14, 2020 at 11:16 AM Sébastien Mizrahi  wrote:

Hi,

For some reasons, I would like to read natively TCP socket in an Apache module. 
The request is not encapsulated in HTTP protocol end the client send raw data.
I have already an apache module that manage standard HTTP request and I would 
like to mutualise the code.


The test suite has "weird" modules that are not HTTP that you might
have a look at

https://svn.apache.org/repos/asf/httpd/test/framework/trunk

./c-modules/nntp_like/mod_nntp_like.c is what I was thinking of. Just
from seeing it scroll by.

There is also mod_ftp: https://httpd.apache.org/mod_ftp/