Re: Time for 2.4.28 ?

[Yann Ylavic]

On Mon, Sep 18, 2017 at 6:24 PM, Jim Jagielski  wrote:
> Seems like a good time to push for a 2.4.28 T by end-of-week.
> Review STATUS! Test and Vote on backports!
>
> Comments?

+1

Re: Listen 443 https

[Daniel]

I have to admit my point of view focuses on more generic cases rather
than extreme cases like the one you describe with "hundreds of
virtualhosts".



2017-09-18 20:03 GMT+02:00 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
>

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 :


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

[Stefan Eissing]

Thanks for you feedback, Daniel. Very much appreciated! You describe
the approach I suggest as "confusing" and "complicated", while for me
it is the opposite. ;-)

But there are really two separate things here. The SSLEngine addition
and the multi-port vhost. I'll argue that the first make sense, even if
you do not want to use the second one.

SSLEngine addr-list
-
The case I would like to make for "SSLEngine addr-list" is that it allows an
admin to define use of TLS on a port (for all or a specific address) in
one line. It is my understanding that all VirtualHosts on the same port
either need to do TLS or none should.

If a server has 100 vhosts on *:443, the admin needs to "SSLEngine on"
in each and every one of them. The task to do that is certainly manageable
for an admin, but why does it have to be that way? Why give the admin
the option to screw up and forget the 99th and see the error only when
someone accesses that host? With an implicit port match on SSLEngine,
 a VirtualHost without certifcates fails the config immediately.

So, I'd argue that for a very common case, "SSLEngine *:443" makes
the configuration easier and offers better fail-safes.

This all holds true if one "folds" virtualhosts on a address/port list
or keeps separate ones for each address, as you think is superior.


VirtualHost addr-list
--
This is a feature that is already there. The new "SSLEngine addr" makes
it usable for http: and https: access. That is new. I think for someone
migrating a site to https:, it is a good approach, but YMMV.

In https://github.com/icing/mod_md/wiki/Migration I describe how
one ca go from a *:80 vhost, add Let's Encrypt certs, serve 80
and 443 both until everything is working as planned and then switch over
with permanent redirects and HSTS to the https: presence.

I recommend to duplicate VirtualHost initially, so that the *:80 can
be left unchanged during migration. But propose - with the help of
the trunk changes, if we decide to backport them - to end up with
a configuration *very* similar to the start one. To be exact, the
config has 5 lines added and 1 edited to add *:443. Migrating a 2nd
vhost on that server would add only 1 new line and 1 edit.

So, from *that* perspective I hope the admin of such a site sees it
as not confusing and not complicate to migrate to https:.

We need to keep in mind that browser will distrust http: *very* soon
and that admins will look for an easy way to offer https:. I hope that
the proposed way is attractive and will help. But it certainly is not
the only way. And there are certainly configurations where it is not
even a good way.

Cheers,

Stefan

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?

Is it really neccessary to have  and try to
do the same thing as above in a new more confusing complicated way?

Of course users may not be admins, but still they can have virtualhost
for both ports (SSL and not SSL) and use .htaccess and all the
RewriteCond %{HTTPS} !on  etc..

But the way I see it.. Are we really going to complicate virtualhosts
too? Do we really need to offer added functionality to do the same
thing that is already being offered now in the simple starting example
I provided of two single virtualhosts, one for each? Obviously one can
complicate it already as needed using If, or RewriteCond, etc.. but
shouldn't we strive to make virtualhosts as simple to understand as
possible?


To me a single virtualhost which handles both SSL and non-SSL
connection seems like doing the opposite, adding a new way for user
confusion.

Perhaps we need to stop for a minute if we wand to add more
complicated ways to do the same thing we can already do (and probably
many should do) in a very simple way?

Regarding the SSL changes, SSLPolicy and such are great additions and
they belong in server config, we should stop there for the moment and
leave Virtualhost as simple as possible.

Hope I don't sound impolite or anything like that, the ideas thrown
and your work (@Stefan) is amazing!

2017-08-10 15:28 GMT+02:00 Stefan Eissing 

Re: Listen 443 https

[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.


2017-09-18 19:18 GMT+02:00 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"
> 



-- 
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

Re: svn commit: r1808746 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_rewrite.c server/util_expr_eval.c

[Yann Ylavic]

Hi Luca,

On Mon, Sep 18, 2017 at 7:08 PM,   wrote:
>
> Modified: httpd/httpd/trunk/modules/mappers/mod_rewrite.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_rewrite.c?rev=1808746=1808745=1808746=diff
> ==
> --- httpd/httpd/trunk/modules/mappers/mod_rewrite.c (original)
> +++ httpd/httpd/trunk/modules/mappers/mod_rewrite.c Mon Sep 18 17:08:54 2017
> @@ -2035,7 +2035,10 @@ static char *lookup_variable(char *var,
>
>  case 'S':
>  if (!strcmp(var, "HTTP_HOST")) {
> -result = lookup_header("Host", ctx);
> +/* Skip the 'Vary: Host' header combination
> + * as indicated in rfc7231 section-7.1.4
> + */
> +result = apr_table_get(ctx->r->headers_in, "Host");

Why not address this in lookup_header directly?
Looks like there several call sites...

Most seem to use a fixed name (other than "Host"), but the one around
line 1879 is:

if (!strncasecmp(var, "HTTP", 4)) {
result = lookup_header(var+5, ctx);
}

so possibly also a candidate.

This might be enough though, to avoid spurious cycles spent in lookup_header().


Regards,
Yann.

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: Time for 2.4.28 ?

[Daniel Gruno]

On 09/18/2017 06:24 PM, Jim Jagielski wrote:
> Seems like a good time to push for a 2.4.28 T by end-of-week.
> Review STATUS! Test and Vote on backports!
> 
> Comments?
> 
+1!

Time for 2.4.28 ?

[Jim Jagielski]

Seems like a good time to push for a 2.4.28 T by end-of-week.
Review STATUS! Test and Vote on backports!

Comments?

Re: Listen 443 https

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

Is it really neccessary to have  and try to
do the same thing as above in a new more confusing complicated way?

Of course users may not be admins, but still they can have virtualhost
for both ports (SSL and not SSL) and use .htaccess and all the
RewriteCond %{HTTPS} !on  etc..

But the way I see it.. Are we really going to complicate virtualhosts
too? Do we really need to offer added functionality to do the same
thing that is already being offered now in the simple starting example
I provided of two single virtualhosts, one for each? Obviously one can
complicate it already as needed using If, or RewriteCond, etc.. but
shouldn't we strive to make virtualhosts as simple to understand as
possible?


To me a single virtualhost which handles both SSL and non-SSL
connection seems like doing the opposite, adding a new way for user
confusion.

Perhaps we need to stop for a minute if we wand to add more
complicated ways to do the same thing we can already do (and probably
many should do) in a very simple way?

Regarding the SSL changes, SSLPolicy and such are great additions and
they belong in server config, we should stop there for the moment and
leave Virtualhost as simple as possible.

Hope I don't sound impolite or anything like that, the ideas thrown
and your work (@Stefan) is amazing!

2017-08-10 15:28 GMT+02:00 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?
>
> -Stefan



-- 
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

Re: Interest in a uwsgi mod_proxy module?

[Jim Jagielski]

They have relicensed the module to ALv2! I am requesting
explicit OK from them for us to snag the module :)


https://github.com/unbit/uwsgi/issues/1636

mime type woff woff2

[Steffen]

In conf mime.types we have:

application/font-woff woff

And missing woff2 (have several request to add)

According to IANA 
https://www.iana.org/assignments/media-types/media-types.xhtml#application 
:


font-woff - DEPRECATED in favor of font/woff  application/font-woff


According 
https://www.iana.org/assignments/media-types/media-types.xml#font


woff font/wof
woff2 font/woff2

Do we change/add in mime.types : ?

change application/font-woffwoff   to  font/woff  woff


and add  font/wof2  woff2  ?


Or do we need both : ?


application/font-woffwoff
application/font-woff2woff2
font/woff  woff
font/woff2  woff2

implement multiple AuthType's

[Stefan Priebe - Profihost AG]

Hello,

would it be possible to implement multiple AuthType's? I know that this
is not possible in all cases but it would be great to be able have a
fallback.

For example:
Having GSSAPI Auth in the first place and if the browser does not send a
valid ticket fallback to other auth systems like ldap.

Greets,
Stefan