On Fri, Feb 17, 2006 at 11:03:54AM -0500, Jeff Trawick wrote:
> On 2/16/06, Jeff Trawick <[EMAIL PROTECTED]> 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
