(editing subject line slightly)
On 2/16/06, Jeff Trawick <[EMAIL PROTECTED]> 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?
