Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Mon, 19 Mar 2007 14:58:19 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@httpd.apache.org, docs@httpd.apache.org
Subject: Re: [RFC] Guide to writing output filters
Message-ID: <20070319145819.GB3237@redhat.com>
Mail-Followup-To: dev@httpd.apache.org, docs@httpd.apache.org
References: <20070316225521.GA8447@redhat.com>
 <cc67648e0703170444o16a9e8akbbf8cdf0d0f6ce81@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <cc67648e0703170444o16a9e8akbbf8cdf0d0f6ce81@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i

Again, thanks for the review! 

On Sat, Mar 17, 2007 at 07:44:02AM -0400, Jeff Trawick wrote:
> I guess I'm confused about the up/down direction convention for output
> filters?  I thought passing the next output filter is "down" and
> returning to the prior input filter is "up"?

My confusion - I always think about filters in terms of the call stack, 
where ap_pass_brigade passes brigades "up" the stack.

> More detail about error handling would be invaluable.  Something that
> has been a thorn in the past has been the two types of status and
> understanding the limited relationship:
> 
> apr_status_t as returned by a filter
> HTTP status as returned by a handler
> 
> What can a filter do to influence HTTP status (set r->status on first
> invocation for a response?)?  What will be logged if a filter returns
> non-APR_SUCCESS?

Excellent questions for which I lack excellent answers :)

Also: is it better to use the elusive HTTP error bucket rather than 
setting r->status?  What should filters do with apr_bucket_read() 
errors?  Must filters _cleanup() the brigade before returning an error?  
(there is a bug in bugzilla caused by that one IIRC)

joe