Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c

[Greg Stein]

On Thu, Aug 10, 2017 at 8:58 AM,  wrote:

> Author: icing
> Date: Thu Aug 10 13:58:26 2017
> New Revision: 1804671
>
> URL: http://svn.apache.org/viewvc?rev=1804671=rev
> Log:
> fix for 
>...

> +++ httpd/httpd/trunk/modules/md/mod_md_config.c Thu Aug 10 13:58:26 2017
>
>...

> @@ -215,7 +218,7 @@ static const char *md_config_sec_add_mem
>  const char *err;
>  int i;
>
> -if (NULL != (err = md_section_check(cmd))) {
> +if (NULL != (err = md_section_check(cmd, "

Seems you should be using a symbolic constant for the dozen occurrences of
this string, in order to avoid typos.

>...

Cheers,
-g

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
> wrote:
 >
 > 
 >  ServerName corecms.example.com 
 >  DocumentRoot "/www/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

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald 
wrote:
>
> 
>  ServerName corecms.example.com
>  DocumentRoot "/www/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.

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald  wrote:
>
> 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"
>  
> 

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.

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:19 AM, Stefan Eissing
 wrote:
>
>> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr :
>>
>>> Would we expect breakage by such a change?
>>
>> I think that Listen *:NNN is maybe the most common misconfiguration
>> in general, on multihomed boxes (and Listen myhost:NNN not answering
>> the call of localhost being a most common point of confusion :)
>>
>> Your mention of ServerName is a little misleading. A corresponding
>> virtual host isn't needed at all. And mod_ssl handshake is always
>> controlled by the physical vhost (first matching named vhost, name
>> being ignored), which makes this a little more confusing to users.
>
> If understand you correctly, if the first matching (document order?)
> vhost for the address:port (with wildcards) has "SSLEngine on", we
> get mod_ssl engaged. If not, we try to parse a http: request?
>
> Hmmm. That...could be improved.

When the NamedVirtualHost still existed and was still documented,
this was all more obvious to the end-user

This is where it is all explained poorly as features such as '*' were
further modified, so the document is pretty muddy and partly wrong;

http://httpd.apache.org/docs/2.4/vhosts/name-based.html

The author here clearly misunderstood the role of virtual hosts for
directives which affect the initial establishment of the connection
in the read request behavior, prior to re-electing a more specific
name-based vhost match. This sentence in particular could be
corrected; "In first establishing the connection and reading the
request off the wire, and subsequently, If no matching ServerName
or ServerAlias is found in the set of virtual hosts containing the
most specific matching IP address and port combination, then
the first listed virtual host that matches that will be used."

That's more correct but still clumsy, better wordsmithing would
be appreciated. It's answered much better in
http://httpd.apache.org/docs/2.4/mod/core.html#virtualhost

"When a request is received, the server first maps it to the best
matching  based on the local IP address and port
combination only. Non-wildcards have a higher precedence. If no match
based on IP and port occurs at all, the "main" server configuration is
used."

"If multiple virtual hosts contain the best matching IP address and
port, the server selects from these virtual hosts the best match based
on the requested hostname. If no matching name-based virtual host is
found, then the first listed virtual host that matched the IP address
will be used. As a consequence, the first listed virtual host for a
given IP address and port combination is the default virtual host for
that IP and port combination."

But even here we could be more specific in the second para;
"Once the request is received"...

Back to the behavior of mod_ssl, the SSLProtocol directive is
obviously dictated by the physical vhost. But SSLHonorCipherOrder
and other post-SNI decisions? I'm unsure whether the handshake
is "completed" with the SNI name-based election or physical vhost.


>> What leads me to wonder, even with some easier-to-read Listen
>> directives, if the user wouldn't be confused by omission of the
>> SSLEngine on, when their other SSL directives aren't behaving
>> as expected. Because they placed them in the wrong ,
>> obviously. But not obvious to them. The need to toggle SSLEngine
>> may be an unintended usability feature.
>
> I think my gut feeling tells me that "SSLEngine on|off" is more
> part of the port and of the vhost. The vhost may add other SSL*
> configurations, once SNI has identified the correct one. But for
> a certain port (address:port) we either do TLS or not.
>
> So, I was looking for ways to express that and Listen seems a good start.

The protocol tag existed for only one reason, to imply a corresponding
AcceptFilter (e.g. data or no data or http ready on the wire before the
accept would recognize the connection.)

Each time we overload this meaning we are introducing an alternate
or alias to other httpd configuration, which might become confusing
to many users. I just suggest we tread carefully and this time, think
the potential confusion and side effects through.

The other issue IMO is multiple protocols on the given listener.
Already true of http / h2c / h2. A recent proposal suggested to add
PROXY protocol to that list, and the list of potential combinations
goes on.

Re: v1.10.10: fixing stream response getting stuck when writing >32k on a...

[Stefan Eissing]

> Am 10.08.2017 um 16:18 schrieb William A Rowe Jr :
> 
> On Thu, Aug 10, 2017 at 4:37 AM, Stefan Eissing
>  wrote:
>> 
>>> Am 09.08.2017 um 20:32 schrieb Jacob Perkins :
>>> 
>>> Hi Stefan,
>>> 
>>> A patch for 2.4.27 would be great.
>>> 
>>> Your assistance is greatly appreciated.
>> 
>> Gladly. Patch available at: 
>> https://github.com/icing/mod_h2/blob/master/patches/mod_h2-v1.10.10-apache-2.4.x.diff
> 
> This seems pretty significant for a now GA module? Two thoughts...
> 
> Duplicate the patch (against httpd dist) into
> www.a.o/dist/httpd/patches/apply_to_2.4.27/ ?

Where is that exactly and what do I need to do?

> Step up plans to T 2.4.28 to supersede the problematic code?

+1

Several things have been added in STATUS for backport.

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: Listen 443 https

[Stefan Eissing]

> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr :
> 
> Let's break it down and consider the implications of Listen...
> 
> On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
>  wrote:
>> 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?
> 
> Firstly, we have well understood protocols definitions, so there
> are several shorthand flavors that could be introduced;
> 
>  Listen https
> 
> has a very plain and obvious meaning. Thus, so would these;
> 
>  Listen https://192.168.1.1
>  Listen https://xxx.yyy
>  Listen https://192.168.1.1:8443
>  Listen https://xxx.yyy:8443

I like this.

>> Would we expect breakage by such a change?
> 
> I think that Listen *:NNN is maybe the most common misconfiguration
> in general, on multihomed boxes (and Listen myhost:NNN not answering
> the call of localhost being a most common point of confusion :)
> 
> Your mention of ServerName is a little misleading. A corresponding
> virtual host isn't needed at all. And mod_ssl handshake is always
> controlled by the physical vhost (first matching named vhost, name
> being ignored), which makes this a little more confusing to users.

If understand you correctly, if the first matching (document order?)
vhost for the address:port (with wildcards) has "SSLEngine on", we
get mod_ssl engaged. If not, we try to parse a http: request?

Hmmm. That...could be improved.

> What leads me to wonder, even with some easier-to-read Listen
> directives, if the user wouldn't be confused by omission of the
> SSLEngine on, when their other SSL directives aren't behaving
> as expected. Because they placed them in the wrong ,
> obviously. But not obvious to them. The need to toggle SSLEngine
> may be an unintended usability feature.

I think my gut feeling tells me that "SSLEngine on|off" is more
part of the port and of the vhost. The vhost may add other SSL*
configurations, once SNI has identified the correct one. But for
a certain port (address:port) we either do TLS or not.

So, I was looking for ways to express that and Listen seems a good start.

>> 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?
> 
> Definitely not a fan. Why isn't this rewrite simply given in the system
> global config?
> 
> A connection, later the request, maps to only VirtualHost declaration.
> That block would never fire if there is a matching VirtualHost. OTOH,
> if no VirtualHost matches, then we use the global host anyways.

I now tend to agree that it probably only adds to confusion rather than simpify 
things. 

-Stefan

Re: v1.10.10: fixing stream response getting stuck when writing >32k on a...

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 4:37 AM, Stefan Eissing
 wrote:
>
>> Am 09.08.2017 um 20:32 schrieb Jacob Perkins :
>>
>> Hi Stefan,
>>
>> A patch for 2.4.27 would be great.
>>
>> Your assistance is greatly appreciated.
>
> Gladly. Patch available at: 
> https://github.com/icing/mod_h2/blob/master/patches/mod_h2-v1.10.10-apache-2.4.x.diff

This seems pretty significant for a now GA module? Two thoughts...

Duplicate the patch (against httpd dist) into
www.a.o/dist/httpd/patches/apply_to_2.4.27/ ?

Step up plans to T 2.4.28 to supersede the problematic code?

Re: Listen 443 https

[William A Rowe Jr]

Let's break it down and consider the implications of Listen...

On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
 wrote:
> 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?

Firstly, we have well understood protocols definitions, so there
are several shorthand flavors that could be introduced;

  Listen https

has a very plain and obvious meaning. Thus, so would these;

  Listen https://192.168.1.1
  Listen https://xxx.yyy
  Listen https://192.168.1.1:8443
  Listen https://xxx.yyy:8443

> Would we expect breakage by such a change?

I think that Listen *:NNN is maybe the most common misconfiguration
in general, on multihomed boxes (and Listen myhost:NNN not answering
the call of localhost being a most common point of confusion :)

Your mention of ServerName is a little misleading. A corresponding
virtual host isn't needed at all. And mod_ssl handshake is always
controlled by the physical vhost (first matching named vhost, name
being ignored), which makes this a little more confusing to users.

What leads me to wonder, even with some easier-to-read Listen
directives, if the user wouldn't be confused by omission of the
SSLEngine on, when their other SSL directives aren't behaving
as expected. Because they placed them in the wrong ,
obviously. But not obvious to them. The need to toggle SSLEngine
may be an unintended usability feature.


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

Definitely not a fan. Why isn't this rewrite simply given in the system
global config?

A connection, later the request, maps to only VirtualHost declaration.
That block would never fire if there is a matching VirtualHost. OTOH,
if no VirtualHost matches, then we use the global host anyways.

Listen 443 https

[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

Re: v1.10.10: fixing stream response getting stuck when writing >32k on a...

[Jacob Perkins]

Good morning,

This patched cleanly and we’re in the process of testing it now. Many thanks 
Stefan! I owe you a beer or two at the next ApacheCon.

—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Aug 10, 2017, at 4:37 AM, Stefan Eissing  
> wrote:
> 
> 
>> Am 09.08.2017 um 20:32 schrieb Jacob Perkins :
>> 
>> Hi Stefan,
>> 
>> A patch for 2.4.27 would be great. 
>> 
>> Your assistance is greatly appreciated. 
> 
> Gladly. Patch available at: 
> https://github.com/icing/mod_h2/blob/master/patches/mod_h2-v1.10.10-apache-2.4.x.diff
> 
> Cheers,
> 
> Stefan
> 
>> —
>> Jacob Perkins
>> Product Owner
>> cPanel Inc.
>> 
>> jacob.perk...@cpanel.net
>> Office:  713-529-0800 x 4046
>> Cell:  713-560-8655
>> 
>>> On Aug 9, 2017, at 12:33 PM, Stefan Eissing  
>>> wrote:
>>> 
>>> Hi Jacob,
>>> 
>>> you can use the github release or I can make a patch for 2.4.27 tomorrow. 
>>> Just say what you prefer. 
>>> 
>>> -Stefan
>>> 
>>> Am 09.08.2017 um 18:39 schrieb Jacob Perkins :
>>> 
 Howdy!
 
 We’re starting to see this issue crop up with our customers. We tried 
 patching the commit, but it doesn’t patch cleanly against the latest 2.4.x.
 
 Is the recommended option here to build against h2 master instead of 
 what’s packaged with 2.4? 
 
 —
 Jacob Perkins
 Product Owner
 cPanel Inc.
 
 jacob.perk...@cpanel.net
 Office:  713-529-0800 x 4046
 Cell:  713-560-8655
 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: v1.10.10: fixing stream response getting stuck when writing >32k on a...

[Stefan Eissing]

> Am 09.08.2017 um 20:32 schrieb Jacob Perkins :
> 
> Hi Stefan,
> 
> A patch for 2.4.27 would be great. 
> 
> Your assistance is greatly appreciated. 

Gladly. Patch available at: 
https://github.com/icing/mod_h2/blob/master/patches/mod_h2-v1.10.10-apache-2.4.x.diff

Cheers,

Stefan

> —
> Jacob Perkins
> Product Owner
> cPanel Inc.
> 
> jacob.perk...@cpanel.net
> Office:  713-529-0800 x 4046
> Cell:  713-560-8655
> 
>> On Aug 9, 2017, at 12:33 PM, Stefan Eissing  
>> wrote:
>> 
>> Hi Jacob,
>> 
>> you can use the github release or I can make a patch for 2.4.27 tomorrow. 
>> Just say what you prefer. 
>> 
>> -Stefan
>> 
>> Am 09.08.2017 um 18:39 schrieb Jacob Perkins :
>> 
>>> Howdy!
>>> 
>>> We’re starting to see this issue crop up with our customers. We tried 
>>> patching the commit, but it doesn’t patch cleanly against the latest 2.4.x.
>>> 
>>> Is the recommended option here to build against h2 master instead of what’s 
>>> packaged with 2.4? 
>>> 
>>> —
>>> Jacob Perkins
>>> Product Owner
>>> cPanel Inc.
>>> 
>>> jacob.perk...@cpanel.net
>>> Office:  713-529-0800 x 4046
>>> Cell:  713-560-8655
>>> 
>