Re: [PATCH] Remove unused enum values in mpm_winnt

[Evgeny Kotkov]

Ivan Zhakov  writes:

> Please find attached patch that removes unused values of io_state_e
> enum in mpm_winnt.

Thanks, patch committed in https://svn.apache.org/r1801657


Regards,
Evgeny Kotkov

Re: 2.4.27

[Jim Riggs]

> On 11 Jul 2017, at 11:46, James Cloos  wrote:
> 
>> "JJ" == Jim Jagielski  writes:
> 
> JJ>   *) mod_http2: disable and give warning when mpm_prefork is encountered. 
> The server will
> JJ>  continue to work, but HTTP/2 will no longer be negotiated. [Stefan 
> Eissing]
> 
> Why break h2 w/ prefork.
> 
> AIUI, one still needs to use prefork with the perl and php modules.
> 
> And it works fine here with 2.4.25.
> 
> That change makes 2.4.27 worthless.

See previous discussion in the "2.4.27" thread, specifically:

https://lists.apache.org/thread.html/bae472cadaeeb761b88bb4569cc0b7d87bc2dcb2fbcbf472d895f32e@%3Cdev.httpd.apache.org%3E

Re: svn commit: r1406495 - in /httpd/httpd/trunk: CHANGES include/http_config.h server/core.c

[Eric Covener]

Does anyone recall what kind of directives were misbehaving?  It seems
like many things that work in Location/LocationMatch but not
Directory/Files would tend to work with 

The single-arg form of Alias for example gets caught up in this check

if (!file_req) {
   if ((access_status = ap_location_walk(r))) {
   return access_status;
   }
   if ((access_status = ap_if_walk(r))) {
   return access_status;
   }

   d = ap_get_core_module_config(r->per_dir_config);
   if (d->log) {
   r->log = d->log;
   }

   if ((access_status = ap_run_translate_name(r))) {
   return decl_die(access_status, "translate", r);
   }
   }

   /* Reset to the server default config prior to running map_to_storage
*/
   r->per_dir_config = r->server->lookup_defaults;

   if ((access_status = ap_run_map_to_storage(r))) {
   /* This request wasn't in storage (e.g. TRACE) */
   return access_status;
   }

On Wed, Nov 7, 2012 at 3:33 AM,   wrote:
> Author: sf
> Date: Wed Nov  7 08:33:05 2012
> New Revision: 1406495
>
> URL: http://svn.apache.org/viewvc?rev=1406495=rev
> Log:
> Make ap_check_cmd_context() treat  sections like  sections.
> This is necessary to properly disallow directives that don't work in
> .
>
> A separate NOT_IN_IF flag may be nicer, but would create much more
> hassle when being backported to 2.4.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/include/http_config.h
> httpd/httpd/trunk/server/core.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1406495=1406494=1406495=diff
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Nov  7 08:33:05 2012
> @@ -1,6 +1,9 @@
>   -*- coding: utf-8 
> -*-
>  Changes with Apache 2.5.0
>
> +  *) Be more correct about rejecting directives that cannot work in 
> + sections. [Stefan Fritsch]
> +
>*) core: Fix directives like LogLevel that need to know if they are invoked
>   at virtual host context or in Directory/Files/Location/If sections to
>   work properly in If sections that are not in a Directory/Files/Location.
>
> Modified: httpd/httpd/trunk/include/http_config.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_config.h?rev=1406495=1406494=1406495=diff
> ==
> --- httpd/httpd/trunk/include/http_config.h (original)
> +++ httpd/httpd/trunk/include/http_config.h Wed Nov  7 08:33:05 2012
> @@ -901,11 +901,11 @@ AP_DECLARE(const char *) ap_check_cmd_co
>  #define  NOT_IN_LIMIT   0x02 /**< Forbidden in Limit */
>  #define  NOT_IN_DIRECTORY   0x04 /**< Forbidden in Directory */
>  #define  NOT_IN_LOCATION0x08 /**< Forbidden in Location */
> -#define  NOT_IN_FILES   0x10 /**< Forbidden in Files */
> +#define  NOT_IN_FILES   0x10 /**< Forbidden in Files or 
> If*/
>  #define  NOT_IN_HTACCESS0x20 /**< Forbidden in .htaccess files */
> -/** Forbidden in Directory/Location/Files*/
> +/** Forbidden in Directory/Location/FilesIf*/
>  #define  NOT_IN_DIR_LOC_FILE
> (NOT_IN_DIRECTORY|NOT_IN_LOCATION|NOT_IN_FILES)
> -/** Forbidden in 
> VirtualHost/Limit/Directory/Location/Files
>  */
> +/** Forbidden in 
> VirtualHost/Limit/Directory/Location/Files/If
>  */
>  #define  GLOBAL_ONLY
> (NOT_IN_VIRTUALHOST|NOT_IN_LIMIT|NOT_IN_DIR_LOC_FILE)
>
>  /** @} */
>
> Modified: httpd/httpd/trunk/server/core.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1406495=1406494=1406495=diff
> ==
> --- httpd/httpd/trunk/server/core.c (original)
> +++ httpd/httpd/trunk/server/core.c Wed Nov  7 08:33:05 2012
> @@ -1144,7 +1144,10 @@ AP_DECLARE(const char *) ap_check_cmd_co
>  || (found = find_parent(cmd->directive, "  || ((forbidden & NOT_IN_FILES)
>  && ((found = find_parent(cmd->directive, " -|| (found = find_parent(cmd->directive, " +|| (found = find_parent(cmd->directive, " +|| (found = find_parent(cmd->directive, " +|| (found = find_parent(cmd->directive, " +|| (found = find_parent(cmd->directive, "  return apr_pstrcat(cmd->pool, cmd->cmd->name, gt,
> " cannot occur within ", found->directive,
> "> section", NULL);
>
>



-- 
Eric Covener
cove...@gmail.com

Re: [RFC/PATCH] mpm_winnt: Fix several issues in the child process shutdown logic

[Evgeny Kotkov]

Evgeny Kotkov  writes:

>  (1) As a part of the process of shutting down worker threads, the code
>  around child.c:1170 currently posts an amount of I/O completion packets
>  equal to the amount of the threads blocked on the I/O completion port.
>  Then it sleeps until all these threads "acknowledge" the completion
>  packets by decrementing the global amount of blocked threads.
>
>  This can be improved to avoid unnecessary Sleep()'s, and make the
>  shutdown faster.  There is no need to block until the threads actually
>  receive the completion, as the shutdown process includes a separate step
>  that waits until the threads exit.  Instead of synchronizing on the
>  amount of the threads blocked on the I/O completion port, we can send
>  the number of IOCP_SHUTDOWN completion packets equal to the total
>  amount of threads and immediately proceed to the next step.

Committed in https://svn.apache.org/r1801635

>   (2) If the shutdown routine hits a timeout while waiting for the worker
>   threads to exit, it uses TerminateThread() to terminate the remaining
>   threads.
>
>   Using TerminateThread() can have dangerous consequences such as
>   deadlocks — say, if the the thread is terminated while holding a lock
>   or a heap lock in the middle of HeapAlloc(), as these locks would not
>   be released.  Or it can corrupt the application state and cause a crash.
>   See https://msdn.microsoft.com/en-us/library/windows/desktop/ms686717
>
>   Presumably, a much better alternative here would be to leave the cleanup
>   to the operating system by calling TerminateProcess().

Committed in https://svn.apache.org/r1801636

>   (3) Assuming (2) is in place, the code around child.c:1170 that waits for
>   multiple thread handles in batches can be simplified.  With (2), there
>   is no difference between ending the wait with one or multiple remaining
>   threads.  (Since we terminate the process if at least one thread is
>   still active when we hit a timeout.)
>
>   Therefore, instead of making an effort to evenly distribute and batch
>   the handles with WaitForMultipleObjects(), we could just start from
>   one end, and wait for one thread handle at a time.

Committed in https://svn.apache.org/r1801637


Regards,
Evgeny Kotkov

Re: svn commit: r1801594 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_wstunnel.xml modules/proxy/mod_proxy_wstunnel.c

[jean-frederic clere]

On 07/11/2017 02:36 PM, Yann Ylavic wrote:
> On Tue, Jul 11, 2017 at 1:41 PM,   wrote:
>> Author: jfclere
>> Date: Tue Jul 11 11:41:44 2017
>> New Revision: 1801594
>>
>> URL: http://svn.apache.org/viewvc?rev=1801594=rev
>> Log:
>>
>> Add logic to read the Upgrade header and use it in the response.
>> Use we you are proxying to a server that has multiple upgrade on the same 
>> IP/Port.
>> PR 61142
> 
> I think it's quite hazardous to use/allow ANY and would prefer the
> upgrade_method (worker->s->upgrade) to be a list of acceptable
> protocols.

Probably...

> 
> The admin surely knows which protocol(s) the backend supports, the
> issue being that otherwise most backends will ignore the Upgrade and
> hence the connection will continue in normal HTTP (tunneled w/o any
> protocol checking).
> 
> IMO the Upgrade handling should be part of mod_proxy_http (not
> _wstunnel) and depend on whether or not the backend accepted it.

Correct upgrade belongs to the HTTP protocol.

Cheers

Jean-Frederic

> 
> It was already discussed in [1], well, I can't say that the idea was
> unanimous at that time...
> The proposed patch there is probably outdated now, but I still find it
> safer than what we have now.
> 
> Regards,
> Yann.
> 
> [1] https://www.mail-archive.com/dev@httpd.apache.org/msg66204.html
> 

Re: 2.4.27

[James Cloos]

> "JJ" == Jim Jagielski  writes:

JJ>   *) mod_http2: disable and give warning when mpm_prefork is encountered. 
The server will
JJ>  continue to work, but HTTP/2 will no longer be negotiated. [Stefan 
Eissing]

Why break h2 w/ prefork.

AIUI, one still needs to use prefork with the perl and php modules.

And it works fine here with 2.4.25.

That change makes 2.4.27 worthless.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: An ask for eyes on proposal

[Jim Jagielski]

+1 for Whitelisting...

> On Jul 10, 2017, at 12:02 PM, William A Rowe Jr  wrote:
> 
> Based on the fact that Jim's advanced this for consideration for 2.4.28,
> any further feedback on the following proposal to make RemoteIPProxyProtocol
> directive into a whitelist (to compliment the current blacklist directive)? 
> E.g.
> in the spirit of the protocol, assign specific remote ip consumers to the list
> of those where we accept PROXY protocol wrapping?
> 
> 
> On Fri, Jun 9, 2017 at 8:29 AM, William A Rowe Jr  wrote:
>> On Fri, Jun 9, 2017 at 4:17 AM, Sander Hoentjen  wrote:
>>> On 06/08/2017 07:30 PM, Daniel Ruggeri wrote:
 Hi, all;
 With the proposal to T set for Monday, I wanted to draw attention to
 the PROXY protocol proposal in STATUS. Just hoping for a quick review.
 I know it appears to be a large change, but as I worked through the
 feedback, ten of the commits effectively got coded out. What we are
 left with is essentially just the donated code + safety around IPv6 +
 the ability to designate subnets that do not get PROXY processing.
>>> 
>>> [...] I still believe it would be better to specify enabling
>>> Proxy Protocol on a server, not vhost level. Because well, once you
>>> enable it in one vhost it gets enabled for all vhosts using that port/ip
>>> combination.
>>> 
>>> Here is what I said before about it:
>>> 
>>> Right now the patch proposes RemoteIPProxyProtocol inside a vhost config, 
>>> but wouldn't it be better (since it is connection-specific) to have 
>>> something like a ProxyProtocolListen directive? Where you say instead of:
>>> --
>>> 
>>> RemoteIPProxyProtocol On
>>> 
>>> --
>>> Something like:
>>> --
>>> ProxyProtocolListen 127.0.0.1:9001
>>> or
>>> ProxyProtocolEnable 127.0.0.1:9001
>>> --
>>> 
>>> IMHO this is much cleaner than within a vhost (because that has 
>>> side-effects on other vhosts as well)
>> 
>> As this lives in mod_remoteip (for better or worse) let's look at what
>> context mod_remoteip is configured in; we set up a list of those local
>> or global *client* IP's which we trust to provide legit x-f-f (or remote-ip
>> or otherly named) true IP address header fields.
>> 
>> in the PROXY protocol case, we configure which *client* IP's which
>> we *require* to submit a PROXY protocol line. Right now, we do that
>> as a RemoteIPProxyProtocolExceptions list of those which we do *not*
>> allow to submit a PROXY protocol line. I proposed we make the config
>> simpler, in theory, by listing those we will trust.
>> 
>> To your example, the *global* config line;
>> 
>> RemoteIPProxyProtocol 127.0.0.1  [or 127.0.0.0/24]
>> 
>> would configure all locally routed *client* requests, irrespective of
>> which by-IP vhost, to require the PROXY protocol line. Requests
>> from other hosts would be denied.
>> 
>> I think that's sufficient. But if we wanted to implement your basic
>> idea, we would still have the complication that we need to infer
>> whether 9001 is a http, https, or h2 listener following the PROXY
>> line processing. Your proposed syntax didn't really touch on that.
>> 
>> It is still possible to override behavior by-vhost (ip-based, we are
>> unprepared to read the TLS SNI or Host header at that point)
>> but I don't see any application to do so. A given client is either
>> an haproxy or similar, or it is not.

[Announcement] Apache HTTP Server 2.2.34 Released

[William A Rowe Jr]

  July 11, 2017

   The Apache Software Foundation and the Apache HTTP Server Project
   announce the release of version 2.2.34 of the Apache HTTP Server
   ("Apache"), the final maintenance release of the 2.2 series. No
   further 2.2 releases are anticipated. This version of Apache is
   principally a security and bug fix maintenance release.

   We consider the current Apache HTTP Server 2.4 release to be the best
   version of Apache available, and encourage every user of 2.2 and all
   prior versions to upgrade. This final 2.2 release is offered for those
   unable to upgrade at this moment.

   Take note that Apache Web Server Project will provide no future release
   of the 2.2.x series, although some security patches may be published
   through December of 2017. These will be collected at the URL;

 http://www.apache.org/dist/httpd/patches/apply_to_2.2.34/

   No further maintenance patches of 2.2.x will be published. Users are
   strongly encouraged to promptly complete their transitions to the
   2.4.x flavor of httpd to receive any future benefit from the user
   community or the Apache HTTP Server project developers.

   For further details about the currently supported release, see:

 http://www.apache.org/dist/httpd/Announcement2.4.txt

   Apache HTTP Server 2.4 and 2.2.34 are available for download from:

 http://httpd.apache.org/download.cgi

   Please see the CHANGES_2.2 file, linked from the download page, for a
   full list of changes. A condensed list, CHANGES_2.2.34 includes only
   those changes introduced since the prior 2.2 release. A summary of all
   of the security vulnerabilities addressed in this and earlier releases
   is available:

 http://httpd.apache.org/security/vulnerabilities_22.html

   Note that the Apache HTTP Server project will discontinue evaluations
   and corresponding advisories to this resource effective January, 2018.

   This release includes the Apache Portable Runtime (APR) version 1.5.2
   and APR Utility Library (APR-util) version 1.5.4, bundled with the tar
   and zip distributions. The APR libraries libapr and libaprutil (and
   on Win32, libapriconv version 1.2.1) must all be updated to ensure
   binary compatibility and address many known security and platform bugs.
   APR version 1.5 and APR-util version 1.5 represent minor version upgrades
   from earlier httpd 2.2 source distributions.

   Note this package also includes very stale and known-vulnerable versions
   of the Expat [http://expat.sourceforge.net/] and PCRE [http://www.pcre.org/]
   packages. Users are strongly encouraged to first install the most recent
   versions of these components (of PCRE 8.x, not PCRE2 10.x at this time.)

   This release builds on and extends the Apache 2.0 API and is superceeded
   by the Apache 2.4 API. Modules written for Apache 2.2 will need to be
   recompiled in order to run with Apache 2.4, and most will require minimal
   or no source code changes.

Re: 2.4.27

[Helmut K. C. Tessarek]

On 2017-07-11 08:55, David Zuelke wrote:
> That PHP bug affects parsing of PHP-FPM's config file. It has nothing
> to do with the FastCGI interface or its runtime behavior.

Nope, it also fixed a web application for me.
see https://github.com/nextcloud/server/issues/5660

-- 
regards Helmut K. C. Tessarek
lookup https://sks-keyservers.net/i for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/

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

[David Zuelke]

On 10. Jul 2017, at 16:04, Reindl Harald  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.

[ANNOUNCEMENT] Apache HTTP Server 2.4.27 Released

[Jim Jagielski]

   Apache HTTP Server 2.4.27 Released

July 11, 2017

The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.27 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. Users are encouraged
to upgrade as soon as possible.

We consider this release to be the best version of Apache available, and
encourage users of all prior versions to upgrade.

Apache HTTP Server 2.4.27 is available for download from:

http://httpd.apache.org/download.cgi

Apache 2.4 offers numerous enhancements, improvements, and performance
boosts over the 2.2 codebase.  For an overview of new features
introduced since 2.4 please see:

http://httpd.apache.org/docs/trunk/new_features_2_4.html

Please see the CHANGES_2.4 file, linked from the download page, for a
full list of changes. A condensed list, CHANGES_2.4.27 includes only
those changes introduced since the prior 2.4 release.  A summary of all 
of the security vulnerabilities addressed in this and earlier releases 
is available:

http://httpd.apache.org/security/vulnerabilities_24.html

Of particular note in this release are 3 COMPATIBILITY items:

o HTTP/2 will not be negotiated when using the Prefork MPM
o FastCGI compatibility with PHP-FPM is fixed
o mod_lua no longer exports the undocumented and unsupported
  'apr_table' variable.

This release requires the Apache Portable Runtime (APR), minimum
version 1.5.x, and APR-Util, minimum version 1.5.x. Some features may
require the 1.6.x version of both APR and APR-Util. The APR libraries
must be upgraded for all features of httpd to operate correctly.

This release builds on and extends the Apache 2.2 API.  Modules written
for Apache 2.2 will need to be recompiled in order to run with Apache
2.4, and require minimal or no source code changes.

http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

When upgrading or installing this version of Apache, please bear in mind
that if you intend to use Apache with one of the threaded MPMs (other
than the Prefork MPM), you must ensure that any modules you will be
using (and the libraries they depend on) are thread-safe.

Please note that Apache Web Server Project will only provide maintenance
releases of the 2.2.x flavor through June of 2017, and will provide some
security patches beyond this date through at least December of 2017.
Minimal maintenance patches of 2.2.x are expected throughout this period,
and users are strongly encouraged to promptly complete their transitions
to the the 2.4.x flavor of httpd to benefit from a much larger assortment
of minor security and bug fixes as well as new features.

Re: svn commit: r1801594 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_wstunnel.xml modules/proxy/mod_proxy_wstunnel.c

[Yann Ylavic]

On Tue, Jul 11, 2017 at 1:41 PM,   wrote:
> Author: jfclere
> Date: Tue Jul 11 11:41:44 2017
> New Revision: 1801594
>
> URL: http://svn.apache.org/viewvc?rev=1801594=rev
> Log:
>
> Add logic to read the Upgrade header and use it in the response.
> Use we you are proxying to a server that has multiple upgrade on the same 
> IP/Port.
> PR 61142

I think it's quite hazardous to use/allow ANY and would prefer the
upgrade_method (worker->s->upgrade) to be a list of acceptable
protocols.

The admin surely knows which protocol(s) the backend supports, the
issue being that otherwise most backends will ignore the Upgrade and
hence the connection will continue in normal HTTP (tunneled w/o any
protocol checking).

IMO the Upgrade handling should be part of mod_proxy_http (not
_wstunnel) and depend on whether or not the backend accepted it.

It was already discussed in [1], well, I can't say that the idea was
unanimous at that time...
The proposed patch there is probably outdated now, but I still find it
safer than what we have now.

Regards,
Yann.

[1] https://www.mail-archive.com/dev@httpd.apache.org/msg66204.html