Re: filters that change r->status[_line]

[Jeff Trawick <tr...@gmail.com>]

(editing subject line slightly)

On 2/16/06, Jeff Trawick <tr...@gmail.com> wrote:
> (perhaps tell me where I go wrong here with the way it is supposed to work)
>
> A module that wants to use an HTTP response code which has no built-in
> support in Apache needs to set r->status AND r->status_line.
> Otherwise, Apache will return 500 to the client.
>
> A module that proxys to some other HTTP application which can return
> arbitrary HTTP response codes can set r->status and r->status_line
> with whatever the other application returned, to avoid situations
> where Apache will return 500 to the client instead of the unsupported
> HTTP response code.  It shouldn't have to look at the exact status
> code before deciding whether to set r->status and r->status_line.
>
> The Range support in Apache >= 2 can handle arbitrary sources for the
> response due to its implementation as a filter.  If the request was
> for a range and the handler didn't implement that aspect of the
> request, the byterange filter will process the non-error response and
> report status to the client as appropriate (e.g., set 206).
>
> 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.

*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

(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...

Thoughts?

Re: filters that change r->status[_line]

[Jeff Trawick <tr...@gmail.com>]

On 2/17/06, Joe Orton <jo...@redhat.com> wrote:
> On Fri, Feb 17, 2006 at 11:03:54AM -0500, Jeff Trawick wrote:
> > On 2/16/06, Jeff Trawick <tr...@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?

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

Re: filters that change r->status[_line]

[Joe Orton <jo...@redhat.com>]

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