On Wed, Jun 7, 2023 at 4:36 PM Ruediger Pluem <rpl...@apache.org> wrote:
>
> On 6/7/23 1:56 PM, Yann Ylavic wrote:
> > Hi Giovanni;
> >
> > On Wed, Jun 7, 2023 at 12:02 AM <gbec...@apache.org> wrote:
> >>
> >> Author: gbechis
> >> Date: Tue Jun  6 22:02:37 2023
> >> New Revision: 1910267
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1910267&view=rev
> >> Log:
> >> mod_ext_filter: check exit status of filter processes
> > []
> >>
> >> +/* check_filter_process_on_eos():
> >> + *
> >> + * if we hit end-of-stream, check the exit status of the filter process, 
> >> and log
> >> + * an appropriate message if it failed
> >> + */
> >> +static apr_status_t check_filter_process_on_eos(ef_ctx_t *ctx, 
> >> request_rec *r)
> >> +{
> >> +    if (ctx->hit_eos) {
> >> +        int exitcode;
> >> +        apr_exit_why_e exitwhy;
> >> +        apr_status_t waitret = apr_proc_wait(ctx->proc, &exitcode, 
> >> &exitwhy,
> >> +                                             APR_WAIT);
> >> +        if (waitret != APR_CHILD_DONE) {
> >> +            ap_log_rerror(APLOG_MARK, APLOG_ERR, waitret, r, 
> >> APLOGNO(10451)
> >> +                          "apr_proc_wait() failed, uri=%s", r->uri);
> >> +            return waitret;
> >> +        }
> >> +        else if (exitwhy != APR_PROC_EXIT) {
> >> +            ap_log_rerror(APLOG_MARK, APLOG_ERR, APR_SUCCESS, r, 
> >> APLOGNO(10452)
> >> +                          "child process %s killed by signal %d, uri=%s",
> >> +                          ctx->filter->command, exitcode, r->uri);
> >> +            return HTTP_INTERNAL_SERVER_ERROR;
> >> +        }
> >> +        else if (exitcode != 0) {
> >> +            ap_log_rerror(APLOG_MARK, APLOG_ERR, APR_SUCCESS, r, 
> >> APLOGNO(10453)
> >> +                          "child process %s exited with non-zero status 
> >> %d, "
> >> +                          "uri=%s", ctx->filter->command, exitcode, 
> >> r->uri);
> >> +            return HTTP_INTERNAL_SERVER_ERROR;
> >> +        }
> >
> > HTTP_INTERNAL_SERVER_ERROR (like all HTTP_* statuses) is not an
> > apr_status_t, it shouldn't be returned by a filter (and does not print
> > well as an ap_log_rerror() error status for instance like below).
> >
> > Maybe use APR_EGENERAL? The error message could be enough to
> > distinguish them here.
> > I wouldn't return waitret for the first case either since it's in the
> > error message already, no need to forward it specifically to the
> > caller, so APR_EGENERAL still possibly.
> >
> >> +    }
> >> +
> >> +    return APR_SUCCESS;
> >> +}
> >> +
> >>  /* ef_unified_filter:
> >>   *
> >>   * runs the bucket brigade bb through the filter and puts the result into
> >> @@ -880,6 +914,11 @@ static apr_status_t ef_output_filter(ap_
> >>      if (rv != APR_SUCCESS) {
> >>          ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01468)
> >>                        "ef_unified_filter() failed");
> >> +        return rv;
> >> +    }
> >> +
> >> +    if ((rv = check_filter_process_on_eos(ctx, r)) != APR_SUCCESS) {
> >> +        return rv;
> >
> > Not correct here for a filter.
>
> I am a little bit confused. Provided that your comments on the 
> check_filter_process_on_eos are considered and the code is changed
> accordingly, why would it be incorrect for the  filter to return this?

Sorry for not being clear. I meant *if the code is not changed* that's
where a/some/this filter returns an HTTP_ error code instead of an
apr_status_t, which may confuse any upper filter or logger (not the
end of the world though, it should hardly be considered something
recoverable).

>
> >
> >>      }
> >>
> >>      if ((rv = ap_pass_brigade(f->next, bb)) != APR_SUCCESS) {
> >> @@ -939,7 +978,13 @@ static apr_status_t ef_input_filter(ap_f
> >>      }
> >>
> >>      rv = ef_unified_filter(f, bb);
> >> -    return rv;
> >> +    if (rv != APR_SUCCESS) {
> >> +        ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f->r, APLOGNO(10454)
> >> +                      "ef_unified_filter() failed");
> >> +        return rv;
> >
> > Ditto, for both the error log status and return value.
>
> Same confusion as above: While ef_unified_filter formally returns an int it 
> looks like its content is actually an apr_status_t.
> Hence why shouldn't it be used in the log message or returned?

Oh I misread ef_unified_filter() as ef_output_filter() and thought the
error was propagating here too.
That's not the case, though now that I look at it in the code (rather
than the diff only..) it probably makes sense for ef_unified_filter()
to declare an apr_status_t as returned type (which FWICT it actually
always returns, as you said).

>
> >
> >> +    }
> >> +
> >> +    return check_filter_process_on_eos(ctx, f->r);
> >>  }
> >

Regards;
Yann.

Reply via email to