unsupported HTTP response codes, r->status[_line], proxies, range requests

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

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