Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Fri, 17 Feb 2006 16:19:49 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@httpd.apache.org
Subject: Re: filters that change r->status[_line]
Message-ID: <20060217161949.GB21071@redhat.com>
Mail-Followup-To: dev@httpd.apache.org
References: <cc67648e0602170803v5b7b82c5t5801d7e5d677b1ba@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <cc67648e0602170803v5b7b82c5t5801d7e5d677b1ba@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i

On Fri, Feb 17, 2006 at 11:03:54AM -0500, Jeff Trawick wrote:
> On 2/16/06, Jeff Trawick <trawick@gmail.com> wrote:
...
> > The range support right now isn't smart enough to clear r->status_line
> > when it sets a new status code (206, 416).  That needs to be fixed to
> > avoid breaking range requests for modules which set r->status_line
> > even for non-error responses.

I'm not sure I understand this.  The range filter would only confuse 
things if some module set r->status_line but *not* r->status, right?  
(because the range filter only takes effect if r->status == 200).

But that would be a rather odd thing for a module to do, surely, or am I 
missing the point?

> *Any filter* that modifies r->status should clear (or set) r->status_line.
>
> Apache could do something to remove the requirement...
> 
> * if Apache has built-in support for r->status, use apache status line
> ("200 OK")
> * elsif r->status_line is set, use that ("200 GOODYGOODY")
> * else use 500 status line

That seems reasonable to me.

> (If the filter changed r->status to a code with no built-in support,
> the filter had to set r->status_line ANYWAY)
> 
> No idea here what depends on modules being able to override Apache's
> status lines...

PHP exposes this at least, and suffered from the same problem with an 
"unknown" r->status requiring r->status_line to be set (though this was 
fixed PHP side).

joe