On 2/17/06, Joe Orton <[EMAIL PROTECTED]> wrote:
> 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?
missing the point due to bad explanation ;)
The range filter would confuse things if a module set
r->status = 200;
r->status_line = "200 OK"
because the range filter could set r->status = 206, leave
r->status_line "200 OK", and so the client would see "200 OK" in the
response since basic_http_header_check() will respect r->status_line
if already set, whether or not it matches r->status.
Now why would the module be stupid enough to set r->status_line if
r->status is 200? Maybe it is a proxy that blindly stores whatever
the origin server returns.
> > *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.
Same here, but wondering whose kludge breaks because they can't see
"200 GOODYGOODY" from their module any more :)
Here's another variation...
if r->status_line is set and leading number matches r->status, use that
elsif Apache has built-in support for r->status, use Apache status line
else use 500 status line
