Re: apr "the latest available version"

[Reindl Harald]

Am 26.10.2017 um 12:38 schrieb Graham Leggett:

On 26 Oct 2017, at 12:31 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


i am not going to subscribe to every single devel list out there for single 
issues and had already submitted a bug as 1.6.x was over months invisible when 
you expect that the top part of the page is recent


Please tone down the aggressive behaviour


i don't see any aggressive here

sorry for pointing out a issue trying to help others which probably 
don't realize and hence not update their servers while i personally 
could not care less after knowing that i have to scroll down

Re: apr "the latest available version"

[Reindl Harald]

Am 25.10.2017 um 18:26 schrieb Daniel Gruno:

On 10/25/2017 06:23 PM, Reindl Harald wrote:

it is *not* helpful when you already have deployed httpd 2.4.29 that you
by random luck face a apr-1.6.3 build on the fedora buildserver


I'd suggest you post this to d...@apr.apache.org if you want them to
update their dist page.


i am not going to subscribe to every single devel list out there for 
single issues and had already submitted a bug as 1.6.x was over months 
invisible when you expect that the top part of the page is recent


both are apache projects, i assume that on this list are also 
apr-developers and when you look at mails like this one such issues 
should be sovled somehow and if it only means doing nothing else than a 
ordinary folder listing and remove the facny always outdated top paragraph


On Wed, Oct 25, 2017 at 4:02 PM, Craig Young <cyo...@tripwire.com> wrote:
> I'm not sure if this is what is referred to in the Apache 2.4.29 
announcement, but please note that the Apache Portable Runtime v1.6.3 
release resolved memory safety issues I found in functions used within 
HTTP server.  This was released in conjunction with 2.4.29.



(https://koji.fedoraproject.org/koji/buildinfo?buildID=989222) either
this stuff on top should be removed completly or properly updated, if
it's not there at all one would look at the filelist

https://www.apache.org/dist/apr/

Important Notices
     Download from your nearest mirror site!
     APR 1.6.2 is the latest available version
     APR-util 1.6.0 is the latest available version
     APR-iconv 1.2.1 is the latest available version

APR 1.6.2 is the latest available version

APR 1.6.2 has been released, and should be considered "general
availability".
APR-util 1.6.0 is the latest available version

APR-util 1.6.0 has been released, and should be considered "general
availability"

apr "the latest available version"

[Reindl Harald]

it is *not* helpful when you already have deployed httpd 2.4.29 that you 
by random luck face a apr-1.6.3 build on the fedora buildserver 
(https://koji.fedoraproject.org/koji/buildinfo?buildID=989222) either 
this stuff on top should be removed completly or properly updated, if 
it's not there at all one would look at the filelist


https://www.apache.org/dist/apr/

Important Notices
Download from your nearest mirror site!
APR 1.6.2 is the latest available version
APR-util 1.6.0 is the latest available version
APR-iconv 1.2.1 is the latest available version

APR 1.6.2 is the latest available version

APR 1.6.2 has been released, and should be considered "general 
availability".

APR-util 1.6.0 is the latest available version

APR-util 1.6.0 has been released, and should be considered "general 
availability".

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[Reindl Harald]

Am 13.10.2017 um 17:05 schrieb William A Rowe Jr:
On Oct 13, 2017 08:41, "Stefan Eissing" > wrote:


 > Am 13.10.2017 um 15:19 schrieb William A Rowe Jr
>:
 >
 > Is anyone seeing an issue of concern about stability on 2.4.x branch?

Not any more than in previous releases, I think.

 > Has anyone else looked at Jim's proposed fixes for xcode 9 building
 > under maintainer mode? A couple-line quick fix to configure.in
, that
 > anyone on OS/X should be able to validate in minutes. The same fix
 > is already present on APR's branches, which I will tag as well.

I build in maintainer mode all the time and use Xcode9 since I
upgrade to macOS 10.13. Whatever weirdness I encountered and reported
earlier is gone - I rebuilt my local 2.4.x environment and all seems
well.

I suspect it works because you first configured APR in maintainer mode, 
and httpd inherits cpp flags?


and why does that happen at all for apr-util and httpd?

that means *you can not* build rpm packages for let say sandybridge on a 
machine which has installed apr/apr-util built with -mtune=native on a 
Skylake cluster until you first rebuild apr/apr-util which then means 
you can't build a httpd package optimized for Skylake until you rebuild 
the other both again - that is simply wrong and no other software acts 
that way


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

Re: [CLOSED] [VOTE] Release Apache httpd 2.4.28 as GA

[Reindl Harald]

Am 08.10.2017 um 15:22 schrieb Jim Jagielski:

Hrm... looks like it was already announced? At least the
website sez it was, and it looks like an Email was
sent to announce@a.o but I'm not seeing anything on
the httpd lists


 Weitergeleitete Nachricht 
Betreff:[Announcement] Apache HTTP Server 2.4.28 Released
Datum:  Thu, 5 Oct 2017 13:49:10 -0500
Von:William A Rowe Jr 
An: annou...@httpd.apache.org



  Apache HTTP Server 2.4.28 Released

October 5, 2017

The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.28 of the Apache
HTTP Server ("Apache").  This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache HTTPD and
represents fifteen years of innovation by the project, and is
recommended over all previous releases. This release of Apache is
a security, feature, and bug fix release.

Re: [VOTE] Release Apache httpd 2.4.28 as GA

[Reindl Harald]

Am 29.09.2017 um 14:16 schrieb Eric Covener:

On Fri, Sep 29, 2017 at 6:57 AM, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 29.09.2017 um 12:35 schrieb Graham Leggett:


On 29 Sep 2017, at 12:25 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


it's not about cheap - it's just questionable that after 2.4.12 the next
release is 2.4.16 because it looks not really sane



Looks perfectly sensible to me


in your world where you know the background, without the context it looks
like "are they not capable to count?"


What kind of user do you think this confusion affects?  They'd have to
care that N-1 wasn't released, but not be reading the changelog


frankly, i personally don't care but it's strange what is the point of 
discuss there when alpha.beta,rc,ga is surrounding us over decades (yes, 
i know in the modern world there is only 1,2,3,4,5,50,60...)

Re: [VOTE] Release Apache httpd 2.4.28 as GA

[Reindl Harald]

Am 29.09.2017 um 12:35 schrieb Graham Leggett:

On 29 Sep 2017, at 12:25 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


it's not about cheap - it's just questionable that after 2.4.12 the next 
release is 2.4.16 because it looks not really sane


Looks perfectly sensible to me


in your world where you know the background, without the context it 
looks like "are they not capable to count?"

Re: [VOTE] Release Apache httpd 2.4.28 as GA

[Reindl Harald]

Am 29.09.2017 um 12:16 schrieb Graham Leggett:

On 28 Sep 2017, at 7:10 PM, Helmut K. C. Tessarek <tessa...@evermeet.cx> wrote:


I have a question. Why are you tagging a release and do testing? Most of
the time a problem is found and a new release is tagged and it starts
over (I think the max was a 3 or 4 patch level jump).

Why not tagging an RC? People test the RC. When all is ok, the RC is
released. If not a new RC is tagged.


Because version numbers are cheap. If you call it RC, or call it the next patch 
version, it doesn’t ultimately matter


it's not about cheap - it's just questionable that after 2.4.12 the next 
release is 2.4.16 because it looks not really sane


* Fr Jul 10 2015 Reindl Harald <h.rei...@thelounge.net>
- update to 2.4.16 (2.4.13, 2.4.14 and 2.4.15 was skipped upstream)

Re: Listen 443 https

[Reindl Harald]

Am 18.09.2017 um 19:28 schrieb Daniel:

I see

But we already have a handy directive to avoid repetition when
necessary, a directive that btw many distros abuse, "Include". You
define the common parts in a single file and Include the appropiate
file.


that scales bad when the vhost itself is already one of hundrets of 
Includes


i have currently written/refactored a "config parser" for vhosts with 
support of some comments to configure Letsencrypt tasks as well as 
generate the remap/ssl config of a reverse proxy, based on some 
Alias-statements webstats shellscripts are generated and the whole 
hosting database is feeded with that data too


that works independent of the number of hosts, a shellscript on the 
admin-servers fetchs all config file sof all webservers and from there 
the central proxy configuration is feeded


well, in other word, with some lines of code based on apache vhost 
includes the whole company is driven and implement includs support here 
would be at least dangerous and hard to test since that all runs over 
many machines and testing environments



2017-09-18 19:18 GMT+02:00 Reindl Harald <h.rei...@thelounge.net>:


Am 18.09.2017 um 17:56 schrieb Daniel:


I tried to read and understand the whole thread and what we are trying
to solve here, but I can't help to think this is an attempt at a new
".htaccess" wildcard thing for SSL that will end in greater confusion.

in Freenode #httpd we generally try to teach people to not be afraid
of defining the necessary virtualhosts. Everyone seems inclined, due
to the amount of trash they have found through google, to define a
single .htaccess files that will solve all their cases, redirections,
and whatnot, and 90% are frustrated on how complicated it is.

The generic solution we give is, (the iconic simplest way), one
virtualhost for each:


ServerName whatever.example.com
Redirect / https://whatever.example.com/



ServerName whatever.example.com
SSLEngine on
etc..


Isn't this much better than any other attempt at reducing it to
"another minimum expression" in a complicated kind of way?



no it is not - have fun define two hosts with all options and i would have
much more samples with much more php-options which needs to be included in
both in doubt

yes, the software fetching lyrics likely had a problem with self-signed
certificates which was the case until short ago but that don't make the
config unreasonable exclude specific locations from enforced https

the only problem cuurently is that $_SERVER['HTTP_PORT'] is wrong for such a
vhost with 80 while it should be 443 in case of a https-connection


  DocumentRoot "/mnt/data/www/example.rhsoft.net"
  ServerName example.rhsoft.net
  ServerAlias example.test.rh example example.rh.thelounge.net
  Alias "/usage" "/var/www/usage/example"
  CustomLog "/var/log/apache_example.log" combined
  
  php_admin_value open_basedir
"/mnt/data/www/example.rhsoft.net:/Volumes/dune/www-servers/phpincludes:/usr/share/php:/usr/share/pear:/mnt/data/audio:/media/WALKMAN/music"
  php_admin_value upload_tmp_dir
"/mnt/data/www/example.rhsoft.net/uploadtemp"
  php_admin_value soap.wsdl_cache_dir
"/mnt/data/www/example.rhsoft.net/uploadtemp"
  php_flag session.cookie_secure "1"
  Require all granted
  
  
  Require all denied
  
  
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !lyrics.php
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
  
  
  SetOutputFilter RATE_LIMIT
  SetEnv rate-limit 2800
  
  RedirectMatch 404 ^/modules/karaoke\-download\.php$
  RedirectMatch 404 ^/modules/music/copy\-cli\.php$
  RedirectMatch 404 ^/modules/music/validate\-all\-id3\-tags\.php$
  SSLEngine Optional
  SSLUseStapling On
  SSLCertificateFile "/var/lib/letsencrypt/certs/rhsoft-example.conf_rsa.pem"
  SSLCertificateFile
"/var/lib/letsencrypt/certs/rhsoft-example.conf_ecdsa.pem"

Re: Listen 443 https

[Reindl Harald]

Am 18.09.2017 um 17:56 schrieb Daniel:

I tried to read and understand the whole thread and what we are trying
to solve here, but I can't help to think this is an attempt at a new
".htaccess" wildcard thing for SSL that will end in greater confusion.

in Freenode #httpd we generally try to teach people to not be afraid
of defining the necessary virtualhosts. Everyone seems inclined, due
to the amount of trash they have found through google, to define a
single .htaccess files that will solve all their cases, redirections,
and whatnot, and 90% are frustrated on how complicated it is.

The generic solution we give is, (the iconic simplest way), one
virtualhost for each:


ServerName whatever.example.com
Redirect / https://whatever.example.com/



ServerName whatever.example.com
SSLEngine on
etc..


Isn't this much better than any other attempt at reducing it to
"another minimum expression" in a complicated kind of way?


no it is not - have fun define two hosts with all options and i would 
have much more samples with much more php-options which needs to be 
included in both in doubt


yes, the software fetching lyrics likely had a problem with self-signed 
certificates which was the case until short ago but that don't make the 
config unreasonable exclude specific locations from enforced https


the only problem cuurently is that $_SERVER['HTTP_PORT'] is wrong for 
such a vhost with 80 while it should be 443 in case of a https-connection



 DocumentRoot "/mnt/data/www/example.rhsoft.net"
 ServerName example.rhsoft.net
 ServerAlias example.test.rh example example.rh.thelounge.net
 Alias "/usage" "/var/www/usage/example"
 CustomLog "/var/log/apache_example.log" combined
 
 php_admin_value open_basedir 
"/mnt/data/www/example.rhsoft.net:/Volumes/dune/www-servers/phpincludes:/usr/share/php:/usr/share/pear:/mnt/data/audio:/media/WALKMAN/music"
 php_admin_value upload_tmp_dir 
"/mnt/data/www/example.rhsoft.net/uploadtemp"
 php_admin_value soap.wsdl_cache_dir 
"/mnt/data/www/example.rhsoft.net/uploadtemp"

 php_flag session.cookie_secure "1"
 Require all granted
 
 
 Require all denied
 
 
 RewriteEngine On
 RewriteCond %{REQUEST_FILENAME} !lyrics.php
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
 
 
 SetOutputFilter RATE_LIMIT
 SetEnv rate-limit 2800
 
 RedirectMatch 404 ^/modules/karaoke\-download\.php$
 RedirectMatch 404 ^/modules/music/copy\-cli\.php$
 RedirectMatch 404 ^/modules/music/validate\-all\-id3\-tags\.php$
 SSLEngine Optional
 SSLUseStapling On
 SSLCertificateFile 
"/var/lib/letsencrypt/certs/rhsoft-example.conf_rsa.pem"
 SSLCertificateFile 
"/var/lib/letsencrypt/certs/rhsoft-example.conf_ecdsa.pem"

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

Am 17.09.2017 um 03:07 schrieb Nick Edwards:

phpmyadmin 4.4.15  is YEARS old


and how does that change the fact that 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519#c1 "SERVER_PORT 80" 
in case of a https-connection is plain wrong?



we using 4.7 for nearly a year, 4.7.2 is current


nice for you when you don't have to support older PHP (sync the package 
to a RHEL 7 host with PHP 5.4 - my whole own software is PHP 7.1 only 
with strict-types but that's not related to the topic at all)


this from a troll who verbally abuses the hell out of people on other 
lists for posting similar comments using very outdated softwares   HAH, 
this ones in google for life.


the only troll in this thread is you and nobody asked you, just because 
i have never seen anything useful on any list since you only post if you 
face something from me and otherwise you are a silent lurker everywhere!


On Sun, Sep 17, 2017 at 10:24 AM, Reindl Harald <h.rei...@thelounge.net 
<mailto:h.rei...@thelounge.net>> wrote:



that's even more worse - phpMyAdmin 4.4.15.10 seems to handle
something wrong because $_SERVER['SERVER_PORT'] is wrong - and i had
myself some bad code using that var instead of $_SERVER['HTTPS']
which again leaded in a endless loop

in case of phpMyAdmin it redirects to https://hostname:80/path/
after enter username/password - the workaround below in the config
file seems to solve that for now, but all in all that leaves a very
bad taste

if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
  $cfg['ForceSSL'] = false;
}
else
{
  $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:

Ok, as I read the code a bit more, there is a tangle of
things that can influence port/scheme selection. But what I
can see, the version in *trunk* should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

    ServerName xxx.yyy
    SSLEngine *:443
     ...


should do the right thing here. Internal methods used to
generator Redirect Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and
als fill the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome
starts to warn about every page with a form tag and no TLS

[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of
/etc/httpd/conf/sites_enabled/contentlounge.conf:
Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald
<h.rei...@thelounge.net <mailto:h.rei...@thelounge.net>>:



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
    UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http://
protocol instead https// on port 443 here even tiggers
mod_security

even if it would mitigate that issue - having ports in
redirect urls easily leads to a lot of other problems
when proxy-servers are part of the game

[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head
--insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1

Am 14.09.2017 um 12:00 schrieb Reindl Harald
<h.rei...@thelounge.net
<mailto:h.rei...@thelounge.net>>:



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized

but with "SSLEngine On" and
"SSLCertificateFile" configur

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

assumption confirmed - and my connection is for sure https:// because of 
the mod_rewrite and finally HSTS


https://bz.apache.org/bugzilla/show_bug.cgi?id=61519 updated too

phpinfo():
SERVER_PORT 80


 ServerName www.rhsoft.net
 SSLEngine Optional
 SSLUseStapling On
 SSLCertificateFile "certs/rhsoft-www.conf_rsa.pem"
 SSLCertificateFile "certs/rhsoft-www.conf_ecdsa.pem"
 
  RewriteEngine on
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
 
 
  Header always set "Strict-Transport-Security" "max-age=31536000"
 


Am 17.09.2017 um 02:24 schrieb Reindl Harald:


that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something 
wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some 
bad code using that var instead of $_SERVER['HTTPS'] which again leaded 
in a endless loop


in case of phpMyAdmin it redirects to https://hostname:80/path/ after 
enter username/password - the workaround below in the config file seems 
to solve that for now, but all in all that leaves a very bad taste


if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
  $cfg['ForceSSL'] = false;
}
else
{
  $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
Ok, as I read the code a bit more, there is a tangle of things that 
can influence port/scheme selection. But what I can see, the version 
in *trunk* should do the right thing *iff*


a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
    ...


should do the right thing here. Internal methods used to generator 
Redirect Location headers, namely

ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill 
the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald <h.rei...@thelounge.net>:



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part 
of the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1

Am 14.09.2017 um 12:00 schrieb Reindl Harald 
<h.rei...@thelounge.net>:




Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized
but with "SSLEngine On" and "SSLCertificateFile" configured 
non-https no longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519


if the trailing slash is missing in the url the automatic redirect 
to the full qualified folder-path points to http:// instead 
https:// and that does not happen within a vhost dedicated to :443 
and "SSLEngine On"


i was trapped in a endless loop because the php script making a 
redirect to https:// had a bug and missed the traling / too



DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something 
wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some 
bad code using that var instead of $_SERVER['HTTPS'] which again leaded 
in a endless loop


in case of phpMyAdmin it redirects to https://hostname:80/path/ after 
enter username/password - the workaround below in the config file seems 
to solve that for now, but all in all that leaves a very bad taste


if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
 $cfg['ForceSSL'] = false;
}
else
{
 $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
Ok, as I read the code a bit more, there is a tangle of things that 
can influence port/scheme selection. But what I can see, the version 
in *trunk* should do the right thing *iff*


a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
    ...


should do the right thing here. Internal methods used to generator 
Redirect Location headers, namely

ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill 
the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald <h.rei...@thelounge.net>:



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part 
of the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1


Am 14.09.2017 um 12:00 schrieb Reindl Harald <h.rei...@thelounge.net>:



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized
but with "SSLEngine On" and "SSLCertificateFile" configured 
non-https no longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519


if the trailing slash is missing in the url the automatic redirect 
to the full qualified folder-path points to http:// instead 
https:// and that does not happen within a vhost dedicated to :443 
and "SSLEngine On"


i was trapped in a endless loop because the php script making a 
redirect to https:// had a bug and missed the traling / too



DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Reindl Harald]

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:

Ok, as I read the code a bit more, there is a tangle of things that can 
influence port/scheme selection. But what I can see, the version in *trunk* 
should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
...


should do the right thing here. Internal methods used to generator Redirect 
Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill the Env 
Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald <h.rei...@thelounge.net>:



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol instead 
https// on port 443 here even tiggers mod_security

even if it would mitigate that issue - having ports in redirect urls easily 
leads to a lot of other problems when proxy-servers are part of the game

[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1


Am 14.09.2017 um 12:00 schrieb Reindl Harald <h.rei...@thelounge.net>:



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized

but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer 
would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

if the trailing slash is missing in the url the automatic redirect to the full qualified 
folder-path points to http:// instead https:// and that does not happen within a vhost 
dedicated to :443 and "SSLEngine On"

i was trapped in a endless loop because the php script making a redirect to 
https:// had a bug and missed the traling / too


DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Reindl Harald]

Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,

could you check if a configuration like:

   UseCanonicalPhysicalPort on

in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part of 
the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1


Am 14.09.2017 um 12:00 schrieb Reindl Harald <h.rei...@thelounge.net>:



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized

but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer 
would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

if the trailing slash is missing in the url the automatic redirect to the full qualified 
folder-path points to http:// instead https:// and that does not happen within a vhost 
dedicated to :443 and "SSLEngine On"

i was trapped in a endless loop because the php script making a redirect to 
https:// had a bug and missed the traling / too


DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Reindl Harald]

Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized


but with "SSLEngine On" and "SSLCertificateFile" configured non-https no 
longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

if the trailing slash is missing in the url the automatic redirect to 
the full qualified folder-path points to http:// instead https:// and 
that does not happen within a vhost dedicated to :443 and "SSLEngine On"


i was trapped in a endless loop because the php script making a redirect 
to https:// had a bug and missed the traling / too



 DocumentRoot "/www/contentlounge"
 ServerName contentlounge.rhsoft.net
 SSLEngine optional
 SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Reindl Harald]

Am 10.08.2017 um 17:57 schrieb William A Rowe Jr:


On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald
<h.rei...@thelounge.net <mailto:h.rei...@thelounge.net>> wrote:
 >
 > 
 >  ServerName corecms.example.com <http://corecms.example.com>
 >  DocumentRoot "/www/corecms.example.com <http://corecms.example.com>"
 >  

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your
certificate file
and your stapling choice from affecting h2 requests on port 80.

Another reason this will not work... Server/VHost config is static. All 
such directives are evaluated at config/startup time, global config is 
merged to per-vhost config. And that is the state of the host for that 
generation of the workers process.  will never be supported for 
those directives, it can work only on per-dir config options.


Final reason this won't be adopted as suggested; VirtualHost [:80] is 
implicit. I cannot see us ever changing this, it would break most 
configs. Maybe a port * feature?


If you want to experiment...

is already recognized


but with "SSLEngine On" and "SSLCertificateFile" configured non-https no 
longer would work, since H2 no longer supports mod_prefork i don't care 
about that part


for high traffic sites apache trafficserver is in front which scales 
much better and enbales H2 automatically but i want every backend vhost 
keep working as now independent and only DNS decides if it goes to the 
proxy - proxy which makes no sense for very small pages with no traffic 
all the time and only introdcues latency and wastes memory caches

Re: Listen 443 https

[Reindl Harald]

Am 10.08.2017 um 15:28 schrieb Stefan Eissing:

Now that mod_md has landed in trunk, I am looking at more ways
to simplify a SSL configuration. Looking at the Listen directive,
it has an optional 2nd protocol parameter.

Would it be unreasonable to assume that a
 Listen NNN https

means that "SSLEngine on" should be the default in all
 
ServerName xxx.yyy
...
 

sections? Would we expect breakage by such a change?

What about name-based virtual hosts that apply to _all_
addresses and ports? E.g. something like:
 
ServerName xxx.yyy
...

   Redirect permanent "/" "https://xxx.yyy/;

...
 

Do you find that ugly/feasible/desirable?


it makes it unflexible, something like port-specific options would solve 
the current problem that you need to define aecgh and every vhost with 
all it's options twice and that part is my biggest headache by implement 
letsencrypt (without mod_md) for hundrets of existing websites


it also would solve the chicken-egg-problem (again, without mod_md) that 
you first need the http-host working for the well-known verfication file 
and the path of the certificate could be easily pre-configured in the 
way of my example, just warn insteda a fatal error on reload when the 
certfile don't exist




 ServerName corecms.example.com
 DocumentRoot "/www/corecms.example.com"
 
  SSLEngine On
  SSLUseStapling Off
  SSLCertificateFile "conf/ssl/corecms.pem"
 
 
  php_admin_value open_basedir "/www/corecms.example.com"
  php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
 




 ServerName corecms.example.com
 DocumentRoot "/www/corecms.example.com"
 
  php_admin_value open_basedir "/www/corecms.example.com"
  php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
 



 ServerName corecms.example.com
 DocumentRoot "/www/corecms.example.com"
 SSLEngine On
 SSLUseStapling Off
 SSLCertificateFile "conf/ssl/corecms.pem"
 
  php_admin_value open_basedir "/www/corecms.example.com"
  php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
 

Re: Content-Type / AddOutputFilterByType DEFLATE text/html

[Reindl Harald]

OK, the reason are the HEAD-Requests triggered by curl_setopt($curl, 
CURLOPT_NOBODY, 1); so the bug is ignoring that in case of 
"/static.htm?count=250_150209658" and sending in fact a body back while 
for the 3 other test urls the response is HEAD as requested and the curl 
code is identical


 $curl = curl_init();
 curl_setopt($curl, CURLOPT_NOBODY, 1);
 curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
 curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 5);
 curl_setopt($curl, CURLOPT_USERAGENT, 'Mozilla/5.0 (X11; Fedora; Linux 
x86_64; rv:55.0) Gecko/20100101 Firefox/55.0');

 curl_setopt($curl, CURLOPT_HEADER, 1);
 curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);
 curl_setopt($curl, CURLOPT_URL, $url);
 curl_setopt($curl, CURLOPT_HTTPHEADER, $curl_header);

Am 07.08.2017 um 11:12 schrieb Reindl Harald:

Hi

AddOutputFilterByType DEFLATE text/html

is this a bug or somehow expected behavior that in case the 
"Content-Type" header also contains a charset mod_defalte don't work as 
expected which means in case of curl requests only static files are gzip 
compressed while PHP responses are missing "Content-Encoding: gzip" - 
that this don't happen in case of Firefox as client makes it even more 
strange


identical result for "Content-Type: text/html; charset=UTF-8" in case 
"default_charset" is not set in php.ini


the last line of each block is the PHP array for curl_setopt($curl, 
CURLOPT_HTTPHEADER, $curl_header);


NO GZIP
http://corecms/index.php?count=250_1502096587
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1744 us
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-cache
ETag: 7d820de3763d0e6c22ccbfe846ab1c31
Vary: User-Agent
Content-Type: text/html; charset=ISO-8859-1
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}


NO GZIP
http://corecms/
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=400 us
Cache-Control: max-age=120
Expires: Mon, 07 Aug 2017 09:05:08 GMT
Vary: User-Agent
Content-Type: text/html; charset=ISO-8859-1
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}


GZIP OK
http://corecms/static.htm?count=250_1502096587
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=297 us
Last-Modified: Sun, 06 Aug 2017 17:49:54 GMT
ETag: "ec1-556195b938c8f-gzip"
Accept-Ranges: bytes
Cache-Control: max-age=120
Expires: Mon, 07 Aug 2017 09:05:08 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 890
Content-Type: text/html
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}


NO GZIP
http://corecms/static.php?count=250_1502096587
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=280 us
Cache-Control: max-age=120
Expires: Mon, 07 Aug 2017 09:05:08 GMT
Vary: User-Agent
Content-Type: text/html; charset=ISO-8859-1
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}

Content-Type / AddOutputFilterByType DEFLATE text/html

[Reindl Harald]

Hi

AddOutputFilterByType DEFLATE text/html

is this a bug or somehow expected behavior that in case the 
"Content-Type" header also contains a charset mod_defalte don't work as 
expected which means in case of curl requests only static files are gzip 
compressed while PHP responses are missing "Content-Encoding: gzip" - 
that this don't happen in case of Firefox as client makes it even more 
strange


identical result for "Content-Type: text/html; charset=UTF-8" in case 
"default_charset" is not set in php.ini


the last line of each block is the PHP array for curl_setopt($curl, 
CURLOPT_HTTPHEADER, $curl_header);


NO GZIP
http://corecms/index.php?count=250_1502096587
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1744 us
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-cache
ETag: 7d820de3763d0e6c22ccbfe846ab1c31
Vary: User-Agent
Content-Type: text/html; charset=ISO-8859-1
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}


NO GZIP
http://corecms/
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=400 us
Cache-Control: max-age=120
Expires: Mon, 07 Aug 2017 09:05:08 GMT
Vary: User-Agent
Content-Type: text/html; charset=ISO-8859-1
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}


GZIP OK
http://corecms/static.htm?count=250_1502096587
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=297 us
Last-Modified: Sun, 06 Aug 2017 17:49:54 GMT
ETag: "ec1-556195b938c8f-gzip"
Accept-Ranges: bytes
Cache-Control: max-age=120
Expires: Mon, 07 Aug 2017 09:05:08 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 890
Content-Type: text/html
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}


NO GZIP
http://corecms/static.php?count=250_1502096587
HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 09:03:08 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=280 us
Cache-Control: max-age=120
Expires: Mon, 07 Aug 2017 09:05:08 GMT
Vary: User-Agent
Content-Type: text/html; charset=ISO-8859-1
a:2:{i:0;s:58:"Cookie: 
LOUNGE_ID=pivked76ocg1n9750n91d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: 
gzip, deflate";}

Re: 2.4.27

[Reindl Harald]

Am 11.07.2017 um 14:55 schrieb David Zuelke:

On 10. Jul 2017, at 16:04, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 06.07.2017 um 19:28 schrieb Jacob Champion:

Administrators using prefork who would like to switch to HTTP/2 in the future need to 
understand the limitations of the prefork architecture they have selected. And sure, our 
users can request that we implement a solution that "just works" with prefork, 
with the parent dispatcher that Stefan has mentioned, and we can weigh the cost/benefit 
of implementing it. But IMO it's not that onerous to ask our users to upgrade to a modern 
MPM if they want a nice new protocol


well, when i see how fragile the combination of httpd and php-fpm still is, 
thanks, but no

Apache:
COMPATIBILITY: mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the default 
ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202

PHP:
Fixed bug #74738 (Multiple [PATH=] and [HOST=] sections not properly parsed).
https://bugs.php.net/bug.php?id=74738


That PHP bug affects parsing of PHP-FPM's config file. It has nothing to do 
with the FastCGI interface or its runtime behavior


fine, but i can't remember something similar in the past 15 years with 
mod_php and that this makes it to stable releases when php-fpm is "the 
new way to go" for a longer time is not the best sign

Re: 2.4.27

[Reindl Harald]

Am 06.07.2017 um 19:28 schrieb Jacob Champion:
Administrators using prefork who would like to switch to HTTP/2 in the 
future need to understand the limitations of the prefork architecture 
they have selected. And sure, our users can request that we implement a 
solution that "just works" with prefork, with the parent dispatcher that 
Stefan has mentioned, and we can weigh the cost/benefit of implementing 
it. But IMO it's not that onerous to ask our users to upgrade to a 
modern MPM if they want a nice new protocol


well, when i see how fragile the combination of httpd and php-fpm still 
is, thanks, but no


Apache:
COMPATIBILITY: mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the 
default ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202


PHP:
Fixed bug #74738 (Multiple [PATH=] and [HOST=] sections not properly 
parsed).

https://bugs.php.net/bug.php?id=74738

Re: 2.4.27

[Reindl Harald]

Am 06.07.2017 um 19:02 schrieb William A Rowe Jr:
+1 to removing support of mom prefork. I'd prefer it still start and if 
configured, with an [error] level alert in the logs and simply be 
disabled. Server must start when module is loaded but not configured, 
e.g. in test framework, IMO


with removing mpm_prefork support for H2 you kill HTTP2 support for a 
lot of production setups which may consider switch to H2 in the future 
and for sure not rework there whole configuration but put a proxy like 
Trafficserver in front and forget about httpd at this point at all


besides the technical consideration above - starting to ignore features 
for mod_prefork in the middle of a lifetime cycle leaves a bad taste in 
general


disclaimer: no i can't fix the issues - i have just my admin hat on

Re: [VOTE] Release Apache httpd 2.4.26 as GA

[Reindl Harald]

Am 13.06.2017 um 19:33 schrieb Jim Jagielski:

The pre-release test tarballs for Apache httpd
version 2.4.26 can be found at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.26 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.

Vote will last the normal 72 hrs.

NOTE: The *-deps are only there for convenience


looks good so far with apr 1.5 on Fedora 25 because somebody should fix 
https://www.apache.org/dist/apr/ and when you look closer you see 1.6.x 
below


APR 1.5.2 is the latest available version
APR-util 1.5.4 is the latest available version
APR-iconv 1.2.1 is the latest available version
APR 0.9.20 is also available
APR-util 0.9.19 is also available
APR-iconv 0.9.7 is also available

Re: VUDDY: unpatched CVEs in apache httpd

[Reindl Harald]

Am 24.05.2017 um 19:12 schrieb Eric Covener:

On Wed, May 24, 2017 at 1:05 PM, Reindl Harald <h.rei...@thelounge.net> wrote:

than also the source should not be bundeled and instead a requirement to
have it installed for build


Already covered ITT: "apr-util 1.6.0 will ship without an embedded
copy of the expat software."


sorry, i missed the "without" and "Obtaining expat and keeping it 
refreshed and up to date with respect to security patches will become an 
exercise for the user/admin/vendor" sound typically more like the usual 
problem of httpd, php and others having burried a random version inside 
the soorce tarball


for user/admin/vendor it's nothing different than any of the other 
undrets to thousands of packages on their system "yum/dnf upgrade, 
apt-get upgrade.." and now they *really* are up-to-date

Re: VUDDY: unpatched CVEs in apache httpd

[Reindl Harald]

Am 24.05.2017 um 17:46 schrieb Eric Covener:

On Wed, May 24, 2017 at 11:44 AM, Reindl Harald <h.rei...@thelounge.net> wrote:

and why does it need to be an embedded copy?


It's not required to be embedded


than also the source should not be bundeled and instead a requirement to 
have it installed for build - problem is with the bundeling many people 
don't realize that their system updates for libraries don't cover the 
default build of random software - httpd/apr is just one of them

Re: VUDDY: unpatched CVEs in apache httpd

[Reindl Harald]

Am 24.05.2017 um 17:02 schrieb William A Rowe Jr:

apr-util 1.6.0 will ship without an embedded copy of the expat software.

Obtaining expat and keeping it refreshed and up to date with respect
to security patches will become an exercise for the user/admin/vendor.

This is scheduled for "RSN" - real soon now


and why does it need to be an embedded copy?
bundle libraries is the start of all evil

[root@buildserver:~]$ rpm -qa |grep expat
expat-2.1.1-2.fc24.x86_64
expat-devel-2.1.1-2.fc24.x86_64

RedirectMatch: unexpected behavior within

[Reindl Harald]

 
  RedirectMatch 404 "(?i)\/[\.]{0,1}(cvs|svn)\/"
 


that above don't work and don't warn as it is normally the case where a 
"apachectl -t" clearly says "syntax error, xxx not allowed here"


don't work means RedirectMatch also applies to GET-requests which makes 
it really hard to restrict extensions like below only for normal 
webacess which is chained into "AllowMethods GET HEAD POST" but at the 
same time allow time for mod_dav_svn methods


well, and there is also no option to remove one or all global set 
"RedirectMatch" for a specific directory


RedirectMatch 404 
"(?i)\.(asax|ascx|ashx|asmx|asp|aspx|axd|back|backup|bak|bat|cfm|class|class\.php|cmd|conf|config|csproj|dat|data|db[0-9]{0,1}|dll|ds_store|exe|fbcindex|idc|inc|ini|jhtml|jsp|jspa|key|log|mdb|mdf|mscgi|nasl|nsf|ocx|old|pl|py|rb|sample|sav|save|sh|shtm|sql|sqlite|vbproj|vbs|webinfo)$"

Re: Apache leaves shared memory segments

[Reindl Harald]

and also "-k stop" don't remove them

read HTTPD_PID < "$PROFILE_ROOT/logs/httpd.pid"
$HTTPD_BINARY -f "$PROFILE_ROOT/httpd.conf" -k stop
exit 0

[builduser@testserver:/rpmbuild/PHP-PGO]$ ipcs -m | wc -l
12
[builduser@testserver:/rpmbuild/PHP-PGO]$ ./profile.sh
[builduser@testserver:/rpmbuild/PHP-PGO]$ ipcs -m | wc -l
13
[builduser@testserver:/rpmbuild/PHP-PGO]$ ./profile.sh
[builduser@testserver:/rpmbuild/PHP-PGO]$ ipcs -m | wc -l
14

[builduser@testserver:/rpmbuild/PHP-PGO]$ ipcs -m
-- Shared Memory Segments 
keyshmid  owner  perms  bytes  nattch status
0x661403ad 0  root   6001000   2
0x151450bd 32769  root   6001000   6
0x0121019a 65538  builduser  6002560
0xc121019a 98307  builduser  6002560
0x8621019a 131076 builduser  6002560
0xdf21019a 163845 builduser  6002560
0x1b210199 196614 builduser  6002560
0x99210199 229383 builduser  6002560
0xe2210199 262152 builduser  6002560
0x5d210199 294921 builduser  6002560


Am 17.04.2017 um 13:28 schrieb Reindl Harald:

https://bz.apache.org/bugzilla/show_bug.cgi?id=7838
that still happens with 2.4.25

"killall httpd 2> /dev/null" in a script starting a temporary httpd for 
php-pgo-profiling since it's a SIGTERM should not leave them and finally 
fail after enough runs to allocate shm segment for auth_digest until you 
reboot


  killall httpd 2> /dev/null
  sleep 2
  rm -f "$PROFILE_ROOT/php.ini"
  rm -f "$PROFILE_ROOT/httpd.conf"
  rm -f "$PROFILE_ROOT/logs/sess_"*
  rm -f "$PROFILE_ROOT/logs/authdigest"*
  rm -f "$PROFILE_ROOT/logs/httpd.pid"
  rm -f "$PROFILE_ROOT/logs/modsec"*

the 256 bytes are pretty clear from "AuthDigestShmemSize 256"

$HTTPD_BINARY -X -f "$PROFILE_ROOT/httpd.conf" to make sure there is 
only one httpd process should not take longer than the 2 seconds sleep 
given that it handles 1500 serial requests within 10 seconds before


[builduser@testserver:/rpmbuild/PHP-PGO]$ ipcs -m

-- Shared Memory Segments 
keyshmid  owner  perms  bytes  nattch status
0x661403ad 0  root   6001000   2
0x151450bd 32769  root   6001000   6
0x0121019a 65538  builduser  6002560
0xc121019a 98307  builduser  6002560
0x8621019a 131076 builduser  6002560

Apache leaves shared memory segments

[Reindl Harald]

https://bz.apache.org/bugzilla/show_bug.cgi?id=7838
that still happens with 2.4.25

"killall httpd 2> /dev/null" in a script starting a temporary httpd for 
php-pgo-profiling since it's a SIGTERM should not leave them and finally 
fail after enough runs to allocate shm segment for auth_digest until you 
reboot


 killall httpd 2> /dev/null
 sleep 2
 rm -f "$PROFILE_ROOT/php.ini"
 rm -f "$PROFILE_ROOT/httpd.conf"
 rm -f "$PROFILE_ROOT/logs/sess_"*
 rm -f "$PROFILE_ROOT/logs/authdigest"*
 rm -f "$PROFILE_ROOT/logs/httpd.pid"
 rm -f "$PROFILE_ROOT/logs/modsec"*

the 256 bytes are pretty clear from "AuthDigestShmemSize 256"

$HTTPD_BINARY -X -f "$PROFILE_ROOT/httpd.conf" to make sure there is 
only one httpd process should not take longer than the 2 seconds sleep 
given that it handles 1500 serial requests within 10 seconds before


[builduser@testserver:/rpmbuild/PHP-PGO]$ ipcs -m

-- Shared Memory Segments 
keyshmid  owner  perms  bytes  nattch status
0x661403ad 0  root   6001000   2
0x151450bd 32769  root   6001000   6
0x0121019a 65538  builduser  6002560
0xc121019a 98307  builduser  6002560
0x8621019a 131076 builduser  6002560

Re: APr Utils and PostgreSQL

[Reindl Harald]

Am 09.04.2017 um 13:16 schrieb Tom Browder:
On Sat, Apr 8, 2017 at 18:34 Nick Kew > wrote:


On Sat, 2017-04-08 at 16:43 -0500, Tom Browder wrote:

 > config.log
 >
 > https://gist.github.com/tbrowder/2878124ad5fc35cb71a65a38e2950583

OK, where did you read that --with-pgsql would work with HTTPD's
configure?  If it's anywhere at apache.org , we
have a docs bug.
You need to build apr-util with pgsql!  Or use your distro package.

With all due respect, Nick, the build and installation docs need some 
work.  Some time ago, when I first started building httpd, the included 
build seemed to be the way to go. That implied, at least to me, that 
configuration options passed to httpd would get passed to apr and 
apr-util.  Otherwise, how does sqlite3 get built in my case (and how 
does pgsql NOT get built)?


no distribution out there is using the bundeled apr for good reasons

1: build and install apr
2: build and install apr-util which uses apr
3: build httpd

https://www.apache.org/dist/apr/
https://www.apache.org/dist/httpd/

[builduser@testserver:/rpmbuild/PHP-PGO]$ cd /rpmbuild/SPECS/
[builduser@testserver:/rpmbuild/SPECS]$ ls | grep apr
-rw-r- 1 builduser builduser 3,4K 2017-03-16 12:49 apr.spec
-rw-r- 1 builduser builduser 4,2K 2017-03-16 12:49 apr-util.spec

[builduser@testserver:/rpmbuild/SPECS]$ ls | grep httpd
-rw-r- 1 builduser builduser  20K 2017-02-20 04:54 httpd.spec

and for start building software you should look how your distribution 
does it, on Redhat systems you have the src,rpm packages and the spec 
files contain very clear BuildRequires and you should vene use that 
spec-files and modify them for your needs as start

Re: APr Utils and PostgreSQL

[Reindl Harald]

Am 07.04.2017 um 18:14 schrieb Yann Ylavic:

On Fri, Apr 7, 2017 at 6:06 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


main question: why in the world are you building from source?
https://packages.debian.org/jessie/libaprutil1-dbd-pgsql


It happens sometimes on a dev@ list ;)


well, but that's the httpd-devel list and he talks about build apr which 
didn't change it's version for years :-)

Re: APr Utils and PostgreSQL

[Reindl Harald]

Am 07.04.2017 um 18:10 schrieb Tom Browder:

On Fri, Apr 7, 2017 at 11:06 AM, Reindl Harald <h.rei...@thelounge.net> wrote:

main question: why in the world are you building from source?
https://packages.debian.org/jessie/libaprutil1-dbd-pgsql


Because I want to be running the latest httpd (and use pgsql and
splite3), and I didn't know of the package you mentioned:

   libaprutil1-dbd-pgsql


well, i am a Redhat user and just typed "debian apr pgsql" into google
debian and many other distributions have subpackages
though the package naming of debian is weird

apr-util-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-devel-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-freetds-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-ldap-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-mysql-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-nss-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-odbc-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-openssl-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-pgsql-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-sqlite-1.5.4-5.fc26.x86_64.rpm (info) (download)
apr-util-debuginfo-1.5.4-5.fc26.x86_64.rpm (info) (download)

Re: APr Utils and PostgreSQL

[Reindl Harald]

Am 07.04.2017 um 17:53 schrieb Tom Browder:

On Fri, Apr 7, 2017 at 10:11 AM, Reindl Harald <h.rei...@thelounge.net> wrote:



Am 07.04.2017 um 17:06 schrieb Tom Browder:


On Fri, Apr 7, 2017 at 09:53 Jordan Gigov <colad...@gmail.com
<mailto:colad...@gmail.com>> wrote:

 The =DIR parameter is optional. If you have the libpq-dev package
 installed, it should find it automatically.

I do have the dev package installed, but it didn't find it.  In the
interim, would creating a pkg-config pc file and pointing DIR at it work?



http://www.catb.org/esr/faqs/smart-questions.html#beprecise

why don't you tell in your first post relevant informations?

* exact os version
* installed packages
* complete ./configure line
* complete output of ./configure


Okay.


"I do have the dev package installed" 4 posts later - seriously?


Well, mea culpa, but I didn't think of it since it's so basic, sorry.


yes, that's all basic, hnce it works everywhere but in your case


Packages  with postgresql in their name:

$ aptitude search postgres | grep ^i
i A postgresql-client-common- manager for multiple PostgreSQL client ver
i A postgresql-common   - PostgreSQL database-cluster manager
i A postgresql-server-dev-9.4   - development files for PostgreSQL 9.4 serve
i   postgresql-server-dev-all   - extension build tool for multiple PostgreS


looks good, i guess debian has a weird naming sicne it's the client 
libraries you link against



   https://gist.github.com/tbrowder/451e0f735bd281dde6694f189b8f6d61


https://gist.github.com/tbrowder/451e0f735bd281dde6694f189b8f6d61

don't show any errors and postgresql is stattet with yes
so what is your *problem*
hecking postgresql/libpq-fe.h usability... yes
checking postgresql/libpq-fe.h presence... yes
checking for postgresql/libpq-fe.h... yes

main question: why in the world are you building from source?
https://packages.debian.org/jessie/libaprutil1-dbd-pgsql

Re: APr Utils and PostgreSQL

[Reindl Harald]

Am 07.04.2017 um 17:06 schrieb Tom Browder:
On Fri, Apr 7, 2017 at 09:53 Jordan Gigov > wrote:


The =DIR parameter is optional. If you have the libpq-dev package
installed, it should find it automatically.

I do have the dev package installed, but it didn't find it.  In the 
interim, would creating a pkg-config pc file and pointing DIR at it work?


http://www.catb.org/esr/faqs/smart-questions.html#beprecise

why don't you tell in your first post relevant informations?

* exact os version
* installed packages
* complete ./configure line
* complete output of ./configure

"I do have the dev package installed" 4 posts later - seriously?

Re: APr Utils and PostgreSQL

[Reindl Harald]

Am 07.04.2017 um 15:28 schrieb Tom Browder:

I am trying to get the pqsql lib built and cannot get the config
option correct.  The help says:

   with-pgsql=DIR

What DIR, please?  Each package seems to have a different definition
of DIR. I have these on my Deb 8 system


none when you are working with default environments, that's the same for 
every type of software and such options be it httpd, php or something else


you just need to install the dev-packages for compile and it will be 
found automatically (on redhat they are called -devel)


http://stackoverflow.com/questions/1157192/what-do-the-dev-packages-in-the-linux-package-repositories-actually-contain

Re: [RFC] ?

[Reindl Harald]

Am 21.02.2017 um 23:24 schrieb Eric Covener:

On Tue, Feb 21, 2017 at 5:20 PM, Reindl Harald <h.rei...@thelounge.net> wrote:



Am 21.02.2017 um 22:58 schrieb Joe Orton:


For cases like HttpProtocolOptions where a new directive is introduced
to multiple active branches simultaneously, it gets awkward to use
 to write conf files which use the new directive but are
compatible across multiple versions.

Triggered by a conversation with a user, but also e.g. see current test
suite t/conf/extra.conf.in which breaks for 2.4 releases older than
2.4.25 with:

  = 2.2.32>

  DocumentRoot @SERVERROOT@/htdocs/
  HttpProtocolOptions Strict Require1.0 RegisteredMethods

Any reason  is a bad idea, so we can do that more cleanly
(... in a couple of decades time)?



you need to wrap that at least in  since mod_version is not
mandatory and httpd if unforgiving for unknown options

for the same reason the dance below is needed


 
  Require all denied
 
 
  Order deny,allow
  Deny from All
 


 
  Order deny,allow
  Deny from all
 
 = 2.4>
  Require all denied
 



Kind of weird to keep the 

in *this* example maybe, in general the "= 2.4>" can be more 
specific like "= 2.4>" because there where options added in 
2.4.x releases which would stop httpd on older minor versions and 
especially in conext of LTS distributions you don't always know which 
features are really in the 2.4.x-distr


SSLCompression
Available in httpd 2.4.3 and later

so you can write a config which is safe for any httpd but chain it to 
recent features if available and *if* mod_version is available

Re: [RFC] ?

[Reindl Harald]

Am 21.02.2017 um 22:58 schrieb Joe Orton:

For cases like HttpProtocolOptions where a new directive is introduced
to multiple active branches simultaneously, it gets awkward to use
 to write conf files which use the new directive but are
compatible across multiple versions.

Triggered by a conversation with a user, but also e.g. see current test
suite t/conf/extra.conf.in which breaks for 2.4 releases older than
2.4.25 with:

  = 2.2.32>

  DocumentRoot @SERVERROOT@/htdocs/
  HttpProtocolOptions Strict Require1.0 RegisteredMethods

Any reason  is a bad idea, so we can do that more cleanly
(... in a couple of decades time)?


you need to wrap that at least in  since mod_version is not 
mandatory and httpd if unforgiving for unknown options


for the same reason the dance below is needed


 
  Require all denied
 
 
  Order deny,allow
  Deny from All
 


 
  Order deny,allow
  Deny from all
 
 = 2.4>
  Require all denied
 

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 08.02.2017 um 00:44 schrieb Yann Ylavic:

On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic <ylavic@gmail.com> wrote:

On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald <h.rei...@thelounge.net> wrote:


how can you trust as a php application developer that "X-Forwarded-Proto" is
trustable and not from the enduser client at all - for REMOTE_ADDR you don't
consider "X-Forwarded-For" exactly for that reason


I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
that mod_remoteip [either directly or provides the (optional)
functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
and/or REMOTE_SCHEME=https accordingly.
Just like REMOTE_ADDR.

But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
sources/hooks as accessed and read by core/modules), like (IIUC)
proposed by the patches.
These are local informations.


Actually, I'm not really opposed to set HTTPS=on (according to
mod_remoteip) in the environment *given to the script/CGI* only, if
that's the trigger for it to do the desired thing, this won't be used
by httpd internally at least.

What's proposed so far is much more than that (if I read the patches correctly)


ok, so finally we agree :-)

i am only interested in a centralized way to get rid of hacks like below 
in each and every application where mod_remoteip solves the similar 
problem with $_SERVER['REMOTAE_ADDR'] for cgi/mod_php


$_SERVER['REQUEST_SCHEME'] because you typically build a full qualifiied 
URL for a link in emails with $_SERVER['REQUEST_SCHEME'] . '//' . 
$_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] . '?param=x'


in my own application the hack below was simple - in case of other 
software like Magento and so on you have to hack "index.php" while at 
the same time you should not touch the application code to keep it 
easily updateable


if(!empty($config['cms_tls_offload']))
{
 $_SERVER['SERVER_PORT']= '443';
 $_SERVER['REQUEST_SCHEME'] = 'https';
 $_SERVER['HTTPS']  = 'on';
}

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 23:50 schrieb Yann Ylavic:

On Tue, Feb 7, 2017 at 11:34 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 07.02.2017 um 22:53 schrieb Yann Ylavic:


I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes)


for that you would need to touch each and every application and you have not
secure way to know for sure if that header is trustable, when mod_remoteip
is part of the game you even don't know (and should not know) the physical
connecting IP


I agree with that, "X-Forwarded-Proto or whatever" was meant to say "a
trustable information", and I even agree that's mod_remoteip's job to
give that information.

I just don't think we should make as if httpd were running https (i.e.
for all modules/applications to think it is), but rather give the real
information: trustable remote is running https


with a wayback machine this would be pretty cool, but whatever you do at 
this point in time needs to


a) get implemented in the tls offlaoding software
b) get implemented in the backend-server (httpd)
c) get implemented in each and every web application

while a) and b) are realistic in a mid-term timeframe c) is not and 
additionally c) needs to to it secure


to do it secure is even a real problem

how can you trust as a php application developer that 
"X-Forwarded-Proto" is trustable and not from the enduser client at all 
- for REMOTE_ADDR you don't consider "X-Forwarded-For" exactly for that 
reason


when mod_remoteip is in place "X-Forwarded-For" contains only untrusted 
informations and the ip of your own proxy is ripped out of that header


without mod_remoteip you get unfiltered whatever came over the wire and 
you have no idea within the php application if you are behind a proxy at 
all


at least not trusted one and even if httpd promises in a later version 
that you don't get that header from untrusted sources you have no idea 
if the httpd on your hoster has that promise (LTS distributions with no 
real versions) and there are other webservers too


hence application developers are advised making no decisions based on 
that header - i would find it questionable having a "X-Forwarded-Proto" 
where you have to deal with in the application and "X-Forwarded-For" 
where you *must not* process it for security reasons

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 22:53 schrieb Yann Ylavic:

On Tue, Feb 7, 2017 at 10:14 PM, Jordan Gigov  wrote:

On 7 February 2017 at 22:33, Yann Ylavic  wrote:

I'm a bit reluctant with these patches, and probably need to be
convinced this isn't an application issue in the first place (why not
use X-Forwarded-Proto or alike to achieve the same? i.e. generate
https links...), or an SSL endpoint issue (why not rewrite URLs or
alike there?).

It can be X-Forwarded-Proto or whatever you set it to with my patch
(for the standard method of proxying).
I can't speak to the ProxyProtocol one.

I also don't see what you mean by an "application issue".


I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes)


for that you would need to touch each and every application and you have 
not secure way to know for sure if that header is trustable, when 
mod_remoteip is part of the game you even don't know (and should not 
know) the physical connecting IP


and so when you write a application to directly proceed that header you 
make your application vulnerable in every environment where the outside 
client fakes that header


dealing with it the same way as for REMOTE_ADDR would make it 100% 
transparent for the application and it would only trigger if the admin 
configured the underlying server as he does with mod_remoteip's 
"RemoteIPInternalProxy"


it's not a application issue - the application must not know anything 
about infrastructure decisions - it's the job of the underlying 
infrastructure

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 21:33 schrieb Yann Ylavic:

My point is that we are not changing/masquarading something which is
remote here (like the client IP address), we are making so that the
applications and httpd itself think they are locally talking SSL/TLS.
Thus they will send things like "; Secure" cookies in "clear" on the
wire, or anything which is expected to not be eavesdrop-able.

I'd like others from the community to give their opinions here, for
now I find this quite opposite to TLS principles/expectations...


it's exactly how it should work - proxy to backend unencrypted, caching 
on the proxy and transport security between proxy endpoint and web client


that is what is meant by "TLS offloading" - it's not your problem how 
secure that wire is, on our VMware-cluster the hosts even don#t talk 
about a switch - they are directly connected for internal traffic and so 
that wire is as secure as the virtual machine itself

Re: Underscores in hostnames

[Reindl Harald]

Am 02.02.2017 um 14:22 schrieb Reindl Harald:



Am 02.02.2017 um 13:53 schrieb Joe Orton:

Another 2.4.25 regression reported from a Fedora user is that
underscores in hostnames are rejected by default now.  I couldn't see a
specific discussion of this, was it deliberate?


underscores are not allowed in host names by RFC and many things will
break at all with them because in different layers of client software
things just break by using them

we had that more than once in devel environments where strange bugs
turend out to be another case where sombody used a underline in
/etc/hosts and his local webserver


here you go:
https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames

The Internet standards (Requests for Comments) for protocols mandate 
that component hostname labels may contain only the ASCII letters 'a' 
through 'z' (in a case-insensitive manner), the digits '0' through '9', 
and the hyphen ('-'). The original specification of hostnames in RFC 
952, mandated that labels could not start with a digit or with a hyphen, 
and must not end with a hyphen. However, a subsequent specification (RFC 
1123) permitted hostname labels to start with digits. No other symbols, 
punctuation characters, or white space are permitted.


While a hostname may not contain other characters, such as the 
underscore character (_), other DNS names may contain the underscore.[4] 
Systems such as DomainKeys and service records use the underscore as a 
means to assure that their special character is not confused with 
hostnames. For example, _http._sctp.www.example.com specifies a service 
pointer for an SCTP capable webserver host (www) in the domain 
example.com. Note that some applications (e.g. Microsoft Internet 
Explorer) won't work correctly if any part of the hostname contains an 
underscore character.[5]

Re: Underscores in hostnames

[Reindl Harald]

Am 02.02.2017 um 13:53 schrieb Joe Orton:

Another 2.4.25 regression reported from a Fedora user is that
underscores in hostnames are rejected by default now.  I couldn't see a
specific discussion of this, was it deliberate?


underscores are not allowed in host names by RFC and many things will 
break at all with them because in different layers of client software 
things just break by using them


we had that more than once in devel environments where strange bugs 
turend out to be another case where sombody used a underline in 
/etc/hosts and his local webserver

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Reindl Harald]

Am 26.01.2017 um 00:20 schrieb David Zuelke:

On 20.01.2017, at 21:37, Graham Leggett  wrote:


On 20 Jan 2017, at 7:47 PM, David Zuelke  wrote:


I'd actually like to question the whole practice of porting features back to 
older branches. I think that's the core reason why trunk is in total disarray, 
and why no substantial releases have been made. There is just no reason for 
anyone to push forward the state of 2.6 or even 3.0 if you can just backport 
whatever you want.


The reason this is bad is because Apache httpd comes with a module ecosystem - 
when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the 
ABI can break, and therefore all modules that depend on that version must be 
recompiled. This includes modules that are closed source and offered by a 
proprietary vendor, or are open source but provided in binary form by a distro.


Yeah, I hadn't considered proprietary modules.

To take the PHP example, ABI and API changes are usually minimal, so most 
extensions build pretty cleanly; if not, then they can be fixed, and with most 
stuff on GitHub these days, that's usually a PR away. Development cycles of 
extensions have definitely sped up together with the language runtime.

Do people who run a non-distro httpd really install distro-provided modules 
though?


yes - i build httpd, mod_security, apr, php, pecl-extensions from source 
(own rpm packages) but don't want to maintain the whole subversion 
package and it's build-dependencies too (mod_dav_svn)


but on the other hand in that case i won't jump to the next httpd 
release until the distribution (Fedora) does, at least not for a larger 
timeframe than prepare the upgrade on a testing vm

Re: [proposed] 2.4 Maintenance SIG

[Reindl Harald]

Am 23.01.2017 um 02:52 schrieb Noel Butler:

Perhaps the only person who wont bend over and take it up the arse like
some people here expect, if I have an opinion, i'll voice it


no, you are just a hypocrite trying to forbid others voice their opinion 
in their weay but not follow your own rules to always say critics nice 
and lovely and so you have no point to play internet police on mailing 
lists any longer

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Reindl Harald]

Am 19.01.2017 um 22:43 schrieb William A Rowe Jr:

I think one of our disconnects with 2.4 -> 2.6 is that in any other
framework, there would be no ABI breakage in 2.6. That breakage
would be deferred to and shipped as 3.0


every PHP version in the past decade (5.3, 5.4, 5.6, 7.0, 7.1, 7.2) is a 
ABI breakage by definition and that's what the second number in the 
version stands for (major.minor.revision)


the same for MySQL 5.0, 5.1 and 5.5 all changed the ABI and caused mass 
rebuilds of linux distributions for every depending package


sorry but no idea how you come to that conclusion

however, the ABI change don't bother the userbase, incompatible config 
changes when the software don't know something like warnings but refuse 
to start when there is a option which is from a later release or a 
option which was removed is what brings people in trouble like one 
needed weeks to migrate every peice of configuration inclduding 
.htaccess files where you still have the same problem when you install 
Magento and did not disable .htaccess entirely

Re: [proposed] 2.4 Maintenance SIG

[Reindl Harald]

Am 19.01.2017 um 08:22 schrieb Stefan Eissing:

Distros seem to have realized the problem long ago and make their own httpd versions. 
First time I realized my "httpd 2.4.7" is not the 2.4.7 release was a WTF 
moment.


no, that applies to LTS distros and in that case of nearly any piece of 
software and has nothing to do with httpd or the problems you are 
talking about


httpd-2.4.6-45.el7.centos.x86_64
mod_security-2.7.3-5.el7.x86_64

php-5.4.16-42.el7.x86_64:
* Fr Aug 05 2016 Remi Collet  - 5.4.16-42
- bz2: fix improper error handling in bzread() CVE-2016-5399

* Mo Aug 01 2016 Remi Collet  - 5.4.16-41
- gd: fix integer overflow in _gd2GetHeader() resulting in
  heap overflow CVE-2016-5766
- gd: fix integer overflow in gdImagePaletteToTrueColor()
  resulting in heap overflow CVE-2016-5767
- mbstring: fix double free in _php_mb_regex_ereg_replace_exec
  CVE-2016-5768

* Fr Jul 22 2016 Remi Collet  - 5.4.16-40
- don't set environmental variable based on user supplied Proxy
  request header CVE-2016-5385

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 08.01.2017 um 11:01 schrieb Stefan Eissing:

There is the reverse situation which is called opportunistic encryption, namely 
the transfer of a http: request over a TLS connection.

Both cases are tricky on HTTP/1.x because the URI scheme is not transported in requests 
(commonly. the spec would allow it but no one does it, so no one is prepared to 
honor/handle it). HTTP/2, with opportunistic encryption in mind, added the 
":scheme" header for this. But implementation is also tricky.

So, mod_http2 has similar problems to this ATS setup: convincing the request 
processing parts in the server that a request has a certain scheme, 
*independent* of mod_ssl's presence. I think it would be nice if we could fix 
this.

One approach that comes to mind:
 * add the uri scheme to request_rec->scheme
 * set it by:
   1. parse the request uri
   2. if not set, fix it in very late read hooks to "http:"
   3. have mod_ssl install an earlier hook that sets "https:" if not present
 * check that URI host and Host: header are an allowed combination
 * check that r->scheme and r->server are an allowed combination

ATS would then be configured to forward requests to the httpd backend by using 
absolute request uris (so they carry the scheme) or HTTP/2. httpd would be 
configured to accept https: uris from ATS remote ip.

And while there are numerous parts/applications where the wheels fall off in 
such a setup, it is not the default setup. No one initially needs to be able to 
get it right. But in a concrete deployment, the configuration can be made and 
the application code fixed where necessary.


yeah - something more or less standard instead
a) change this in tttpd config
b) change this in ATS config, dunno how handle it with a different proxy
c) change this in your application

when there is something you can detect in the application code when 
proxy / backend play in a more or less defined way together other 
proxies and backend servers could follow



Am 07.01.2017 um 09:30 schrieb Reindl Harald <h.rei...@thelounge.net>:

* Apache Trafficserver in front
* ATS configured for TLS-offloading
* connection to backend-httpd on the LAN unencrypted
* mod_remoteip correctly configured on backend httpd

is there any way to make the backend php application aware that in fact 
$_SERVER['HTTPS'] and $_SERVER['REQUEST_SCHEME'] should be 'on' / https:// in 
case of generate absolute URLs like for emails

in a perfect world this would be handeled like the transparent translation of the client 
IP with https://httpd.apache.org/docs/current/mod/mod_remoteip.html and it's 
RemoteIPInternalProxy and a header like "X-Forwarded-TLS"

something like below where "X-TLS-Offloading" is only evaluated from 
"RemoteIPInternalProxy" pyhsical addressess

RemoteIPHeader X-Forwarded-For
RemoteTLSHeaderX-TLS-Offloading
RemoteIPInternalProxy  192.168.196.1

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 08.01.2017 um 00:31 schrieb Yann Ylavic:

On Sun, Jan 8, 2017 at 12:22 AM, Reindl Harald <h.rei...@thelounge.net> wrote:


ok, so we need to continue the code below and set the option in every
tls-offloaded application - intention of this thread was maybe get this
transparent which seems not to be possible


It is "technically" possible, but not wise IMHO.
Making every httpd module/CGI/app think the local connection is https
could lead to things like "; Secure" cookies sent on the (clear) wire,
and that option would be accompanied with so much warnings ("unless
you're really on the same switch, but even that...") that it'd be hard
to defend (endlessly?).


excatly *that* would be the desired result if configured that way 
because the "clear wire" is controlled and trusted in that context and 
you *want* the secure flag sent for cookies between the tls-offloading 
server and the enduser to not get them back unencrypted over the "real 
clear wire"


the whole purpose of *tls offloading* is run the application on a 
virtual machine with a preforked httpd and encryption on the 
reverse-proxy running multithreaded with keep-alive


another secuity gain here is that the amchine which runs application 
code never has a change to see the private ssl key while a breach on the 
proxy with no application code is less likely



if(!empty($cms_tls_offload))
{
 $_SERVER['REQUEST_SCHEME'] = 'https';
 $_SERVER['HTTPS']  = 'on';
}


Your choice ;)

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 07.01.2017 um 23:53 schrieb Yann Ylavic:

On Sat, Jan 7, 2017 at 11:25 PM, Reindl Harald <h.rei...@thelounge.net> wrote:

Am 07.01.2017 um 22:53 schrieb Yann Ylavic:


Wouldn't something like this work?

RewriteRule on
RewriteCond %{ENV:remoteip-proxy-ip-list} .
RewriteCond %{HTTP:X-TLS-Offloading} ^true$
RewriteRule ^ - [E=HTTPS:on,E=REQUEST_SCHEME:https]


That wouldn't work anyway, both variables will be overridden later
when the env is constructed.


Given that remoteip-proxy-ip-list is filled by mod_remoteip if (and
only if) RemoteIPInternalProxy matches


currently not because nothing provides "X-TLS-Offloading" which is the
reason for add both parties to this conversation


OK, that's a prerequisite in any case..


such global rewrite rules are not very appealing while the intention of get
this handeled by mod_remoteip is that for the admin this would be the
central place to deal with backendsservers with a proxy in front


Admittedly.


it is handeled perfectly for the REMOTE_ADDR where for every access(deny
rules, loggings, mod_security-rules and within applications you can trust
it's the clients IP and not one from own infrastructure


Right, but HTTPS and REQUEST_SCHEME have a meaning for the httpd
server, and they refer to its *local* configuration, so overriding
them is very misleading (and does not work as mentioned above).

Thus RemoteTLSHeader cannot be something that overrides them, and the
best it could do is to unset the header if not trusted.


end-to-end-encryption (one argunmet which came against it) is something one
needs to consider anyways if TLS-offloading come into the mix and the
connection between proxy and backend needs to be 100% trusted, but it's a
great way to spread load of generate dynamic content and encryption to
different machines and should be 100% transparent to the application


From the above, the app would have to rely on the (un)defined
RemoteTLSHeader instead of HTTPS/REQUEST_SCHEME, so it can't be as
transparent you'd like...

A new mod_remoteip feature for what you could do with mod_rewrite or
mod_headers is less appealing then


ok, so we need to continue the code below and set the option in every 
tls-offloaded application - intention of this thread was maybe get this 
transparent which seems not to be possible


if(!empty($cms_tls_offload))
{
 $_SERVER['REQUEST_SCHEME'] = 'https';
 $_SERVER['HTTPS']  = 'on';
}

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 07.01.2017 um 22:53 schrieb Yann Ylavic:

On Sat, Jan 7, 2017 at 9:30 AM, Reindl Harald <h.rei...@thelounge.net> wrote:


something like below where "X-TLS-Offloading" is only evaluated from
"RemoteIPInternalProxy" pyhsical addressess

RemoteIPHeader X-Forwarded-For
RemoteTLSHeaderX-TLS-Offloading
RemoteIPInternalProxy  192.168.196.1


Wouldn't something like this work?

RewriteRule on
RewriteCond %{ENV:remoteip-proxy-ip-list} .
RewriteCond %{HTTP:X-TLS-Offloading} ^true$
RewriteRule ^ - [E=HTTPS:on,E=REQUEST_SCHEME:https]

Given that remoteip-proxy-ip-list is filled by mod_remoteip if (and
only if) RemoteIPInternalProxy matches


currently not because nothing provides "X-TLS-Offloading" which is the 
reason for add both parties to this conversation


such global rewrite rules are not very appealing while the intention of 
get this handeled by mod_remoteip is that for the admin this would be 
the central place to deal with backendsservers with a proxy in front


it is handeled perfectly for the REMOTE_ADDR where for every access(deny 
rules, loggings, mod_security-rules and within applications you can 
trust it's the clients IP and not one from own infrastructure


end-to-end-encryption (one argunmet which came against it) is something 
one needs to consider anyways if TLS-offloading come into the mix and 
the connection between proxy and backend needs to be 100% trusted, but 
it's a great way to spread load of generate dynamic content and 
encryption to different machines and should be 100% transparent to the 
application


generate links for emails and secure-flag for cookies are the first 
things coming to my mind but likely not all hidden cases where missing 
awarness the the client connection is encrypted may lead to undesired 
behavior

Re: how make backend applications aware about tls-offloading

[Reindl Harald]

Am 07.01.2017 um 17:04 schrieb Jered Floyd:

Does the "sslheaders" experimental plugin meet your needs?

https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/sslheaders.en.html


not really beause it's not transparent to the application and so i can 
continue fake the $_SERVER vars based on application configs - it also 
needs to make sure that this headers never ever are passed through from 
untrusted amchines in front fo the own proxy or faked by clients 
pointing directly to the origin - the way mod_remoteip works takes cae 
of such things


"end-to-end" don't matter when both ATS and httpd are on the same switch 
or even running on the same vritualization host - what matters much more 
is that your applications is aware about the https fact and set the 
*encryption flag for cookies* as example


the fake-by-configuration hacking makes things just more complex because 
you have one more place to care besides DNS, ATS and httpd and the 
Magento hacks placing $_SERVER['xyz'] into 'index.php' are anything but 
not beautiful


well, and for sites which should be reachable with https *and* http you 
can forget this entirely when don't have any clue



- On Jan 7, 2017, at 3:30 AM, Reindl Harald h.rei...@thelounge.net wrote:


* Apache Trafficserver in front
* ATS configured for TLS-offloading
* connection to backend-httpd on the LAN unencrypted
* mod_remoteip correctly configured on backend httpd

is there any way to make the backend php application aware that in fact
$_SERVER['HTTPS'] and $_SERVER['REQUEST_SCHEME'] should be 'on' /
https:// in case of generate absolute URLs like for emails

in a perfect world this would be handeled like the transparent
translation of the client IP with
https://httpd.apache.org/docs/current/mod/mod_remoteip.html and it's
RemoteIPInternalProxy and a header like "X-Forwarded-TLS"

something like below where "X-TLS-Offloading" is only evaluated from
"RemoteIPInternalProxy" pyhsical addressess

RemoteIPHeader X-Forwarded-For
RemoteTLSHeaderX-TLS-Offloading
RemoteIPInternalProxy  192.168.196.1

how make backend applications aware about tls-offloading

[Reindl Harald]

* Apache Trafficserver in front
* ATS configured for TLS-offloading
* connection to backend-httpd on the LAN unencrypted
* mod_remoteip correctly configured on backend httpd

is there any way to make the backend php application aware that in fact 
$_SERVER['HTTPS'] and $_SERVER['REQUEST_SCHEME'] should be 'on' / 
https:// in case of generate absolute URLs like for emails


in a perfect world this would be handeled like the transparent 
translation of the client IP with 
https://httpd.apache.org/docs/current/mod/mod_remoteip.html and it's 
RemoteIPInternalProxy and a header like "X-Forwarded-TLS"


something like below where "X-TLS-Offloading" is only evaluated from 
"RemoteIPInternalProxy" pyhsical addressess


RemoteIPHeader X-Forwarded-For
RemoteTLSHeaderX-TLS-Offloading
RemoteIPInternalProxy  192.168.196.1

Re: --enable-mods-shared don't work

[Reindl Harald]

Am 30.12.2016 um 15:06 schrieb Yann Ylavic:

On Fri, Dec 30, 2016 at 3:00 PM, Reindl Harald <h.rei...@thelounge.net> wrote:

and --enable-modules= don't work too


Doesn't setting --enable-modules=none first help?


see my last post - only partially

normally when i list explicit "this modules shared" and "this modules 
static" there shoul dbe nothing in between

Re: --enable-mods-shared don't work

[Reindl Harald]

and even --enable-modules=none leads to stuff like

checking whether to enable mod_proxy... shared
checking whether to enable mod_proxy_connect... checking dependencies
checking whether to enable mod_proxy_connect... shared (most)
checking whether to enable mod_proxy_ftp... checking dependencies
checking whether to enable mod_proxy_ftp... shared (most)
checking whether to enable mod_proxy_http... checking dependencies
checking whether to enable mod_proxy_http... shared
checking whether to enable mod_proxy_fcgi... checking dependencies
checking whether to enable mod_proxy_fcgi... shared
checking whether to enable mod_proxy_scgi... checking dependencies
checking whether to enable mod_proxy_scgi... shared (most)
checking whether to enable mod_proxy_fdpass... checking dependencies

 --enable-modules=none \
 --enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info 
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
 --enable-mods-static="alias allowmethods auth_basic auth_digest 
authn_core authn_file authz_core authz_groupfile authz_host authz_user 
autoindex deflate dir env expires filter headers log_config mime 
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id 
unixd version" \


while for some parts it is respected like

checking whether to enable mod_file_cache... no (none)
checking whether to enable mod_cache... no (none)
checking whether to enable mod_cache_disk... no (none)
checking whether to enable mod_cache_socache... no (none)

anyways, the stuf fbelow is unasked built

Fehler beim Bauen des RPM:
Installierte (aber nicht gepackte) Datei(en) gefunden:
   /usr/lib64/httpd/modules/mod_lbmethod_bybusyness.so
   /usr/lib64/httpd/modules/mod_lbmethod_byrequests.so
   /usr/lib64/httpd/modules/mod_lbmethod_bytraffic.so
   /usr/lib64/httpd/modules/mod_lbmethod_heartbeat.so
   /usr/lib64/httpd/modules/mod_proxy_ajp.so
   /usr/lib64/httpd/modules/mod_proxy_balancer.so
   /usr/lib64/httpd/modules/mod_proxy_connect.so
   /usr/lib64/httpd/modules/mod_proxy_express.so
   /usr/lib64/httpd/modules/mod_proxy_fdpass.so
   /usr/lib64/httpd/modules/mod_proxy_ftp.so
   /usr/lib64/httpd/modules/mod_proxy_scgi.so
   /usr/lib64/httpd/modules/mod_proxy_wstunnel.so

Am 30.12.2016 um 15:00 schrieb Reindl Harald:

and --enable-modules= don't work too

none of the 3 options mentions "dbm" anywhere

checking whether to enable mod_authn_dbm... shared (most)
checking whether to enable mod_authn_anon... shared (most)
checking whether to enable mod_authn_dbd... shared (most)
checking whether to enable mod_authn_socache... shared (most)


 --enable-modules="alias allowmethods auth_basic auth_digest authn_core
authn_file authz_core authz_groupfile authz_host authz_user autoindex
cgi dav dav_fs dav_lock deflate dir env expires ext_filter filter
headers http2 info log_config mime mime_magic negotiation proxy
proxy_fcgi proxy_http ratelimit remoteip reqtimeout rewrite setenvif
socache_shmcb ssl status substitute unique_id unixd version" \
 --enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
 --enable-mods-static="alias allowmethods auth_basic auth_digest
authn_core authn_file authz_core authz_groupfile authz_host authz_user
autoindex deflate dir env expires filter headers log_config mime
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id
unixd version" \


Am 30.12.2016 um 14:51 schrieb Reindl Harald:

what is the purpose of -enable-mods-shared=MODULE-LIST Space-separated
list of shared modules to enable when

--enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status
substitute" \
--enable-mods-static="alias allowmethods auth_basic auth_digest
authn_core authn_file authz_core authz_groupfile authz_host authz_user
autoindex deflate dir env expires filter headers log_config mime
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id
unixd version" \

leads to

checking whether to enable mod_request... shared (most)
checking whether to enable mod_include... shared (most)

and finally this list of unwanted modules is built?

   /usr/lib64/httpd/modules/mod_access_compat.so
   /usr/lib64/httpd/modules/mod_actions.so
   /usr/lib64/httpd/modules/mod_auth_form.so
   /usr/lib64/httpd/modules/mod_authn_anon.so
   /usr/lib64/httpd/modules/mod_authn_dbd.so
   /usr/lib64/httpd/modules/mod_authn_dbm.so
   /usr/lib64/httpd/modules/mod_authn_socache.so
   /usr/lib64/httpd/modules/mod_authz_dbd.so
   /usr/lib64/httpd/modules/mod_authz_dbm.so
   /usr/lib64/httpd/modules/mod_authz_owner.so
   /usr/lib64/httpd/modules/mod_buffer.so
   /usr/lib64/httpd/modules/mod_cache.so
   /usr/lib64/httpd/modules/mod_cache_disk.so
   /usr/lib64/httpd/modules/mod_cache_socache.so
   /usr/lib64/httpd/modules/

Re: --enable-mods-shared don't work

[Reindl Harald]

and --enable-modules= don't work too

none of the 3 options mentions "dbm" anywhere

checking whether to enable mod_authn_dbm... shared (most)
checking whether to enable mod_authn_anon... shared (most)
checking whether to enable mod_authn_dbd... shared (most)
checking whether to enable mod_authn_socache... shared (most)


 --enable-modules="alias allowmethods auth_basic auth_digest authn_core 
authn_file authz_core authz_groupfile authz_host authz_user autoindex 
cgi dav dav_fs dav_lock deflate dir env expires ext_filter filter 
headers http2 info log_config mime mime_magic negotiation proxy 
proxy_fcgi proxy_http ratelimit remoteip reqtimeout rewrite setenvif 
socache_shmcb ssl status substitute unique_id unixd version" \
 --enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info 
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
 --enable-mods-static="alias allowmethods auth_basic auth_digest 
authn_core authn_file authz_core authz_groupfile authz_host authz_user 
autoindex deflate dir env expires filter headers log_config mime 
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id 
unixd version" \



Am 30.12.2016 um 14:51 schrieb Reindl Harald:

what is the purpose of -enable-mods-shared=MODULE-LIST Space-separated
list of shared modules to enable when

--enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
--enable-mods-static="alias allowmethods auth_basic auth_digest
authn_core authn_file authz_core authz_groupfile authz_host authz_user
autoindex deflate dir env expires filter headers log_config mime
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id
unixd version" \

leads to

checking whether to enable mod_request... shared (most)
checking whether to enable mod_include... shared (most)

and finally this list of unwanted modules is built?

   /usr/lib64/httpd/modules/mod_access_compat.so
   /usr/lib64/httpd/modules/mod_actions.so
   /usr/lib64/httpd/modules/mod_auth_form.so
   /usr/lib64/httpd/modules/mod_authn_anon.so
   /usr/lib64/httpd/modules/mod_authn_dbd.so
   /usr/lib64/httpd/modules/mod_authn_dbm.so
   /usr/lib64/httpd/modules/mod_authn_socache.so
   /usr/lib64/httpd/modules/mod_authz_dbd.so
   /usr/lib64/httpd/modules/mod_authz_dbm.so
   /usr/lib64/httpd/modules/mod_authz_owner.so
   /usr/lib64/httpd/modules/mod_buffer.so
   /usr/lib64/httpd/modules/mod_cache.so
   /usr/lib64/httpd/modules/mod_cache_disk.so
   /usr/lib64/httpd/modules/mod_cache_socache.so
   /usr/lib64/httpd/modules/mod_dbd.so
   /usr/lib64/httpd/modules/mod_dumpio.so
   /usr/lib64/httpd/modules/mod_file_cache.so
   /usr/lib64/httpd/modules/mod_include.so
   /usr/lib64/httpd/modules/mod_lbmethod_bybusyness.so
   /usr/lib64/httpd/modules/mod_lbmethod_byrequests.so
   /usr/lib64/httpd/modules/mod_lbmethod_bytraffic.so
   /usr/lib64/httpd/modules/mod_lbmethod_heartbeat.so
   /usr/lib64/httpd/modules/mod_log_debug.so
   /usr/lib64/httpd/modules/mod_logio.so
   /usr/lib64/httpd/modules/mod_macro.so
   /usr/lib64/httpd/modules/mod_proxy_ajp.so
   /usr/lib64/httpd/modules/mod_proxy_balancer.so
   /usr/lib64/httpd/modules/mod_proxy_connect.so
   /usr/lib64/httpd/modules/mod_proxy_express.so
   /usr/lib64/httpd/modules/mod_proxy_fdpass.so
   /usr/lib64/httpd/modules/mod_proxy_ftp.so
   /usr/lib64/httpd/modules/mod_proxy_hcheck.so
   /usr/lib64/httpd/modules/mod_proxy_scgi.so
   /usr/lib64/httpd/modules/mod_proxy_wstunnel.so
   /usr/lib64/httpd/modules/mod_request.so
   /usr/lib64/httpd/modules/mod_sed.so
   /usr/lib64/httpd/modules/mod_session.so
   /usr/lib64/httpd/modules/mod_session_cookie.so
   /usr/lib64/httpd/modules/mod_session_crypto.so
   /usr/lib64/httpd/modules/mod_session_dbd.so
   /usr/lib64/httpd/modules/mod_slotmem_shm.so
   /usr/lib64/httpd/modules/mod_socache_dbm.so
   /usr/lib64/httpd/modules/mod_socache_memcache.so
   /usr/lib64/httpd/modules/mod_speling.so
   /usr/lib64/httpd/modules/mod_userdir.so
   /usr/lib64/httpd/modules/mod_vhost_alias.so
   /usr/lib64/httpd/modules/mod_watchdog.so

--enable-mods-shared don't work

[Reindl Harald]

what is the purpose of -enable-mods-shared=MODULE-LIST Space-separated 
list of shared modules to enable when


--enable-mods-shared="cgi dav dav_fs dav_lock ext_filter http2 info 
mime_magic negotiation proxy proxy_fcgi proxy_http ssl status substitute" \
--enable-mods-static="alias allowmethods auth_basic auth_digest 
authn_core authn_file authz_core authz_groupfile authz_host authz_user 
autoindex deflate dir env expires filter headers log_config mime 
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id 
unixd version" \


leads to

checking whether to enable mod_request... shared (most)
checking whether to enable mod_include... shared (most)

and finally this list of unwanted modules is built?

   /usr/lib64/httpd/modules/mod_access_compat.so
   /usr/lib64/httpd/modules/mod_actions.so
   /usr/lib64/httpd/modules/mod_auth_form.so
   /usr/lib64/httpd/modules/mod_authn_anon.so
   /usr/lib64/httpd/modules/mod_authn_dbd.so
   /usr/lib64/httpd/modules/mod_authn_dbm.so
   /usr/lib64/httpd/modules/mod_authn_socache.so
   /usr/lib64/httpd/modules/mod_authz_dbd.so
   /usr/lib64/httpd/modules/mod_authz_dbm.so
   /usr/lib64/httpd/modules/mod_authz_owner.so
   /usr/lib64/httpd/modules/mod_buffer.so
   /usr/lib64/httpd/modules/mod_cache.so
   /usr/lib64/httpd/modules/mod_cache_disk.so
   /usr/lib64/httpd/modules/mod_cache_socache.so
   /usr/lib64/httpd/modules/mod_dbd.so
   /usr/lib64/httpd/modules/mod_dumpio.so
   /usr/lib64/httpd/modules/mod_file_cache.so
   /usr/lib64/httpd/modules/mod_include.so
   /usr/lib64/httpd/modules/mod_lbmethod_bybusyness.so
   /usr/lib64/httpd/modules/mod_lbmethod_byrequests.so
   /usr/lib64/httpd/modules/mod_lbmethod_bytraffic.so
   /usr/lib64/httpd/modules/mod_lbmethod_heartbeat.so
   /usr/lib64/httpd/modules/mod_log_debug.so
   /usr/lib64/httpd/modules/mod_logio.so
   /usr/lib64/httpd/modules/mod_macro.so
   /usr/lib64/httpd/modules/mod_proxy_ajp.so
   /usr/lib64/httpd/modules/mod_proxy_balancer.so
   /usr/lib64/httpd/modules/mod_proxy_connect.so
   /usr/lib64/httpd/modules/mod_proxy_express.so
   /usr/lib64/httpd/modules/mod_proxy_fdpass.so
   /usr/lib64/httpd/modules/mod_proxy_ftp.so
   /usr/lib64/httpd/modules/mod_proxy_hcheck.so
   /usr/lib64/httpd/modules/mod_proxy_scgi.so
   /usr/lib64/httpd/modules/mod_proxy_wstunnel.so
   /usr/lib64/httpd/modules/mod_request.so
   /usr/lib64/httpd/modules/mod_sed.so
   /usr/lib64/httpd/modules/mod_session.so
   /usr/lib64/httpd/modules/mod_session_cookie.so
   /usr/lib64/httpd/modules/mod_session_crypto.so
   /usr/lib64/httpd/modules/mod_session_dbd.so
   /usr/lib64/httpd/modules/mod_slotmem_shm.so
   /usr/lib64/httpd/modules/mod_socache_dbm.so
   /usr/lib64/httpd/modules/mod_socache_memcache.so
   /usr/lib64/httpd/modules/mod_speling.so
   /usr/lib64/httpd/modules/mod_userdir.so
   /usr/lib64/httpd/modules/mod_vhost_alias.so
   /usr/lib64/httpd/modules/mod_watchdog.so

Re: Post 2.4.25

[Reindl Harald]

Am 29.12.2016 um 07:08 schrieb William A Rowe Jr:

(Again, it's gmail, /shrug. I can attempt to undecorate but doubt I'm
moving to a local client/mail store again. If anyone has good gmail
formatting tips for their default settings, I'd love a pointer.)


yes, setup thunderbird and gmail with IMAP for mailing-lists so that 
your sent and received mail are as now on the server or setup roundcube 
to access gmail via IMAP/SMTP and configure it to prefer plaintext


or complain loud enough to google that they are fools when they convert 
a plaintext message to html while press reply

Re: [VOTE] Release Apache httpd 2.4.25 as GA

[Reindl Harald]

Am 16.12.2016 um 19:29 schrieb Jim Jagielski:

At long, long last, the pre-release test tarballs for Apache httpd
version 2.4.25 can be found at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.25 GA.

[x] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why


+1 on Fedora 24 x86_64 with PHP 7.0.14 / PHP 7.1.0

Re: PCRE 10 and puzzling edge cases

[Reindl Harald]

Am 12.12.2016 um 10:52 schrieb Petr Pisar:

I made sure I have installed all Perl modules I found relevant, but I was
unable to run the tests against SVN httpd sources. I played with
LD_LIBRARY_PATH, apxs etc. but without any good result. At the end
I reconfigured httpd sources and installed the binaries into a /tmp
subdirectory and that allowed me to run the tests. It's quite annoying to have
to install httpd into the system just only to test it


since your email is @redhat.com take a look at the Fedora php.spec and 
how the testsuite is called there from the rpm builddir *before* make 
install - same for mariadb/mysql - i guess httpd wouldn't bee that different

Re: how to build httpd with profile-guided-optimization?

[Reindl Harald]

since there are already higly optimized parts with "-O3 -fPIC 
-funswitch-loops -minline-all-stringops -fno-strict-aliasing -flto 
-ffat-lto-objects -fuse-ld=gold -fuse-linker-plugin" even if you biuld 
with -Os (which is a good combination when performance critical code is 
optimized while the rest not bloated) i guess that parts could be 
enhanced by the implicit "-funroll-loops"


as httpd typically has similar operations for every website it could be 
easier to profile than PHP where you really need to profile your 
application


PGO enables the options below and our PHP build with PGO is 0.8 MB 
smaller (the main binary while anything is built as loadable extension) 
than without while gives around 7-10% performance gain and the 
profiling-code running through a complete website in a loop should be 
re-usable for httpd too

__

-fprofile-use=
Enable profile feedback-directed optimizations, and the following 
optimizations which are generally profitable only with profile feedback 
available: -fbranch-probabilities, -fvpt, -funroll-loops, -fpeel-loops, 
-ftracer, -ftree-vectorize, and ftree-loop-distribute-patterns.


Before you can use this option, you must first generate profiling 
information. See Optimize Options, for information about the 
-fprofile-generate option.


Am 11.10.2016 um 13:32 schrieb Reindl Harald:

https://en.wikipedia.org/wiki/Profile-guided_optimization

for PHP it's easy because the makefiles support it directly

make %{?_smp_mflags} prof-gen
/usr/bin/bash /rpmbuild/PHP-PGO/profile.sh --php_build $PWD
make prof-clean
make %{?_smp_mflags} prof-use
_

i tried to replicate that for httpd but obviously CFLAGS after
./configure are completly ignored but you need "-fprofile-generate" for
the first make and "-fprofile-generate" after benchmark the application
for the second build which means that the stuff belows looks not
terrible wrong but don't work at all

export CFLAGS="$COMPILERFLAGS -fprofile-generate"
export CXXFLAGS="$COMPILERFLAGS -fprofile-generate"
CCACHE_DISABLE=1 make %{?_smp_mflags} PROF_FLAGS="-fprofile-generate all"
/usr/bin/bash /rpmbuild/PHP-PGO/profile.sh --httpd_build $PWD
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f
find . -name \*.so | xargs rm -f
rm -f httpd libs/*
export CFLAGS="$COMPILERFLAGS -fprofile-use"
export CXXFLAGS="$COMPILERFLAGS -fprofile-use"
CCACHE_DISABLE=1 make %{?_smp_mflags} PROF_FLAGS="-fprofile-use all"

how tu build httpd with profile-guided-optimization?

[Reindl Harald]

https://en.wikipedia.org/wiki/Profile-guided_optimization

for PHP it's easy because the makefiles support it directly

make %{?_smp_mflags} prof-gen
/usr/bin/bash /rpmbuild/PHP-PGO/profile.sh --php_build $PWD
make prof-clean
make %{?_smp_mflags} prof-use
_

i tried to replicate that for httpd but obviously CFLAGS after 
./configure are completly ignored but you need "-fprofile-generate" for 
the first make and "-fprofile-generate" after benchmark the application 
for the second build which means that the stuff belows looks not 
terrible wrong but don't work at all


export CFLAGS="$COMPILERFLAGS -fprofile-generate"
export CXXFLAGS="$COMPILERFLAGS -fprofile-generate"
CCACHE_DISABLE=1 make %{?_smp_mflags} PROF_FLAGS="-fprofile-generate all"
/usr/bin/bash /rpmbuild/PHP-PGO/profile.sh --httpd_build $PWD
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f
find . -name \*.so | xargs rm -f
rm -f httpd libs/*
export CFLAGS="$COMPILERFLAGS -fprofile-use"
export CXXFLAGS="$COMPILERFLAGS -fprofile-use"
CCACHE_DISABLE=1 make %{?_smp_mflags} PROF_FLAGS="-fprofile-use all"

Re: [PATCH] Introducing mod_brotli

[Reindl Harald]

Am 19.09.2016 um 19:56 schrieb Jacob Champion:

On 09/19/2016 10:12 AM, Eric Covener wrote:


I would prefer to keep them separate even if we have to teach something
to coordinate them (a module, some new support in mod_filter, some
kind of hook?)



+1. (If it proves difficult to make separate compression modules play
well together, that's a problem we should fix.)


agreed - however, below some configs where my brain rumours how have 
that identically behavior by just use "brotli" compression in case the 
cient supports it - maybe someone with deeper insights as my pure 
adiminstrator view has a idea by looking at it


the "no-gzip dont-vary" stuff is for long running scripts with 
output-flushing to give "realtime" feedback instead have it all buffered


one brainstorming: "AddOutputCompressionByType" provided by whatever 
module, proceed the Accept-Encoding of the client and deciding the 
compression algo


__

Logging to have the compression ratio in the access-logs

DeflateFilterNote   Ratio ratio_info
LogFormat   "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" 
\"%{User-Agent}i\" (%{ratio_info}n%%)" combined

ErrorLog"/Volumes/dune/www-servers/_logs/apache_error.log"
CustomLog 
"/Volumes/dune/www-servers/_logs/apache_access.log" combined

LogLevelnotice core:info
__

[root@testserver:~]$ cat /etc/httpd/conf/httpd-deflate.conf
DeflateCompressionLevel 2
DeflateBufferSize 32768


 AddOutputFilterByType DEFLATE text/html
 AddOutputFilterByType DEFLATE text/javascript
 AddOutputFilterByType DEFLATE text/css
 AddOutputFilterByType DEFLATE text/plain
 AddOutputFilterByType DEFLATE text/xml
 AddOutputFilterByType DEFLATE text/x-component
 AddOutputFilterByType DEFLATE application/xhtml+xml
 AddOutputFilterByType DEFLATE application/xml+rss
 AddOutputFilterByType DEFLATE application/rss+xml
 AddOutputFilterByType DEFLATE application/xml
 AddOutputFilterByType DEFLATE application/javascript
 AddOutputFilterByType DEFLATE application/x-javascript
 AddOutputFilterByType DEFLATE application/msword
 AddOutputFilterByType DEFLATE application/msexcel
 AddOutputFilterByType DEFLATE application/mspowerpoint
 AddOutputFilterByType DEFLATE application/msaccess
 AddOutputFilterByType DEFLATE application/mshelp
 AddOutputFilterByType DEFLATE application/pdf
 AddOutputFilterByType DEFLATE application/postscript
 AddOutputFilterByType DEFLATE audio/x-wav
 AddOutputFilterByType DEFLATE text/rtf
 AddOutputFilterByType DEFLATE text/comma-separated-values
 AddOutputFilterByType DEFLATE text/tab-separated-values
 AddOutputFilterByType DEFLATE text/vnd.wap.wml
 AddOutputFilterByType DEFLATE text/vnd.wap.wmlscript
 AddOutputFilterByType DEFLATE text/vnd.wap.wmlscript
 AddOutputFilterByType DEFLATE application/vnd.wap.wmlc
 AddOutputFilterByType DEFLATE text/x-setext
 AddOutputFilterByType DEFLATE text/x-sgml
 AddOutputFilterByType DEFLATE text/x-speech
 AddOutputFilterByType DEFLATE application/x-sh
 AddOutputFilterByType DEFLATE application/x-latex
 AddOutputFilterByType DEFLATE application/x-httpd-php-source
 AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
 AddOutputFilterByType DEFLATE font/ttf
 AddOutputFilterByType DEFLATE font/otf
 AddOutputFilterByType DEFLATE font/x-woff
 AddOutputFilterByType DEFLATE image/svg+xml
 AddOutputFilterByType DEFLATE 
application/vnd.ms-word.document.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.openxmlformats-officedocument.wordprocessingml.document
 AddOutputFilterByType DEFLATE 
application/vnd.ms-word.template.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.openxmlformats-officedocument.wordprocessingml.template
 AddOutputFilterByType DEFLATE 
application/vnd.ms-powerpoint.template.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.openxmlformats-officedocument.presentationml.template
 AddOutputFilterByType DEFLATE 
application/vnd.ms-powerpoint.addin.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.ms-powerpoint.slideshow.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.openxmlformats-officedocument.presentationml.slideshow
 AddOutputFilterByType DEFLATE 
application/vnd.ms-powerpoint.presentation.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.openxmlformats-officedocument.presentationml.presentation
 AddOutputFilterByType DEFLATE 
application/vnd.ms-excel.addin.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.ms-excel.sheet.binary.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.ms-excel.sheet.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
 AddOutputFilterByType DEFLATE 
application/vnd.ms-excel.template.macroEnabled.12
 AddOutputFilterByType DEFLATE 
application/vnd.openxmlformats-officedocument.spreadsheetml.template



SetEnvIfNoCase Request_URI (download.php)$ no-gzip 

Re: [PATCH] Introducing mod_brotli

[Reindl Harald]

Am 19.09.2016 um 16:14 schrieb Evgeny Kotkov:

Eric Covener  writes:


Wow! This is great stuff. Brotli support has been in my TODO
queue for awhile.

Thanks!


+1, cool stuff and thanks!


Glad to hear that, thanks everyone.

I would be happy to continue the work on this module, for instance, by
adding the necessary documentation and the ability to log compression ratio


just an idea - wouldn't it make sense to add 'br' support for 
mod_deflate and have it preferred when the client says in it's request 
headers that it supports the encoding instead having two modules for the 
same thing just using different comrepssion algos?


if not i am fine and grateful too - though about that again after 
considering how to include it and prefer mod_brotli over mod_defalte for 
clients whcih support it while mod_deflate is still needed for old 
clients only knowing about gzip/deflate

Re: [PATCH] Introducing mod_brotli

[Reindl Harald]

Am 16.09.2016 um 14:59 schrieb Stefan Eissing:

Sweet!


Am 16.09.2016 um 14:32 schrieb Evgeny Kotkov :

Hi all,

This patch adds a module for dynamic Brotli (RFC 7932) compression in httpd.

The new compression format is supported by Mozilla Firefox since 44.0 and
by Google Chrome since 50.0 [1, 2], and both nginx and IIS have modules that
offer Brotli compression.

With the new module, existing mod_deflate installations can benefit from
better compression ratio by sending Brotli-compressed data to the clients
that support it:

   LoadModule brotli_module modules/mod_brotli.so
   LoadModule deflate_module modules/mod_deflate.so
   SetOutputFilter BROTLI_COMPRESS;DEFLATE


sounds good - 20% better compression AFAIK

how is the ordering?
defined by SetOutputFilter or client?

looked at my firefox request headers and "br" is at the last position
Accept-Encoding: gzip, deflate, br
__

does it also support (%{ratio_info}n%%) in the log configuration?

LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" 
(%{ratio_info}n%%)" combined


leads to:

213.47.77.186 - - [16/Sep/2016:15:13:28 +0200] "GET / HTTP/1.1" 200 4133 
"" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36" (38%)


would especially when you compare clients with and without support nice 
to see the difference here

Re: [users@httpd] rpmbuild for httpd-2.4.23 failed missing mod_proxy_fdpass.so

[Reindl Harald]

Am 17.07.2016 um 12:49 schrieb William A Rowe Jr:

This is a dev@ level regression, sharing with that list. Please confirm
you are using httpd's own rpm. If not, the specific --enable-modules
provided for your rpm.spec file may be at issue.


confirmed also here with the latest release, i just commented it out 
since i don't use it


[builduser@buildserver:~]$ cat /rpmbuild/SPECS/httpd.spec | grep fdpass
# %package -nmod_proxy_fdpass
# Summary:   mod_proxy_fdpass for the Apache HTTP Server
# Provides:  mod_proxy_fdpass = %{version}-%{release}
# %description -nmod_proxy_fdpass
# %files -n mod_proxy_fdpass
# %{_libdir}/%{name}/modules/mod_proxy_fdpass.so

./configure \
 --disable-dependency-tracking \
 --prefix=%{_sysconfdir}/%{name} \
 --exec-prefix=%{_prefix} \
 --bindir=%{_bindir} \
 --sbindir=%{_sbindir} \
 --mandir=%{_mandir} \
 --libdir=%{_libdir} \
 --sysconfdir=%{_sysconfdir}/%{name}/conf \
 --includedir=%{_includedir}/%{name} \
 --libexecdir=%{_libdir}/%{name}/modules \
 --datadir=%{contentdir} \
 --enable-layout=Fedora \
 --enable-mpms-static=prefork \
 --with-mpm=prefork \
 --enable-mods-shared=all \
 --enable-mods-static="alias allowmethods auth_basic auth_digest 
authn_core authn_file authz_core authz_groupfile authz_host authz_user 
autoindex deflate dir env expires filter headers log_config mime 
ratelimit remoteip reqtimeout rewrite setenvif socache_shmcb unique_id 
unixd version" \

 --enable-nonportable-atomics \
 --enable-allocator-uses-mmap \
 --enable-proxy \
 --enable-cache \
 --enable-disk-cache \
 --enable-cgi \
 --enable-authn-anon \
 --enable-authn-alias \
 --enable-pie \
 --enable-ssl \
 --with-installbuilddir=%{_libdir}/%{name}/build \
 --with-apr=%{_prefix} \
 --with-apr-util=%{_prefix} \
 --with-pic \
 --with-pcre \
 --with-ssl \
 --disable-dtrace \
 --disable-ldap \
 --disable-lua \
 --disable-access-compat \
 --disable-charset-lite \
 --disable-distcache \
 --disable-imagemap \
 --disable-session \
 --disable-suexec \
 --disable-debug
 $*
%{__make} %{?_smp_mflags}


On Jul 17, 2016 3:45 AM, "kohmoto" > wrote:

I tried to rpmbuild the former version httpd-2.4.20.tar.bz2 in the
same machine. The result was successful without error. So, the
rpmbuild failure of httpd-2.4.23 missing mod_proxy_fdpass.so is not
due to my rebuild environment. All previous versions gave also
successful results.




signature.asc
Description: OpenPGP digital signature

Re: Apache Benchmark SNI SSL

[Reindl Harald]

Am 01.07.2016 um 15:23 schrieb Yann Ylavic:

On Fri, Jul 1, 2016 at 3:17 PM, Yann Ylavic <ylavic@gmail.com> wrote:

On Fri, Jul 1, 2016 at 3:02 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 01.07.2016 um 14:41 schrieb Yann Ylavic:


The -I does not take any argument, it tells ab to use iether the -H
"Host: ..." if any, or the host from the given URL otherwise


but why is there a param needed instead just send the SNI header from the
given URL like any browser does?


You may want to use an IP (or another DNS name) in the URL and still
reach the right (Virtual)Host on the server by specifying a -H "Host:
...".

The -H "Host:" existed already, and if it's used it has to be taken
for the SNI, that's how the server will elect the appropriate
VirtualHost if multiple ones listen on the same port.


Oh, I probably misunderstood your remark, you probably meant this
should be the defaut when TLS is available and used (per -f).

Good point, will look at it


exactly - it's all present what is needed to send the host-header and in 
case of TLS that's just the same which is needed for the SNI header 
without the need to tell "ab" it should use SNI by introducing a new param




signature.asc
Description: OpenPGP digital signature

Re: Apache Benchmark SNI SSL

[Reindl Harald]

Am 01.07.2016 um 14:41 schrieb Yann Ylavic:

On Fri, Jul 1, 2016 at 1:44 PM, Pietro Paolini  wrote:


On 1 July 2016 at 11:18, Pietro Paolini  wrote:


Is it correct ? It does not look good to me.

 -while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwix:y:z:C:H:P:A:g:X:de:SqB:m:"
+while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwixI:y:z:C:H:P:A:g:X:de:SqB:m:"

The x option has lost its argument, the new option you have introduced
uses an argument but the :

+fprintf(stderr, "-I Use TLS Server Name Indication (SNI)
extension\n");

Does not tell that.


Right, it was fixed in a follow up (http://svn.apache.org/r1750855).


That will do the job, as it stands right now it will be working if given a
-I option with a random argument, for example :

./support/ab -I randomstring  -c 1 -n 1 https://whatever/url

The I argument is actually not used.


The -I does not take any argument, it tells ab to use iether the -H
"Host: ..." if any, or the host from the given URL otherwise


but why is there a param needed instead just send the SNI header from 
the given URL like any browser does?






signature.asc
Description: OpenPGP digital signature

Re: Apache Benchmark SNI SSL

[Reindl Harald]

Am 30.06.2016 um 20:55 schrieb Yann Ylavic:

On Thu, Jun 30, 2016 at 7:21 PM, Pietro Paolini
 wrote:


I have built the httpd-2-.4.20 tarball but the problem is still there, has
it been fixed in newer version ? is there a workaround for that ?


SNI handling just added to ab in http://svn.apache.org/r1750854.
It will be part of some future release when accepted by the community,
meanwhile maybe you can patch your current release with the commit
above


oh *that* explains why it's impossible to "ab" a apache trafficserver 
target (running as reverse proxy) while it just *looked like* it works 
on httpd-sni vhosts while likely do the benchmark always on the default host




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.22 as GA

[Reindl Harald]

Am 20.06.2016 um 15:20 schrieb Jim Jagielski:

The pre-release test tarballs for Apache httpd 2.4.22 can be found
at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.22 GA.

[x] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why


+1

looks good on Fedora 23 x86_64



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.20 as GA

[Reindl Harald]

Am 04.04.2016 um 18:20 schrieb Jim Jagielski:

The pre-release test tarballs for Apache httpd 2.4.20 can be found
at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.20 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why


+1 Fedora 23 x86_64



signature.asc
Description: OpenPGP digital signature

Re: Status for 2.4.20

[Reindl Harald]

Am 29.03.2016 um 09:37 schrieb Noel Butler:

On 29/03/2016 01:06, William A Rowe Jr wrote:

@Everyone on this thread - keep it civil.
On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler > wrote:

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler
> wrote:

as stated previously, this shit will happen when certain
people push with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched
by any pending release, so lets get house in order  S T A
B L E , then worry about releases, jesus christ, we are
not ubuntu or redhat with set programs to release every 3
or 6 months regardless if shit is ready or not.


It sounds like you're making drama where there is none.

sounds like you only look at this from one perspective, and thats
not of the users, especially, the larger users.


Going by this, I've not seen some posts, Bills reply makes it appear I
said the above, which I didnt


you did

 Weitergeleitete Nachricht 
Betreff: Re: Status for 2.4.20
Datum: Wed, 23 Mar 2016 21:58:18 +1000
Von: Noel Butler 
Antwort an: dev@httpd.apache.org
An: dev@httpd.apache.org

as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any pending
release, so lets get house in order S T A B L E , then worry about
releases, jesus christ, we are not ubuntu or redhat with set programs to
release every 3 or 6 months regardless if shit is ready or not.


flame away... IDGAF

 Weitergeleitete Nachricht 
Betreff: Re: Status for 2.4.20
Datum: Sat, 26 Mar 2016 13:13:33 +1000
Von: Noel Butler 
Antwort an: dev@httpd.apache.org
An: dev@httpd.apache.org

On 25/03/2016 19:52, Graham Leggett wrote:
> It sounds like you're making drama where there is none.

sounds like you only look at this from one perspective, and thats not of 
the users, especially, the larger users.




signature.asc
Description: OpenPGP digital signature

Re: Status for 2.4.20

[Reindl Harald]

Am 26.03.2016 um 04:44 schrieb Noel Butler:

On 26/03/2016 13:32, Reindl Harald wrote:

Am 26.03.2016 um 04:13 schrieb Noel Butler:

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler <noel.but...@ausics.net> wrote:


as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any
pending release, so lets get house in order  S T A B L E , then worry
about releases, jesus christ, we are not ubuntu or redhat with set
programs to release every 3 or 6 months regardless if shit is ready
or not…..


It sounds like you’re making drama where there is none.


sounds like you only look at this from one perspective, and thats not of
the users, especially, the larger users.


if it has no relevant bugfixes for you - just don't upgrade - so what
why should others wait for probably relevant fixes longer just because
you are annoyed by an update nobody is forcing you to install?


*yawn*


grow up!

especially with your off-list hate-mails while block responses



signature.asc
Description: OpenPGP digital signature

Re: Status for 2.4.20

[Reindl Harald]

Am 26.03.2016 um 04:13 schrieb Noel Butler:

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:


as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any
pending release, so lets get house in order  S T A B L E , then worry
about releases, jesus christ, we are not ubuntu or redhat with set
programs to release every 3 or 6 months regardless if shit is ready
or not…..


It sounds like you’re making drama where there is none.


sounds like you only look at this from one perspective, and thats not of
the users, especially, the larger users.


if it has no relevant bugfixes for you - just don't upgrade - so what
why should others wait for probably relevant fixes longer just because 
you are annoyed by an update nobody is forcing you to install?





signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Reindl Harald]

Am 22.03.2016 um 20:59 schrieb William A Rowe Jr:

On Tue, Mar 22, 2016 at 2:58 PM, Reindl Harald <h.rei...@thelounge.net
<mailto:h.rei...@thelounge.net>> wrote:


Am 22.03.2016 um 20:55 schrieb William A Rowe Jr:

Can anyone get mod_lbmethod_rr.c to build?


my Fedora 23 rpm-spec builds without any issue or change - most
modules external sub-apckages and typically used ones static

I don't see where you enabled lbmethod_rr module?


not sure if my rpm is missing something we don't use

if something was not built then before 2.4.19 because i wrote the SPEC 
file based on the resulting binary modules - just all of them in own 
subpackages and what did not exist at that moment is not missing now


* Fr Jul 10 2015 Reindl Harald <h.rei...@thelounge.net>
- update to 2.4.16 (2.4.13, 2.4.14 and 2.4.15 was skipped upstream)
- split modules in own subpackages
- systemd: PrivateDevices=yes
- systemd: RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 
AF_IPX AF_NETLINK AF_PACKET AF_X25

- systemd: SystemCallArchitectures=x86-64



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Reindl Harald]

Am 22.03.2016 um 20:55 schrieb William A Rowe Jr:

Can anyone get mod_lbmethod_rr.c to build?


my Fedora 23 rpm-spec builds without any issue or change - most modules 
external sub-apckages and typically used ones static


[root@srv-rhsoft:~]$ /bin/ls -1 /fileserver/yum-repo/fc23/x86_64/ | grep 
mod_

mod_actions-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_asis-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_auth_form-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_anon-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_dbd-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_dbm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_socache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authz_dbd-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authz_dbm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authz_owner-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_buffer-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cache_disk-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cache_socache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cgi-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_data-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dav-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dav_fs-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dav_lock-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dbd-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dialup-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dumpio-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_echo-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_ext_filter-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_file_cache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_h264_streaming-2.2.7-21.fc23.20160322.rh.x86_64.rpm
mod_heartbeat-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_heartmonitor-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_http2-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_include-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_info-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_bybusyness-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_byrequests-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_bytraffic-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_heartbeat-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_log_debug-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_log_forensic-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_logio-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_macro-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_mime_magic-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_negotiation-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_ajp-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_balancer-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_connect-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_express-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_fcgi-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_fdpass-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_ftp-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_html-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_http-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_scgi-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_wstunnel-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_reflector-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_request-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_security-2.9.1-2.fc23.20160322.rh.x86_64.rpm
mod_sed-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_slotmem_plain-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_slotmem_shm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_socache_dbm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_socache_memcache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_speling-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_ssl-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_status-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_substitute-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_userdir-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_usertrack-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_vhost_alias-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_watchdog-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_xml2enc-2.4.19-1.fc23.20160322.rh.x86_64.rpm



I'm seeing 'name' : is not a member of 'proxy_balancer' errors,
as well as ap_proxy_retry_worker() undefined (converted into
an optional function, perhaps?)

On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski > wrote:

The pre-release test tarballs for Apache httpd 2.4.19 can be found
at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.

Vote will last the normal 72 hrs.

NOTE: The *-deps are only there for convenience.

Thx!




signature.asc
Description: OpenPGP digital signature

Re: access control for dynamic hosts

[Reindl Harald]

Am 29.02.2016 um 07:16 schrieb fab...@apache.org:

Maybe the reverse dns is working on your test address?


I checked it and yes it does work that way. I never knew it did.


Indeed.

This feature makes sense because it allows to allow a full domain, say
"apache.org", any host of which the inverse dns resolves to the domain
can then be allowed.

But this also means that if the reverse dns is not controlled, say with
the dynamic dns and a moving ip, ip control does not work, hence my
proposal for a lesser version which just checks that a client ip is
allowed just by resolving a name.


that is unsafe

it takes me exactly 5 seconds to add a PTR "myserver.apache.org" to one 
of our public ip-addresses if i would like to and nobody can do anything 
against it except check if the A record matchs because that can only be 
controlled by the domain owner


the same for anybody else who has a /24 or bigger network and the 
reverse dns delegated to his own namservers - i would not do such 
things, others would and so it's nothing to hand authentication on it





signature.asc
Description: OpenPGP digital signature

Re: httpd + systemd

[Reindl Harald]

Am 26.02.2016 um 17:11 schrieb Tim Bannister:

On 26 February 2016, Reindl Harald wrote:




in case of a SIGTERM the daemon is supposed to do a clean shutdown
anyways

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
Restart=always
RestartSec=1


Maybe add an ExecStop as well which calls graceful-stop? This is more reliable 
than a signal.

After DefaultTimeoutStopSec seconds, systemd will intervene regardless


it works not the way you likely think and may make things worser than a 
controlled SIGTERM


https://www.freedesktop.org/software/systemd/man/systemd.service.html

Note that it is usually not sufficient to specify a command for this 
setting that only asks the service to terminate (for example, by queuing 
some form of termination signal for it), but does not wait for it to do 
so. Since the remaining processes of the services are killed using 
SIGKILL immediately after the command exited, this would not result in a 
clean stop. The specified command should hence be a synchronous 
operation, not an asynchronous one.




signature.asc
Description: OpenPGP digital signature

Re: BufferedLogs and docs

[Reindl Harald]

Am 26.02.2016 um 15:01 schrieb Reindl Harald:

http://httpd.apache.org/docs/2.4/mod/mod_log_config.html#bufferedlogs
Context: server config

is that a documentation error or a error in the module that
"BufferedLogs Off" inside a vhost is accepted

the config below at least gives no error and it's unclear if it disables
the BufferedLogs from the global config entirely or is silently ignored


  
   BufferedLogs Off
   ...
  



looking with "tail -f" to a different bhost-specific logfile in fact it 
disables BufferedLogs globally instead  for only that vhost or raise a 
error witch "apachectl -t" that it is not allowed here


so it's a bug



signature.asc
Description: OpenPGP digital signature

BufferedLogs and docs

[Reindl Harald]

http://httpd.apache.org/docs/2.4/mod/mod_log_config.html#bufferedlogs
Context: server config

is that a documentation error or a error in the module that 
"BufferedLogs Off" inside a vhost is accepted


the config below at least gives no error and it's unclear if it disables 
the BufferedLogs from the global config entirely or is silently ignored



 
  BufferedLogs Off
  ...
 




signature.asc
Description: OpenPGP digital signature

Re: httpd + systemd

[Reindl Harald]

Am 26.02.2016 um 10:57 schrieb Graham Leggett:

Hi all,

I am trying to come up with a vanilla systemd unit file so that our RPM 
packaging contains a sensible startup on systemd environments, but I’m 
struggling.

With the unit file below the “systemctl restart httpd” command hangs. Usually 
the server starts fine, but then the server is stopped by something a short 
while afterwards for no clear reason. According to google the hang in systemctl 
happens for many people, systemctl is waiting for a message that never comes, 
but the causes are widely varied and I am struggling to figure out exactly what 
is wrong.

What I am trying to achieve is a simple daemon start, with no mod_systemd 
(which isn’t part of core httpd).

Can anyone point out any obvious errors in the following?


i would recommend the following which is in use here starting in 2012 on 
all servers, with the no-forking the mainpid for systemd is clear and by 
stop the service all processes get a SIGTERM from systemd


that works also with mpm-prefork perfectly (we use prefork)

while i understand the "give httpd some time to finish gracefully" in 
case of a hard restart it has the drawback that new connections are not 
accepted for that time-period and so it has negative impact


in case of a SIGTERM the daemon is supposed to do a clean shutdown anyways

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
Restart=always
RestartSec=1


[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)

[Service]
Type=forking
PIDFile=/var/run/httpd.pid
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
# We want systemd to give httpd some time to finish gracefully, but still want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to give
# httpd time to finish.
KillSignal=SIGCONT
PrivateTmp=true

[Install]
WantedBy=multi-user.target




signature.asc
Description: OpenPGP digital signature

Re: 256-bits cipher for HTTP/2 with Chrome

[Reindl Harald]

Am 15.01.2016 um 12:00 schrieb Jan Ehrhardt:

No question or issue, just a quick note.

On Apachelounge Mario Brandt (aka James Bond) once asked the question:
"Is there any chance to have a 256 cipher instead of
ECDHE-RSA-AES128-GCM-SHA256?"

It turns out, that there is a 256-bits cipher which will be used by Chrome
for HTTP/2 connections: ECDHE-RSA-CHACHA20-POLY1305

Further reading: https://www.apachelounge.com/viewtopic.php?p=32641#32641


given that AES is hardware accelerated (on client and server) these days 
and there is no compelling reason to prefer 256 bit because you would 
need a RSA-16000 (at least for AES256, not sure for CHACHA) while for 
AES128 RSA-3072 key.




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.18 as GA

[Reindl Harald]

Am 08.12.2015 um 21:38 schrieb Jim Jagielski:

The pre-release test tarballs for Apache httpd 2.4.18 can be found
at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.

Vote will last the normal 72 hrs


+1 Fedora 23 x86_64 with mod_security 2.9 and PHP 5.6.16
without HTTP2 part of the game the same most likely for Fedora 22



signature.asc
Description: OpenPGP digital signature

Re: Broken 2.4 ./configure

[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: 2.4.18?

[Reindl Harald]

Am 18.11.2015 um 08:11 schrieb Noel Butler:

On 17/11/2015 22:31, Graham Leggett wrote:

We’ve just released HTTP/2 support for the very first time. People
want to use it, people want to see problems in it fixed. I don’t see
the number of releases as excessive at all.


You obviously dont manage very many public facing servers then, I have
that advantage of looking at it from both sides, when I do testing - I
test based on what sys admins want


not in my name!

i manage enough public facing servers, maintain enough RPM packages at 
my own and have no problem put a new release tarball below 
rpmbuild/SOURFCES, edit the version in the SPEC file and build a package 
followed by standard tests and automated deployment


not for MariaDB, not for PHP, not for anything else and as long as i can 
deploy weekly kernel updates for 35 machines (and yes for some times 
they are weekly) i can cope with monthly httpd updates pretty fine




signature.asc
Description: OpenPGP digital signature

Re: 2.4.18?

[Reindl Harald]

Am 18.11.2015 um 08:16 schrieb Noel Butler:

On 17/11/2015 22:33, Reindl Harald wrote:


5 or 6 bloody weeks is a month - so what's the problem?
any other software but httpd is allowed to have monthly updates?

"I can accept" - seriously - you can just ignore a release when you
think it's not important for you but i don't get why anybody else
should wait for available non-security bugfixes just because you feel
like someone enforces you to update your server


your problem harry as usual is you dont comprehend whats said, because i
never once said it was OK for that other software, in fact its made
clear otherwise, but I'll grant you your comments based only on the fact
you have little comprehension of english and rely on translators.


no i don't rely on a translator, i just read you other posts too before 
reply and one part of that was "take phpmyadmin as one example, most 
admins I know gave up updating it, because there were updates every 
week, sometimes  every few days, Marc has accepted this is a serious 
problem and unless a critical security bug is found, normal bug fixes 
releases will be only once per month if need be"


and here we talk about that *one month* - so what's the problem?

anyways, if you can't cope with monthly updates and in doubt decide if 
they are relevant at all hire somebody who can cope or just install a 
LTS distribution only delivering critical bugfixes




signature.asc
Description: OpenPGP digital signature

Re: 2.4.18?

[Reindl Harald]

Am 17.11.2015 um 13:27 schrieb Noel Butler:

On 17/11/2015 18:02, Stefan Eissing wrote:

Am 17.11.2015 um 08:13 schrieb Noel Butler :


On 17/11/2015 03:05, Jim Jagielski wrote:
My plan is to T 2.4.18 sometime next week in hopes of a formal
release the beginning of Dec.


??? We only had 2.4.17  5 weeks ago, why the rush?


Uhm. When would be a better time for you to get fixes and functional
improvements?

//Stefan


when there is
1/ serious security issue that need to be addresses immediately, or,
2/ when there are enough stable new functions to warrant it - just like
every other project out there that has a stable product.

We need to loose this desire to release often mentality, I can accept
every 3 or 4 months which is how its generally been done in the past,
but 5 or 6 bloody weeks? thats a concern, for reasons I outlayed to
Graham, it says, " ohh its flawed release, and when it happens a few
times people think " oh FFS, must be more stable software than this" and
over time the userbase dwindles away


5 or 6 bloody weeks is a month - so what's the problem?
any other software but httpd is allowed to have monthly updates?

"I can accept" - seriously - you can just ignore a release when you 
think it's not important for you but i don't get why anybody else should 
wait for available non-security bugfixes just because you feel like 
someone enforces you to update your server




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Reindl Harald]

Am 11.10.2015 um 22:06 schrieb Rainer Jung:

Am 11.10.2015 um 21:14 schrieb Reindl Harald:



Am 11.10.2015 um 21:07 schrieb Yann Ylavic:

On Sun, Oct 11, 2015 at 8:59 PM, Reindl Harald
<h.rei...@thelounge.net> wrote:


Google only showed discussions, Bugzilla and so on and finding the new
directive is hard - maybe the hint should made it into the changelog
for GA
release


Yes you're right, I should have mentioned that directive in the
CHANGES entry.
Unfortunately I'm afraid it's too late now, the 2.4.17 tag is frozen.
Hopefully the (new) documentation will quickly be indexed...


no problem since it's diabled by default


"ab -c 100 -n 5 http://small-image.gif; did not make me that happy
after a short test on a quadcore machine, after some time httpd stopped
to respond for a tinay statical image with a few bytes

# SO_REUSEPORT support
# = 2.4.17>
#  ListenCoresBucketsRatio 4
# 


You might run into problems if your server accumulates to many TIME_WAIT
connections. Check their number in the "netstat -an" output.

ab without "-k" does in connection per request and if those are only
used very short and the server is fast you can end up with a couple of
10.000s of TIME_WAIT connections (independent of SO_REUSEPORT)


sorry for the last reply

no, it's only when "ListenCoresBucketsRatio 4" is used while otherwise a 
"ab -c 100 -n 500 http://small-image.gif; is no problem




signature.asc
Description: OpenPGP digital signature

Re: H2 compatible ciphers

[Reindl Harald]

Am 17.10.2015 um 11:18 schrieb Kaspar Brand:

Another - quite radical - approach would consist of using a whitelist,
which consists of a single cipher suite only: given that section 9.2 of
RFC 7540 states

"Implementations of HTTP/2 MUST use TLS version 1.2"

and section 9.2.2 further says

"deployments of HTTP/2 that use TLS 1.2 MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256
elliptic curve [FIPS186]"

then "H2Compliance on" would only have to make sure that this exact
suite is negotiated. (What this MTI cipher suite also means, IINM, is
that you can't run an RFC 7540 h2 compliant server with an ECDSA key
only, actually... not sure if that was really an intended effect of this
requirement.)


terrible idea because it would lead to disable new, safer and 
recommended ciphers in the future until somebody adds them to the whitelist


so users (clientside) would have to wait for openssl *and* apache after 
their browser has already support and with the current release cycles of 
all major browsers it's likely to end that way




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Reindl Harald]

Am 11.10.2015 um 21:07 schrieb Yann Ylavic:

On Sun, Oct 11, 2015 at 8:59 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


Google only showed discussions, Bugzilla and so on and finding the new
directive is hard - maybe the hint should made it into the changelog for GA
release


Yes you're right, I should have mentioned that directive in the CHANGES entry.
Unfortunately I'm afraid it's too late now, the 2.4.17 tag is frozen.
Hopefully the (new) documentation will quickly be indexed...


no problem since it's diabled by default


"ab -c 100 -n 5 http://small-image.gif; did not make me that happy 
after a short test on a quadcore machine, after some time httpd stopped 
to respond for a tinay statical image with a few bytes


# SO_REUSEPORT support
# = 2.4.17>
#  ListenCoresBucketsRatio 4
# 



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Reindl Harald]

Am 11.10.2015 um 20:51 schrieb Yann Ylavic:

On Sun, Oct 11, 2015 at 8:45 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


Am 09.10.2015 um 19:40 schrieb Jim Jagielski:


The pre-release test tarballs for Apache httpd 2.4.17 can be found
at the usual place:

 http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.17 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why



+1 on Fedora 21 / 22 x86_64

one question:
MPMs: Support SO_REUSEPORT to create multiple duplicated listener

does that get automatic enabled on recent Linux kernels or is there any
configuration needed to enable it?


You need to configure this directive:
http://httpd.apache.org/docs/2.4/mod/mpm_common.html#listencoresbucketsratio


thanks!

Google only showed discussions, Bugzilla and so on and finding the new 
directive is hard - maybe the hint should made it into the changelog for 
GA release



will give it a try

however, 2.4.17 without touch configs looks fine



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Reindl Harald]

Am 11.10.2015 um 21:25 schrieb Yann Ylavic:

On Sun, Oct 11, 2015 at 9:14 PM, Reindl Harald <h.rei...@thelounge.net> wrote:


"ab -c 100 -n 5 http://small-image.gif; did not make me that happy after
a short test on a quadcore machine, after some time httpd stopped to respond
for a tinay statical image with a few bytes


Hm, with 4 cores and a ratio of 4, there is only one bucket per
listener, which is the same as the default.
Did you try the same test without the directive or with a ratio of 0?
(I rather suspect a connectivity issue with ab)


i did not test it much and honestly i am not able to make a decision 
based on 
http://httpd.apache.org/docs/2.4/mod/mpm_common.html#listencoresbucketsratio 



without the directive all is unchanged and stable

0 is not accepted which i would consider a bug given
the docs days default  "ListenCoresBucketsRatio 0 (disabled)"
AH00526: Syntax error on line 48 of /etc/httpd/conf/httpd-core.conf:
ListenCoresBucketsRatio must be > 0

= 2.4.17>
 ListenCoresBucketsRatio 0

__

i just wanted to test the new feature on a 4.2.3 kernel

"ab" don't scale well but likely not a connectivity issue runnig it on 
the same machine like httpd




signature.asc
Description: OpenPGP digital signature

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 03.10.2015 um 11:16 schrieb Kaspar Brand:

On 01.10.2015 16:32, Reindl Harald wrote:

Am 01.10.2015 um 16:29 schrieb Plüm, Rüdiger, Vodafone Group:

The question is: What happens on Firefox side. Of course it still tries to get 
to the OCSP server, but it should not cause an error on Firefox side if this 
does not work.


no, it does not because "security.OCSP.enabled = 0" and i saw at least
two requests to different servers failing with my Firefox with the
responder error from the webserver


What do you have security.OCSP.require set to? If it's "true" (a setting
no longer configurable through the UI, BTW, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1034360), then Firefox
shows a fairly peculiar behavior: even when OCSP checking is disabled
(by setting security.OCSP.enabled to "0", through the "Query OCSP
responder servers to confirm the current validity of certificates"
preference in the UI under Advanced -> Certificates), it still includes
a status_request extension in the TLS handshake, and will subsequently
fail when it receives a stapled tryLater OCSP response, as long as
security.OCSP.require=true


security.OCSP.require=false is the default
but it's not only my client with random failed connections

[Sat Oct 03 00:15:01.478741 2015] [ssl:error] [pid 27458] 
(104)Connection reset by peer: [client 81.223.20.5:59844] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 00:45:01.618792 2015] [ssl:error] [pid 4965] (104)Connection 
reset by peer: [client 81.223.20.5:33566] AH01977: failed reading line 
from OCSP server
[Sat Oct 03 01:15:01.589643 2015] [ssl:error] [pid 5599] (104)Connection 
reset by peer: [client 81.223.20.5:36218] AH01977: failed reading line 
from OCSP server
[Sat Oct 03 01:45:01.816132 2015] [ssl:error] [pid 4965] (104)Connection 
reset by peer: [client 81.223.20.5:38762] AH01977: failed reading line 
from OCSP server
[Sat Oct 03 02:15:01.187187 2015] [ssl:error] [pid 14361] 
(104)Connection reset by peer: [client 81.223.20.5:41043] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 02:45:01.292205 2015] [ssl:error] [pid 14366] 
(104)Connection reset by peer: [client 81.223.20.5:42999] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 03:15:01.353077 2015] [ssl:error] [pid 14364] 
(104)Connection reset by peer: [client 81.223.20.5:45180] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 03:45:01.428090 2015] [ssl:error] [pid 14364] 
(104)Connection reset by peer: [client 81.223.20.5:46857] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 04:15:02.019261 2015] [ssl:error] [pid 26399] 
(104)Connection reset by peer: [client 81.223.20.5:49007] AH01977: 
failed reading line from OCSP server




signature.asc
Description: OpenPGP digital signature

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 01.10.2015 um 15:08 schrieb Reindl Harald:

Am 01.10.2015 um 14:53 schrieb Plüm, Rüdiger, Vodafone Group:

not really, i had the error message just now again in FF, the difference
was that now a "try again" loaded the page but with
"SSLStaplingReturnResponderErrors" i would expect it invisible to
clients in general - GoDaddy seems to have massive problems with their
responders the last days and the defaults with stapling enabled make
them to a perfect DOS target

[Thu Oct 01 13:33:01.179365 2015] [ssl:error] [pid 19312] [client
10.0.0.99:37860] AH01980: bad response from OCSP server: (none)
[Thu Oct 01 13:33:01.179393 2015] [ssl:error] [pid 19312] AH01941:
stapling_renew_response: responder error

SSLStaplingCache shmcb:/var/cache/mod_ssl/ocsp_cache(1048576)
SSLStaplingStandardCacheTimeout 86400
SSLStaplingErrorCacheTimeout 300
SSLStaplingReturnResponderErrors Off


What happens if you set

SSLStaplingFakeTryLater off

in addition?


i added that now and will have a look over the serverlogs, it's not
happening all the time but very often and so if the logs are clear
within 24 hours the problem is likely solved


looks not that good - "Connection reset by peer" indicates a failed 
client request, the other lines could be just internal


[Thu Oct 01 15:15:01.495986 2015] [ssl:error] [pid 17468] 
(104)Connection reset by peer: [client 81.223.20.5:55156] AH01977: 
failed reading line from OCSP server
[Thu Oct 01 15:15:01.496037 2015] [ssl:error] [pid 17468] [client 
81.223.20.5:55156] AH01980: bad response from OCSP server: (none)
[Thu Oct 01 15:15:01.496057 2015] [ssl:error] [pid 17468] AH01941: 
stapling_renew_response: responder error




signature.asc
Description: OpenPGP digital signature

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 01.10.2015 um 14:53 schrieb Plüm, Rüdiger, Vodafone Group:

-Ursprüngliche Nachricht-
Von: Reindl Harald [mailto:h.rei...@thelounge.net]

The default for SSLStaplingReturnResponderErrors is relatively odd.
Not sure why it has always defaulted to "on" (r829619), but setting it
to off should save you further troubles with Firefox clients.


not really, i had the error message just now again in FF, the difference
was that now a "try again" loaded the page but with
"SSLStaplingReturnResponderErrors" i would expect it invisible to
clients in general - GoDaddy seems to have massive problems with their
responders the last days and the defaults with stapling enabled make
them to a perfect DOS target

[Thu Oct 01 13:33:01.179365 2015] [ssl:error] [pid 19312] [client
10.0.0.99:37860] AH01980: bad response from OCSP server: (none)
[Thu Oct 01 13:33:01.179393 2015] [ssl:error] [pid 19312] AH01941:
stapling_renew_response: responder error

SSLStaplingCache shmcb:/var/cache/mod_ssl/ocsp_cache(1048576)
SSLStaplingStandardCacheTimeout 86400
SSLStaplingErrorCacheTimeout 300
SSLStaplingReturnResponderErrors Off


What happens if you set

SSLStaplingFakeTryLater off

in addition?


i added that now and will have a look over the serverlogs, it's not 
happening all the time but very often and so if the logs are clear 
within 24 hours the problem is likely solved


thanks!



signature.asc
Description: OpenPGP digital signature

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 30.09.2015 um 08:42 schrieb Kaspar Brand:

On 29.09.2015 18:24, Reindl Harald wrote:

i just restarted the servers and disabled stapling since all our
servcies where unreachable (before i write the second mail 5 different
hosts with several sites where affected)

in fact the error caching does more harm than benefits - IHMO a better
"could not reach OCSP server or received a error from it" caching would
be just temporary disable stapling for 10 minutes instead lead in
connections fail even from clients which have disabled OCSP completly


firefox refused to open our adminpanel with the error below until i
restarted httpd


The default for SSLStaplingReturnResponderErrors is relatively odd.
Not sure why it has always defaulted to "on" (r829619), but setting it
to off should save you further troubles with Firefox clients.


not really, i had the error message just now again in FF, the difference 
was that now a "try again" loaded the page but with 
"SSLStaplingReturnResponderErrors" i would expect it invisible to 
clients in general - GoDaddy seems to have massive problems with their 
responders the last days and the defaults with stapling enabled make 
them to a perfect DOS target


[Thu Oct 01 13:33:01.179365 2015] [ssl:error] [pid 19312] [client 
10.0.0.99:37860] AH01980: bad response from OCSP server: (none)
[Thu Oct 01 13:33:01.179393 2015] [ssl:error] [pid 19312] AH01941: 
stapling_renew_response: responder error


SSLStaplingCache shmcb:/var/cache/mod_ssl/ocsp_cache(1048576)
SSLStaplingStandardCacheTimeout 86400
SSLStaplingErrorCacheTimeout 300
SSLStaplingReturnResponderErrors Off



signature.asc
Description: OpenPGP digital signature

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 01.10.2015 um 16:29 schrieb Plüm, Rüdiger, Vodafone Group:




-Ursprüngliche Nachricht-
Von: Reindl Harald [mailto:h.rei...@thelounge.net]
Gesendet: Donnerstag, 1. Oktober 2015 15:18
An: dev@httpd.apache.org
Betreff: Re: SSLUseStapling: ssl handshake fails until httpd restart



Am 01.10.2015 um 15:08 schrieb Reindl Harald:

Am 01.10.2015 um 14:53 schrieb Plüm, Rüdiger, Vodafone Group:

not really, i had the error message just now again in FF, the

difference

was that now a "try again" loaded the page but with
"SSLStaplingReturnResponderErrors" i would expect it invisible to
clients in general - GoDaddy seems to have massive problems with

their

responders the last days and the defaults with stapling enabled make
them to a perfect DOS target

[Thu Oct 01 13:33:01.179365 2015] [ssl:error] [pid 19312] [client
10.0.0.99:37860] AH01980: bad response from OCSP server: (none)
[Thu Oct 01 13:33:01.179393 2015] [ssl:error] [pid 19312] AH01941:
stapling_renew_response: responder error

SSLStaplingCache shmcb:/var/cache/mod_ssl/ocsp_cache(1048576)
SSLStaplingStandardCacheTimeout 86400
SSLStaplingErrorCacheTimeout 300
SSLStaplingReturnResponderErrors Off


What happens if you set

SSLStaplingFakeTryLater off

in addition?


i added that now and will have a look over the serverlogs, it's not
happening all the time but very often and so if the logs are clear
within 24 hours the problem is likely solved


looks not that good - "Connection reset by peer" indicates a failed
client request, the other lines could be just internal

[Thu Oct 01 15:15:01.495986 2015] [ssl:error] [pid 17468]
(104)Connection reset by peer: [client 81.223.20.5:55156] AH01977:
failed reading line from OCSP server
[Thu Oct 01 15:15:01.496037 2015] [ssl:error] [pid 17468] [client
81.223.20.5:55156] AH01980: bad response from OCSP server: (none)
[Thu Oct 01 15:15:01.496057 2015] [ssl:error] [pid 17468] AH01941:
stapling_renew_response: responder error


The question is: What happens on Firefox side. Of course it still tries to get 
to the OCSP server, but it should not cause an error on Firefox side if this 
does not work.


no, it does not because "security.OCSP.enabled = 0" and i saw at least 
two requests to different servers failing with my Firefox with the 
responder error from the webserver




signature.asc
Description: OpenPGP digital signature

SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

is that by intention?

firefox refused to open our adminpanel with the error below until i 
restarted httpd - i suggest the server should retry SSLUseStapling when 
a new client connects and it has failed for whatever reason


SSLUseStapling On

An error occurred during a connection to ***:8443. The OCSP server 
suggests trying again later. (Error code: sec_error_ocsp_try_server_later)






signature.asc
Description: OpenPGP digital signature

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 29.09.2015 um 10:20 schrieb Reindl Harald:

is that by intention?

firefox refused to open our adminpanel with the error below until i
restarted httpd - i suggest the server should retry SSLUseStapling when
a new client connects and it has failed for whatever reason

SSLUseStapling On

An error occurred during a connection to ***:8443. The OCSP server
suggests trying again later. (Error code: sec_error_ocsp_try_server_later)


as long httpd behaves that way i suggest to re-consider if it's a good 
idea to use "SSLUseStapling On" as future default - i just disabled it 
everywhere because *any* of our https-sites using the same GoDaddy 
wildcard certificate where broken repeatly today with the same error 
message and after a "apachectl graceful" started to work again




signature.asc
Description: OpenPGP digital signature