Re: svn commit: r1855449 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_mime.xml modules/http/mod_mime.c

[Eric Covener]

On Wed, Mar 13, 2019 at 3:56 PM Ruediger Pluem  wrote:
>
>
>
> On 03/13/2019 07:41 PM, cove...@apache.org wrote:
> > Author: covener
> > Date: Wed Mar 13 18:41:30 2019
> > New Revision: 1855449
> >
> > URL: http://svn.apache.org/viewvc?rev=1855449=rev
> > Log:
> > mod_mime: Add `MimeOptions`


Thanks for spotting both!

Re: svn commit: r1855449 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_mime.xml modules/http/mod_mime.c

[Ruediger Pluem]

On 03/13/2019 07:41 PM, cove...@apache.org wrote:
> Author: covener
> Date: Wed Mar 13 18:41:30 2019
> New Revision: 1855449
> 
> URL: http://svn.apache.org/viewvc?rev=1855449=rev
> Log:
> mod_mime: Add `MimeOptions` 
> 
> mod_mime: Add `MimeOptions` directive to allow Content-Type or all metadata
> detection to use only the last (right-most) file extension. 
> 
> 
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/docs/manual/mod/mod_mime.xml
> httpd/httpd/trunk/modules/http/mod_mime.c
> 

> 
> Modified: httpd/httpd/trunk/docs/manual/mod/mod_mime.xml
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_mime.xml?rev=1855449=1855448=1855449=diff
> ==
> --- httpd/httpd/trunk/docs/manual/mod/mod_mime.xml (original)
> +++ httpd/httpd/trunk/docs/manual/mod/mod_mime.xml Wed Mar 13 18:41:30 2019
> @@ -1051,4 +1051,38 @@ RemoveType .cgi
>  mod_mime_magic
>  
>  
> +
> +MimeOptions
> +Configures mod_mime behavior
> +MimeOptionsoption [option] ...
> +server config
> +virtual hostdirectory
> +.htaccess
> +IBM HTTP Server 9.0.0.12 and later

:-)


> Modified: httpd/httpd/trunk/modules/http/mod_mime.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/mod_mime.c?rev=1855449=1855448=1855449=diff
> ==
> --- httpd/httpd/trunk/modules/http/mod_mime.c (original)
> +++ httpd/httpd/trunk/modules/http/mod_mime.c Wed Mar 13 18:41:30 2019

> @@ -364,6 +377,33 @@ static const char *multiviews_match(cmd_
>  return NULL;
>  }
>  
> +static const char *add_mime_options(cmd_parms *cmd, void *in_dc,
> +const char *flag)
> +{
> +mime_dir_config *dc = in_dc;
> +
> +if (!strcasecmp(flag, "TypesLastExtension")) {
> +dc->ct_last_ext = CT_LAST_ON;
> +}
> +else if (!strcasecmp(flag, "NoTypesLastExtension")) {
> +dc->ct_last_ext = CT_LAST_OFF;
> +}
> +else if (!strcasecmp(flag, "AllLastExtension")) {
> +dc->all_last_ext = ALL_LAST_ON;
> +}
> +else if (!strcasecmp(flag, "AllLastExtension")) {

I guess it should be NoAllLastExtension.

> +dc->all_last_ext = ALL_LAST_OFF;
> +}
> +else {
> +return apr_pstrcat(cmd->temp_pool,
> +   "Invalid MimeOptions option: ",
> +   flag,
> +   NULL);
> +}
> +
> +return NULL;
> +}
> +
>  static const command_rec mime_cmds[] =
>  {
>  AP_INIT_ITERATE2("AddCharset", add_extension_info,


Regards

Rüdiger

Re: http://svn.apache.org/r1850745

[William A Rowe Jr]

To take this discussion all the way back to APR project's potential
concerns...

On Wed, Mar 13, 2019 at 8:03 AM Jim Jagielski  wrote:
>
> > On Mar 13, 2019, at 8:56 AM, Nick Kew  wrote:
> >
> >> On 13 Mar 2019, at 12:43, Jim Jagielski  wrote:
> >>
> >> Is there anyone else building 2.4 on macOS under maintainer-mode
> >> who is also being affected by the above? The fact that I seem to
> >> be the anyone "complaining" :) seems weird...
> >
> > Just out of interest, is that with a libxml2-enabled APR version?
> > Guess I need to test-drive that on Mac/latest, which has bitten me
> > on similar platform issues before now!
>
> It's libxml2 from MacPorts... which is basically vanilla libxml2.
>
> APR is 1.6.x

Here's the concern Nick raises... apr 2.0 (and now apr-util 1.7) allow us
to substitute --with-libxml2 in place of expat. This works for most
scenarios (subversion itself still needs expat specifically, since it uses
more than simple apr_xml.)

It would be good to also fix maintainer mode in apr 1.7.0, along with the
OSX quirk in APR_OFF_T_FMT, so we are prepared for the apr-util 1.7.0
libxml2 Nick has just backported. This same compiler emit on OSX should
rise again in this scenario, *except* that in apr we don't toggle -std=c89.
So perhaps we will observe no warnings, if clang defaults to a later -std=
option?

I'd like (speaking from APR's perspective) to find the right solution to
this bogus combination of OSX clang 5 comment rules and their icu library
includes. And we presume that is going to happen again with some other
system headers down the road.

Here's what happens today using libxml2 on httpd;

On Wed, Mar 13, 2019 at 8:04 AM Jim Jagielski  wrote:
>
> > On Wed, Mar 13, 2019 at 1:45 PM Eric Covener  wrote:
> >>
> >> On Wed, Mar 13, 2019 at 8:43 AM Jim Jagielski  wrote:
> >>>
> >>> Is there anyone else building 2.4 on macOS under maintainer-mode
> >>> who is also being affected by the above? The fact that I seem to
> >>> be the anyone "complaining" :) seems weird...
> >>
> >> FWIW Looks like I have maintainer mode but not libxml2
>
> Yeah, I also think it depends on the version of clang... previous
versions did not flag
>
> /usr/local/include/unicode/uenum.h:1:1: error: // comments are not
allowed in this language [-Werror,-Wcomment]
>
> as fatal errors.

To solve for the case of --with-maintainer-mode for APR + APR-UTIL 1.7
releases, I see three possibilities;

  Only for maintainer mode, where we are strictly handling all errors,
always
  check all -std=c99 behaviors (fix any legacy pre-c99 issues that may
arise.)
  All the system headers using c99 (or earlier) semantics should behave
well.
  I'm expecting we still adhere to c89, especially in all APR 1.x releases,
but
  we don't need to explicitly add that flag to normal builds, IMO.

  Or, for maintainer mode, always relax the comments restriction only so we
  always add -Wno-error=comment. You can almost call this c99-lite which
  solves one c99'ism in newer system headers without allowing all possible
  c99'isms in system headers, and without overriding the -std flag defaults
  at all.

  Or, introduce no -std flag, similar to above, and only in the clang 5 case
  add -Wno-error=comment in apr maintainer mode so that even if
  -std=c89 is toggled elsewhere, that particular error is overriden.

This is the current APR maintainer-mode logic;

AC_ARG_ENABLE(maintainer-mode,[  --enable-maintainer-mode  Turn on
debugging and compile time warnings],
  [APR_ADDTO(CFLAGS,-g)
   if test "$GCC" = "yes"; then
 APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations])
  case `($CC --version) 2>/dev/null` in
*clang-900* | *"clang version 5.0.0"*)
  APR_ADDTO(CFLAGS,[-Wno-error=strict-prototypes])
  ;;
  esac
   elif test "$AIX_XLC" = "yes"; then
 APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
   fi
])dnl

Note that there is no future-proofing here, clang 5.0.1 or 5.1.0 wouldn't
escape the strict-prototypes omission (and wondering, why it was needed in
the first place, if not for system headers again.)

Contrast to httpd 2.4's set of flags; -std=c89 -Werror -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
-Wunused

So, what would folks propose we change to APR 1.7.0 maintainer mode, or
does anyone have a positive thought on the above three options?

Re: http://svn.apache.org/r1850745

[Jim Jagielski]

> On Mar 13, 2019, at 11:04 AM, William A Rowe Jr  wrote:
> 
> 
> As you can see, you didn't modify only modules/filters/ ... Maybe you 
> meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does?
>  

If that will solve the issue I'm all for it!

Thx.

Re: http://svn.apache.org/r1850745

[William A Rowe Jr]

Just as a reminder of what r1850745 actually did, from an old discussion;

On Wed, Jan 16, 2019 at 5:09 PM William A Rowe Jr 
wrote:

> On Wed, Jan 16, 2019 at 3:54 PM Jim Jagielski  wrote:
>
>> I'm sorry but I'm confused. The patch is as specific as you can get. It
>> just adds the minimal option and JUST for filters and JUST if libxml2 is
>> part of the build.
>>
>
> Understood, but you might have overlooked the fact that changing CPPFLAGS
> (or CFLAGS - even worse) changes it for the entire build.
>
> My normal config, without your patch;
> ./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
> ./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
> ./build/config_vars.mk:PICFLAGS =
> ./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
> ./build/config_vars.mk:CPPFLAGS =
> ./build/config_vars.mk:CFLAGS =
> ./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
> ./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
> -Wunused
> ./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
> ./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -Wall -Wmissing-prototypes
> -Wstrict-prototypes -Wmissing-declarations -pthread
> ./build/config_vars.mk:INTERNAL_CPPFLAGS =
>
> With your patch in 2.5.x;
> ./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
> ./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
> ./build/config_vars.mk:PICFLAGS =
> ./build/config_vars.mk:UNITTEST_CFLAGS = -pthread
> ./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
> ./build/config_vars.mk:CPPFLAGS =
> ./build/config_vars.mk:CFLAGS =
> ./build/config_vars.mk:CFLAGS_FOR_BUILD =
> ./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
> ./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
> -Wunused -Wno-error=comment
> ./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
> ./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -pthread
> ./build/config_vars.mk:INTERNAL_CPPFLAGS =
>
> As you can see, you didn't modify only modules/filters/ ... Maybe you
> meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does?
>
>
>> Anything else seems more disruptive than that. So why are the more
>> disruptive changes preferred? I'm just trying to understand the logic there.
>>
>
> My thought is that your observation was spot-on that libxml2, but soon
> more and more system headers will introduce C99 headers, and there is
> no reason to apply just the bandaid, certainly not to the whole server
> based on accumulated individual modules/foo/config.m4 bandaids.
> That's my objection to the commit in trunk.
>
> If we agree this is a problem to solve, let's not presume libxml2 will
> be the end of it, and produce another tarball that gets broken with
> maintainer mode in the next OS release of your favorite *nix?
> I'm seeing it as inevitable that we should allow all manner of
> c99'isms from system headers when we build in our most strict mode,
> but when we don't build in maintainer-mode, to leave things at c89
> without -Wall etc. I see that as the most flexible compromise, without
> suggesting that we *add* c99'isms to httpd itself, just yet.
>

On Wed, Mar 13, 2019 at 7:43 AM Jim Jagielski  wrote:

> Is there anyone else building 2.4 on macOS under maintainer-mode
> who is also being affected by the above? The fact that I seem to
> be the anyone "complaining" :) seems weird...
>
> Thx!
>

Re: http://svn.apache.org/r1850745

[William A Rowe Jr]

On Wed, Mar 13, 2019 at 8:04 AM Jim Jagielski  wrote:

>
> Yeah, I also think it depends on the version of clang... previous versions
> did not flag
>
> /usr/local/include/unicode/uenum.h:1:1: error: // comments are not
> allowed in this language [-Werror,-Wcomment]
>
> as fatal errors.


Just looking on Fedora 29, their distribution and truly the vanilla libxml2
source package 2.9.9...

In include/libxml2 tree (dropping all the dups);
grep -r "#include" . | grep -v "
./SAX.h:#include 
./xmlwriter.h:#include 
./tree.h:#include 
./nanoftp.h:#include 
./encoding.h:#include 
./encoding.h:#include 

That's about as vanilla as things get for a C project; no '//' comments.
the problem is in the last item, as you observe above;
 /usr/local/include/unicode/uenum.h:1:1: error: // comments are not allowed
in this language [-Werror,-Wcomment]

Confirmed `grep -r "^[\t ]*//" .` on FC29 that modern /usr/include/unicode/
is full of '//' comments, entirely because...
// © 2016 and later: Unicode, Inc. and others.
// License & terms of use: http://www.unicode.org/copyright.html
/*
***
*
*   Copyright (C) 2002-2013, International Business Machines
...

unicode maintainers did a simple mass-license-update pass in 2016 through
these files using C99/C++ conventions without thinking much about it. The
relevant package on FC29 is libicu-devel-62.1-3.fc29.x86_64 : ("Development
files for International Components for Unicode").

gcc (GCC) 8.3.1 as shipping on FC29 does not flag these comments. Seems
like clang might have become too enthusiastic about enforcing only K
comments, lending the question of whether this is quirk falls entirely on
Apple.

Re: h2 backport proposal

[Stefan Eissing]

> Am 13.03.2019 um 15:41 schrieb Yann Ylavic :
> 
> Got Jim's and my votes, could be merged now ;)
> Please note that the CHANGES entries from the patch are slightly mixed
> with unrelated changes, should be cleaned up when backporting.
> Nice changes otherwise, thanks!

Thanks, Yann! Will do!


> On Wed, Mar 13, 2019 at 2:05 PM Stefan Eissing
>  wrote:
>> 
>> Proposal updated in 1855417.
>> 
>>> Am 13.03.2019 um 13:46 schrieb Stefan Eissing 
>>> :
>>> 
>>> 
 Am 13.03.2019 um 13:32 schrieb Yann Ylavic :
 
 On Wed, Mar 13, 2019 at 12:55 PM Yann Ylavic  wrote:
> 
> On Wed, Mar 13, 2019 at 12:49 PM Stefan Eissing
>  wrote:
>> 
>> It would be nice if 2 people could find the time to have a look at it.
> 
> I'm currently reviewing it, looks good so far, nice!
 
 Looks like the proposal reverts r1852989, normal?
>>> 
>>> Nicely caught! I forgot to bring this over to github, so my recent merge 
>>> over did revert it.
>>> 
>>> Re-added to trunk in: r1855411. Will add to backport proposal.
>>> 
>>> Thanks, Yann!
>>> 
>> 

Re: h2 backport proposal

[Yann Ylavic]

Got Jim's and my votes, could be merged now ;)
Please note that the CHANGES entries from the patch are slightly mixed
with unrelated changes, should be cleaned up when backporting.
Nice changes otherwise, thanks!

On Wed, Mar 13, 2019 at 2:05 PM Stefan Eissing
 wrote:
>
> Proposal updated in 1855417.
>
> > Am 13.03.2019 um 13:46 schrieb Stefan Eissing 
> > :
> >
> >
> >> Am 13.03.2019 um 13:32 schrieb Yann Ylavic :
> >>
> >> On Wed, Mar 13, 2019 at 12:55 PM Yann Ylavic  wrote:
> >>>
> >>> On Wed, Mar 13, 2019 at 12:49 PM Stefan Eissing
> >>>  wrote:
> 
>  It would be nice if 2 people could find the time to have a look at it.
> >>>
> >>> I'm currently reviewing it, looks good so far, nice!
> >>
> >> Looks like the proposal reverts r1852989, normal?
> >
> > Nicely caught! I forgot to bring this over to github, so my recent merge 
> > over did revert it.
> >
> > Re-added to trunk in: r1855411. Will add to backport proposal.
> >
> > Thanks, Yann!
> >
>

Re: h2 backport proposal

[Stefan Eissing]

Proposal updated in 1855417.

> Am 13.03.2019 um 13:46 schrieb Stefan Eissing :
> 
> 
>> Am 13.03.2019 um 13:32 schrieb Yann Ylavic :
>> 
>> On Wed, Mar 13, 2019 at 12:55 PM Yann Ylavic  wrote:
>>> 
>>> On Wed, Mar 13, 2019 at 12:49 PM Stefan Eissing
>>>  wrote:
 
 It would be nice if 2 people could find the time to have a look at it.
>>> 
>>> I'm currently reviewing it, looks good so far, nice!
>> 
>> Looks like the proposal reverts r1852989, normal?
> 
> Nicely caught! I forgot to bring this over to github, so my recent merge over 
> did revert it.
> 
> Re-added to trunk in: r1855411. Will add to backport proposal.
> 
> Thanks, Yann!
> 

Re: http://svn.apache.org/r1850745

[Jim Jagielski]

> On Mar 13, 2019, at 8:51 AM, Yann Ylavic  wrote:
> 
> On Wed, Mar 13, 2019 at 1:45 PM Eric Covener  wrote:
>> 
>> On Wed, Mar 13, 2019 at 8:43 AM Jim Jagielski  wrote:
>>> 
>>> Is there anyone else building 2.4 on macOS under maintainer-mode
>>> who is also being affected by the above? The fact that I seem to
>>> be the anyone "complaining" :) seems weird...
>> 
>> FWIW Looks like I have maintainer mode but not libxml2
> 
> Maintainer mode and libxml2 here, but not macOS :)

Yeah, I also think it depends on the version of clang... previous versions did 
not flag

/usr/local/include/unicode/uenum.h:1:1: error: // comments are not allowed 
in this language [-Werror,-Wcomment]

as fatal errors.

Re: http://svn.apache.org/r1850745

[Jim Jagielski]

It's libxml2 from MacPorts... which is basically vanilla libxml2.

APR is 1.6.x

> On Mar 13, 2019, at 8:56 AM, Nick Kew  wrote:
> 
> 
> 
>> On 13 Mar 2019, at 12:43, Jim Jagielski  wrote:
>> 
>> Is there anyone else building 2.4 on macOS under maintainer-mode
>> who is also being affected by the above? The fact that I seem to
>> be the anyone "complaining" :) seems weird...
>> 
>> Thx!
> 
> Just out of interest, is that with a libxml2-enabled APR version?
> Guess I need to test-drive that on Mac/latest, which has bitten me
> on similar platform issues before now!
> 
> -- 
> Nick Kew
> 

Re: http://svn.apache.org/r1850745

[Nick Kew]

> On 13 Mar 2019, at 12:43, Jim Jagielski  wrote:
> 
> Is there anyone else building 2.4 on macOS under maintainer-mode
> who is also being affected by the above? The fact that I seem to
> be the anyone "complaining" :) seems weird...
> 
> Thx!

Just out of interest, is that with a libxml2-enabled APR version?
Guess I need to test-drive that on Mac/latest, which has bitten me
on similar platform issues before now!

-- 
Nick Kew

Re: http://svn.apache.org/r1850745

[Yann Ylavic]

On Wed, Mar 13, 2019 at 1:45 PM Eric Covener  wrote:
>
> On Wed, Mar 13, 2019 at 8:43 AM Jim Jagielski  wrote:
> >
> > Is there anyone else building 2.4 on macOS under maintainer-mode
> > who is also being affected by the above? The fact that I seem to
> > be the anyone "complaining" :) seems weird...
>
> FWIW Looks like I have maintainer mode but not libxml2

Maintainer mode and libxml2 here, but not macOS :)

Re: h2 backport proposal

[Stefan Eissing]

> Am 13.03.2019 um 13:32 schrieb Yann Ylavic :
> 
> On Wed, Mar 13, 2019 at 12:55 PM Yann Ylavic  wrote:
>> 
>> On Wed, Mar 13, 2019 at 12:49 PM Stefan Eissing
>>  wrote:
>>> 
>>> It would be nice if 2 people could find the time to have a look at it.
>> 
>> I'm currently reviewing it, looks good so far, nice!
> 
> Looks like the proposal reverts r1852989, normal?

Nicely caught! I forgot to bring this over to github, so my recent merge over 
did revert it.

Re-added to trunk in: r1855411. Will add to backport proposal.

Thanks, Yann!

Re: http://svn.apache.org/r1850745

[Eric Covener]

On Wed, Mar 13, 2019 at 8:43 AM Jim Jagielski  wrote:
>
> Is there anyone else building 2.4 on macOS under maintainer-mode
> who is also being affected by the above? The fact that I seem to
> be the anyone "complaining" :) seems weird...

FWIW Looks like I have maintainer mode but not libxml2

http://svn.apache.org/r1850745

[Jim Jagielski]

Is there anyone else building 2.4 on macOS under maintainer-mode
who is also being affected by the above? The fact that I seem to
be the anyone "complaining" :) seems weird...

Thx!

Re: h2 backport proposal

[Yann Ylavic]

On Wed, Mar 13, 2019 at 12:55 PM Yann Ylavic  wrote:
>
> On Wed, Mar 13, 2019 at 12:49 PM Stefan Eissing
>  wrote:
> >
> > It would be nice if 2 people could find the time to have a look at it.
>
> I'm currently reviewing it, looks good so far, nice!

Looks like the proposal reverts r1852989, normal?

Re: h2 backport proposal

[Yann Ylavic]

On Wed, Mar 13, 2019 at 12:49 PM Stefan Eissing
 wrote:
>
> It would be nice if 2 people could find the time to have a look at it.

I'm currently reviewing it, looks good so far, nice!

Cheers.

h2 backport proposal

[Stefan Eissing]

There is a mod_http2/mod_proxy_http2 backport proposal in 2.4.x/STATUS
that accumulates this years changes from the github version. This
includes several bugfixes, 2 of which from Michael Kaufmann (Thanks!), 
for issues reported:

  *) mod_http2: HEAD requests to some module such as mod_cgid caused the stream 
to
 terminate improperly and cause a HTTP/2 PROTOCOL_ERROR. 
 Fixes . [Michael Kaufmann]
  *) mod_http2: when SSL renegotiation is inhibited and a 403 ErrorDocument is
 in play, the proper HTTP/2 stream reset did not trigger with 
H2_ERR_HTTP_1_1_REQUIRED.
 Fixed. [Michael Kaufmann] 
  *) mod_proxy_http2: changed mod_proxy_http2 implementation and fixed several 
bugs which
 resolve PR63170. The proxy module does now a single h2 request on the 
(reused)
 connection and returns. [Stefan Eissing]
  *) mod_http2: enable re-use of slave connections again. Fixed slave connection
 keepalives counter. [Stefan Eissing]

Two features have also been implemented:

  *) mod_http2: new configuration directive: ```H2Padding numbits``` to control 
 padding of HTTP/2 payload frames. 'numbits' is a number from 0-8,
 controlling the range of padding bytes added to a frame. The actual number
 added is chosen randomly per frame. This applies to HEADERS, DATA and 
PUSH_PROMISE
 frames equally. The default continues to be 0, e.g. no padding. [Stefan 
Eissing] 
  *) mod_http2: Configuration directives H2Push and H2Upgrade can now be 
specified per 
 Location/Directory, e.g. disabling PUSH for a specific set of resources. 
[Stefan Eissing]

For the H2Padding, I also wrote a blog at: 
https://icing.github.io/mod_h2/padding.html

It would be nice if 2 people could find the time to have a look at it. 

Cheers, Stefan