Return-Path: Delivered-To: apmail-httpd-modules-dev-archive@locus.apache.org Received: (qmail 71507 invoked from network); 28 Aug 2007 17:06:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Aug 2007 17:06:29 -0000 Received: (qmail 14010 invoked by uid 500); 28 Aug 2007 17:06:24 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 13716 invoked by uid 500); 28 Aug 2007 17:06:23 -0000 Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: modules-dev@httpd.apache.org Delivered-To: mailing list modules-dev@httpd.apache.org Received: (qmail 13707 invoked by uid 99); 28 Aug 2007 17:06:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 10:06:23 -0700 X-ASF-Spam-Status: No, hits=-0.8 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS,TVD_FW_GRAPHIC_NAME_MID X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of cvitale@us.ibm.com designates 32.97.110.152 as permitted sender) Received: from [32.97.110.152] (HELO e34.co.us.ibm.com) (32.97.110.152) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 17:07:10 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7SH5oS5027438 for ; Tue, 28 Aug 2007 13:05:50 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7SH5nJa480512 for ; Tue, 28 Aug 2007 11:05:49 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7SH5n88029163 for ; Tue, 28 Aug 2007 11:05:49 -0600 Received: from d03nm132.boulder.ibm.com (d03nm132.boulder.ibm.com [9.17.195.172]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7SH5nUU029146 for ; Tue, 28 Aug 2007 11:05:49 -0600 In-Reply-To: <20070827153440.078f3089@grimnir> References: <46D2DA15.1030906@artofdefence.com> <20070827153440.078f3089@grimnir> Subject: Re: Howto return apache status (error) page from output filter ? To: modules-dev@httpd.apache.org X-Mailer: Lotus Notes Release 8.0 August 02, 2007 Message-ID: From: Christopher Vitale Date: Tue, 28 Aug 2007 13:05:46 -0400 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 7.0.2FP2HF51 | June 19, 2007) at 08/28/2007 11:05:48 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF9D6DFC5A7518f9e8a93df938690918c0ABBF9D6DFC5A751" X-Virus-Checked: Checked by ClamAV on apache.org --0__=0ABBF9D6DFC5A7518f9e8a93df938690918c0ABBF9D6DFC5A751 Content-type: multipart/alternative; Boundary="1__=0ABBF9D6DFC5A7518f9e8a93df938690918c0ABBF9D6DFC5A751" --1__=0ABBF9D6DFC5A7518f9e8a93df938690918c0ABBF9D6DFC5A751 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hello, I've got some questions about Nick's comments on filters and errors. I understand why setting an error status on an output filter is dicey. Wh= at about content input filters? Are handlers required to detect errors in inbound filters, pass them to= Apache, and respect r->status? Is this more of a best practice that some people choose not to follow? Are handlers encouraged to decide for themselves what is correct as handlers can be so varied? When I first started looking at filters I thought that the handlers wou= ld respect inbound filter errors, stop processing, and hand an error code = to Apache. If mod_deflate is given a compressed upload and detects an erro= r then the entire request should be considered to be as dangerous as radioactive waste. Throwing away the bad buckets and proceeding with th= e request shouldn't be an option. In practice, I'm starting to think that handlers do whatever they wish.= This makes things messy because handlers lack uniformity. A hacked uplo= ad would return a 400 error with handler X and a 200 with handler Y. Are there hard and fast rules for real world handlers? vitale = From: Nick Kew = = To: modules-dev@httpd.apache.org = = Date: 08/27/2007 11:37 AM = = Subject: Re: Howto return apache status (error) page from ouptut f= ilter ? = On Mon, 27 Aug 2007 16:05:09 +0200 Holger Moser wrote: > Hi, > > To keep a long storry short: i have an apache module that sets an > ouput-filter (besides other things), does validate/mangle the data. s= o > far so good. my question now is how can i get apache to generate an > errorpage by itself if my module wants it to return with e.g. 404 > errcode (just returning the status code as outputfilter returnvalue > doesnt work.. i tried that because someone mentioned it could work). > currently i generate my own errorpage with the statuscode as > workaround (but this is only a temp solution). so whats the correct > way doing that? A filter is the wrong place to set an error status. Your filter function is a callback, and in general will be called after the response status has already been sent to the client. The exception to that is in the first call to your filter function. But if you're relying on that, it points to a problem in your design. Though in that case, you can still set r->status and return APR_EGENERAL, and hope the content generator (which is in control) does what you want. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/ = --1__=0ABBF9D6DFC5A7518f9e8a93df938690918c0ABBF9D6DFC5A751 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hello,

I've got some questions about Nick's comments on filters and errors. I = understand why setting an error status on an output filter is dicey. Wh= at about content input filters?

Are handlers required to detect errors in inbound filters, pass them to= Apache, and respect r->status?
Is this more of a best practice that some people choose not to follow? =
Are handlers encouraged to decide for themselves what is correct as han= dlers can be so varied?

When I first started looking at filters I thought that the handlers wou= ld respect inbound filter errors, stop processing, and hand an error co= de to Apache. If mod_deflate is given a compressed upload and detects a= n error then the entire request should be considered to be as dangerous= as radioactive waste. Throwing away the bad buckets and proceeding wit= h the request shouldn't be an option.

In practice, I'm starting to think that handlers do whatever they wish.= This makes things messy because handlers lack uniformity. A hacked upl= oad would return a 400 error with handler X and a 200 with handler Y.<= br>
Are there hard and fast rules for real world handlers?

vitale


3D"InactiveNick Kew ---08/27/2007 11:37:02 AM---On Mon, 27 Au= g 2007 16:05:09 +0200

=
3D=
From:		= 3D""
Nick Kew <nick@webthing.com>
3D=
To:
modules-dev@httpd.apache.org
3D=
Date:		= 3D""
08/27/2007 11:37 AM
3D=
Subject:		3D""
Re: Howto return apache status (error) page from ouptu= t filter ?




On Mon, 27 Aug 2007 16:05:09 +0200
Holger Moser <holger.moser@artofdefence.com> wrote:

> Hi,
>
> To keep a long storry short: i have an apache module that sets an<= br> > ouput-filter (besides other things), does validate/mangle the data= . so
> far so good. my question now is how can i get apache to generate a= n
> errorpage by itself if my module wants it to return with e.g. 404<= br> > errcode (just returning the status code as outputfilter returnvalu= e
> doesnt work.. i tried that because someone mentioned it could work= ).
> currently i generate my own errorpage with the statuscode as
> workaround (but this is only a temp solution). so whats the correc= t
> way doing that?

A filter is the wrong place to set an error status.  Your filter function is a callback, and in general will be called after the
response status has already been sent to the client.

The exception to that is in the first call to your filter function.
= But if you're relying on that, it points to a problem in your
design.  Though in that case, you can still set r->status and return APR_EGENERAL, and hope the content generator (which is
in control) does what you want.

--
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor= .org/

= --1__=0ABBF9D6DFC5A7518f9e8a93df938690918c0ABBF9D6DFC5A751-- --0__=0ABBF9D6DFC5A7518f9e8a93df938690918c0ABBF9D6DFC5A751--