You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2017/01/09 16:12:53 UTC
svn commit: r1778004 - /httpd/httpd/branches/2.4.x/STATUS
Author: wrowe
Date: Mon Jan 9 16:12:53 2017
New Revision: 1778004
URL: http://svn.apache.org/viewvc?rev=1778004&view=rev
Log:
Upvote and promote 3 patches, note one being-worked, as yet unworkable backport
Modified:
httpd/httpd/branches/2.4.x/STATUS
Modified: httpd/httpd/branches/2.4.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1778004&r1=1778003&r2=1778004&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Jan 9 16:12:53 2017
@@ -119,6 +119,24 @@ RELEASE SHOWSTOPPERS:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
+ *) util_fcgi: Fix crash with empty-valued envvars. PR60275
+ trunk patch: http://svn.apache.org/r1775487.
+ 2.4.x patch: trunk works
+ +1 covener, jim, wrowe
+
+ *) mod_auth_digest: Reduce severity from NOTICE to DEBUG this
+ once-per-restart msg (I guess the concern was that the RNG
+ could block after this message)
+ AH01757: generating secret for digest authentication ...
+ trunk patch: This was fixed in trunk as a trivial part of http://svn.apache.org/r1492395
+ 2.4.x patch: Just change the loglevel to DEBUG.
+ +1: covener, jim, wrowe
+
+ *) http: allow folding in check_headers(), still compliant with RFC 7230 (3.2.4).
+ trunk patch: http://svn.apache.org/r1777460
+ http://svn.apache.org/r1777672
+ 2.4.x patch: trunk works
+ +1: ylavic, covener, wrowe
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
@@ -142,11 +160,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
2.4.x patch: trunk works
+1: ylavic, jim
- *) util_fcgi: Fix crash with empty-valued envvars. PR60275
- trunk patch: http://svn.apache.org/r1775487.
- 2.4.x patch: trunk works
- +1 covener, jim
-
*) mod_proxy_fcgi: Return HTTP 504 rather than 503 in case of proxy timeout.
trunk patch: http://svn.apache.org/r1775858
2.4 patch: trunk works (modulo CHANGES)
@@ -162,27 +175,12 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
http://people.apache.org/~druggeri/patches/RemoteIPProxyProtocol.2.4.x.patch
+1: druggeri, jim
- *) mod_auth_digest: Reduce severity from NOTICE to DEBUG this
- once-per-restart msg (I guess the concern was that the RNG
- could block after this message)
-
- AH01757: generating secret for digest authentication ...
-
- trunk patch: This was fixed in trunk as a trivial part of http://svn.apache.org/r1492395
- 2.4.x patch: Just change the loglevel to DEBUG.
- +1: covener, jim
-
*) mod_filter: AddOutputFilterByType should use underlying filters type, not just
AP_FTYPE_CONTENT_SET. PR58856
trunk patch: http://svn.apache.org/r1726705
2.4.x patch: trunk works
+1: covener, jim
- *) http: allow folding in check_headers(), still compliant with RFC 7230 (3.2.4).
- trunk patch: http://svn.apache.org/r1777460
- http://svn.apache.org/r1777672
- 2.4.x patch: trunk works
- +1: ylavic, covener
PATCHES/ISSUES THAT ARE BEING WORKED
[ New entried should be added at the START of the list ]
@@ -275,6 +273,27 @@ PATCHES/ISSUES THAT ARE BEING WORKED
(& also, making the structure change with apr-util version
means it breaks binary compat across an apr-util upgrade?)
+ * Support PCRE2 (10.x) in place of PCRE (8.x).
+ Submitted by: wrowe, Petr Pisar [ppisar redhat.com]
+ trunk patches:
+ http://svn.apache.org/r1773454
+ http://svn.apache.org/r1773741
+ http://svn.apache.org/r1773742
+ http://svn.apache.org/r1773839
+ http://svn.apache.org/r1773870
+ http://svn.apache.org/r1773882
+ wrowe notes that the current code is too inefficient, owing to the fact
+ that the ovector is a required allocation and is no longer allocated on
+ the stack, by design. The correct fix is an apr userdata allocation on
+ the appropriate pool, which would be thread-safe, but the actual API of
+ ap_regexec[_len]() offers us no pool. We cannot associate that pool with
+ the ap_regex_t, because a single regex may be used by many threads in
+ parallel and is not thread-safe beyond initialization.
+ So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to write
+ this as a thread safe storage buffer for the majority of cases (<10 $args)
+ and we don't have a portable tls mechanism to do so.
+
+
PATCHES/ISSUES THAT ARE STALLED
* core: Add ap_errorlog_provider to make ErrorLog logging modular. This
Re: svn commit: r1778004 - /httpd/httpd/branches/2.4.x/STATUS
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Jan 12, 2017 at 6:02 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Thu, Jan 12, 2017 at 10:54 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Thu, Jan 12, 2017 at 5:32 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>>>
>>>> + So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to write
>>>> + this as a thread safe storage buffer for the majority of cases (<10 $args)
>>>> + and we don't have a portable tls mechanism to do so.
>>
>> Don't we, apr_threadkey_private_*()?
>
> Which in turn... requires the apr_pool_t * all over again, so not really;
>
> https://apr.apache.org/docs/apr/2.0/group__apr__thread__proc.html#gacb9553b2b3165388bfc0a54b1148804a
Well, the pool is needed to create the key, which could be done once
and for all at httpd startup (with ap_pglobal or pproc).
Re: svn commit: r1778004 - /httpd/httpd/branches/2.4.x/STATUS
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 12, 2017 at 10:54 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Thu, Jan 12, 2017 at 5:32 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>>
>>> + So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to write
>>> + this as a thread safe storage buffer for the majority of cases (<10 $args)
>>> + and we don't have a portable tls mechanism to do so.
>
> Don't we, apr_threadkey_private_*()?
Which in turn... requires the apr_pool_t * all over again, so not really;
https://apr.apache.org/docs/apr/2.0/group__apr__thread__proc.html#gacb9553b2b3165388bfc0a54b1148804a
>> Does anyone have a good suggestion on this that would be back-portable
>> and threadsafe for 2.4, before I surrender and make the trunk-only change
>> to include the worker's/thread's pool for this reusable buffer tagged with a
>> pooldata(m) in a new apr_pool_t * passed to the ap_regexec[_len] functions?
>
> Maybe having the match_data in a TLS created with a reasonable size
> (i.e. 50) on the first use?
For our purposes, I think the generic buffer of 10 ($0-$9) for most cases
is probably sufficient. But if folks like the idea (and consider that TLS may
be supporting almost 2k worker threads on an MPM like win32) perhaps
we use a quadratic reallocator, to leap from 10 to 40 to 160 or something
like that? But I would expect some 160 args to be a defective config or
malicious .htaccess exploit.
Our API isn't suited to named args, etc. At some point, a richer API might
want a bigger default. But allocating and freeing (or using a pool based
alternate allocator, with no requirement to 'free()') may be the most
efficient way to handle excessively long ovectors.
Re: svn commit: r1778004 - /httpd/httpd/branches/2.4.x/STATUS
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Jan 12, 2017 at 5:32 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> + So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to write
>> + this as a thread safe storage buffer for the majority of cases (<10 $args)
>> + and we don't have a portable tls mechanism to do so.
Don't we, apr_threadkey_private_*()?
>
> Does anyone have a good suggestion on this that would be back-portable
> and threadsafe for 2.4, before I surrender and make the trunk-only change
> to include the worker's/thread's pool for this reusable buffer tagged with a
> pooldata(m) in a new apr_pool_t * passed to the ap_regexec[_len] functions?
Maybe having the match_data in a TLS created with a reasonable size
(i.e. 50) on the first use?
Re: svn commit: r1778004 - /httpd/httpd/branches/2.4.x/STATUS
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Jan 9, 2017 at 10:12 AM, <wr...@apache.org> wrote:
> Author: wrowe
> Date: Mon Jan 9 16:12:53 2017
> New Revision: 1778004
>
> PATCHES/ISSUES THAT ARE BEING WORKED
> [ New entried should be added at the START of the list ]
> @@ -275,6 +273,27 @@ PATCHES/ISSUES THAT ARE BEING WORKED
> (& also, making the structure change with apr-util version
> means it breaks binary compat across an apr-util upgrade?)
>
> + * Support PCRE2 (10.x) in place of PCRE (8.x).
> + Submitted by: wrowe, Petr Pisar [ppisar redhat.com]
> + trunk patches:
> + http://svn.apache.org/r1773454
> + http://svn.apache.org/r1773741
> + http://svn.apache.org/r1773742
> + http://svn.apache.org/r1773839
> + http://svn.apache.org/r1773870
> + http://svn.apache.org/r1773882
> + wrowe notes that the current code is too inefficient, owing to the fact
> + that the ovector is a required allocation and is no longer allocated on
> + the stack, by design. The correct fix is an apr userdata allocation on
> + the appropriate pool, which would be thread-safe, but the actual API of
> + ap_regexec[_len]() offers us no pool. We cannot associate that pool with
> + the ap_regex_t, because a single regex may be used by many threads in
> + parallel and is not thread-safe beyond initialization.
> + So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to write
> + this as a thread safe storage buffer for the majority of cases (<10 $args)
> + and we don't have a portable tls mechanism to do so.
Does anyone have a good suggestion on this that would be back-portable
and threadsafe for 2.4, before I surrender and make the trunk-only change
to include the worker's/thread's pool for this reusable buffer tagged with a
pooldata(m) in a new apr_pool_t * passed to the ap_regexec[_len] functions?