httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: filters that change r->status[_line]
Date Fri, 17 Feb 2006 16:03:54 GMT
(editing subject line slightly)

On 2/16/06, Jeff Trawick <> 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...


View raw message