Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: [PATCH] trunk/2.4 core output filter is broken
Date: Fri, 3 Feb 2012 20:13:48 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <20120120165210.GA23839@redhat.com>
 <201201292053.09488.sf@sfritsch.de> <20120202155817.GA9636@redhat.com>
In-Reply-To: <20120202155817.GA9636@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201202032013.49060.sf@sfritsch.de>

On Thursday 02 February 2012, Joe Orton wrote:
> The combination of APR_SUCCESS and DECLINED is unusual; an int
> return  value with OK/DECLINED?

Input and output filters should return an apr_status_t. So, if the 
hook does not return an apr_status_t, core_input_filter() would have 
to invent some apr_status_t value, which is bad. And I think the 
general principle that return code 'int' means HTTP_* error code 
should be kept.

But I agree that DECLINED == -1 is not a good idea, because it could 
in theory collide with another APR_E* code. Should we define an 
AP_STATUS_DECLINED or something in the APR_OS_START_USERERR range?
Or simply change the definition of DECLINED to be in the 
APR_OS_START_USERERR range? APR_OS_START_USERERR is 120000, so there 
should be no danger of a collision with HTTP_*. It would require a 
major MMN bump, but making core_output_filter_ctx_t and core_ctx_t 
private is an API change, anyway.