Bug 63491 - Apache HTTP Server's mod_ext_filterso not respond the body with APR 1.7.0
Summary: Apache HTTP Server's mod_ext_filterso not respond the body with APR 1.7.0
Status: RESOLVED FIXED
Alias: None
Product: APR
Classification: Unclassified
Component: APR (show other bugs)
Version: 1.7.0
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache Portable Runtime bugs mailinglist
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-08 13:18 UTC by Norimasa Yamamoto
Modified: 2020-10-01 17:12 UTC (History)
4 users (show)



Attachments
Test results (APR 1.5.2 to 1.7.0) (36.52 KB, text/plain)
2019-06-08 13:18 UTC, Norimasa Yamamoto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norimasa Yamamoto 2019-06-08 13:18:14 UTC
Created attachment 36613 [details]
Test results (APR 1.5.2 to 1.7.0)

Apache Lounge built Apache HTTP Server 2.4.39 with APR 1.7.0 at the end of March 219.
But I encountered my external filter program would not respond at this build.

I thoght this issue was occured at APR 1.6.2 too.
(That time, I reported it by e-mail, and it resolved at APR 1.6.3.)

APR (named libapr-1.dll) have functional upward compatibility,
so I tested with APR 1.5.2, 1.6.2, 1.6.5 and 1.7.0.
I will attach the results in CSV format.
Comment 1 Dimitry Andric 2020-09-30 12:46:18 UTC
As far as I can see, this is because trunk r1809753 ("pipe: fix apr_file_pipe_create_ex()'s blocking parameter forwarding") was never backported to the apr 1.7.x branch.

Yann did backport it to the 1.6.x branch in r1809754, but maybe at that point 1.7.x did not exist yet?

In any case, the code in the 1.7.x branch as of r1865793 (the last change was on 2019-08-23) still has:

    74  APR_DECLARE(apr_status_t) apr_file_pipe_create_ex(apr_file_t **in,
    75                                                    apr_file_t **out,
    76                                                    apr_int32_t blocking,
    77                                                    apr_pool_t *p)
    78  {
    79      return apr_file_pipe_create_pools(in, out, APR_FULL_BLOCK, p, p);
    80  }

whereas the 'APR_FULL_BLOCK' parameter should be replaced by 'blocking'.
Comment 2 Dimitry Andric 2020-09-30 13:35:27 UTC
For the sake of completeness, a sample configuration that triggers the error, at least for with Apache Lounge builds of 2.4.39 (apr 1.7.0) or later:

ExtFilterDefine hello-world mode=output \
  cmd="C:/Windows/System32/cmd.exe /c echo Hello World"

<Location /hello-world>
  ExtFilterOptions LogStderr
  SetInputFilter hello-world
</Location>

Even a rudimentary case like this will give you an error like:

[Tue Sep 29 16:22:39.055118 2020] [ext_filter:error] [pid 4140:tid 1448] (22)Invalid argument: [client 127.0.0.1:63582] AH01465: apr_file_pipe_timeout_set(child output)
[Tue Sep 29 16:22:39.055118 2020] [ext_filter:error] [pid 4140:tid 1448] (22)Invalid argument: [client 127.0.0.1:63582] AH01468: ef_unified_filter() failed

The reason is that mod_ext_filter calls apr_procattr_io_set(ctx->procattr, APR_CHILD_BLOCK, APR_CHILD_BLOCK, APR_CHILD_BLOCK), but the APR_CHILD_BLOCK value gets overridden by APR_FULL_BLOCK in apr_file_pipe_create_ex().
Comment 3 Nick Kew 2020-09-30 13:55:21 UTC
1.7 fixed in r1882155 .  Thanks for the clear explanation.
Comment 4 Norimasa Yamamoto 2020-10-01 10:13:29 UTC
It works!
( https://www.apachelounge.com/viewtopic.php?p=39558#39558 )

Thanks to Dimitry Andric and Steffen.
Comment 5 Dimitry Andric 2020-10-01 17:12:13 UTC
The Apache Lounge people have provided a test build with the fix from r1882155 applied, and I have verified that it solves the problem. I am assuming they will soon release new official zip file builds for Apache 2.4.46 + APR 1.7.0, with this fix included.