Jeff Trawick wrote:
On Tue, May 27, 2008 at 3:29 PM, Rainer Jung <[EMAIL PROTECTED]> wrote:
Jeff Trawick schrieb:
On Tue, May 20, 2008 at 3:27 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
On 05/20/2008 08:52 PM, Jeff Trawick wrote:
Do we really need to require the space in the case that the reason phrase
is
empty?
No... Both sets of code should be changed to consider the space
optional. We just need to make sure we generate the space in our
response so some other software doesn't have to be so generous.
I attached two patches against trunk to BZ 44995, one for the status_line
validation in http_filters.c and one for the test when used in error pages
in http_protocol.c. Backports should be straighforward, because the code
didn't change locally.
I didn't yet test thoroughly, but if you like them in principle I'll go
through it.
re: https://issues.apache.org/bugzilla/attachment.cgi?id=22019
I don't think r->status_line should be updated by this function
(ap_send_error_response()).
OK, so there are two cases which need clarification w.r.t.
ap_send_error_response() in http_protocol.c:
1) status_line ="NNN" 3 digit status code without trailing space
This would be non-conforming to RFC 2616. We correct it in
validate_status_line() in http_filters.c but I neither know, if there is
an order between ap_send_error_response() and validate_status_line(),
nor if the status line could change in between. If we use the old
behaviour, we simply switch to the standard 500 status line if we detect
"NNN" in ap_send_error_response().
Anyone knowing more about the order of processing between
ap_send_error_response() and validate_status_line() (which is called by
basic_http_header_check(), which in turn is used inside
ap_basic_http_header() and ap_http_header_filter())?
Even if we correct the status_line here (adding a space), we still have
to decide on the second case below.
2) status_line ="NNN " 3 digit status code with trailing space but no
following reason phrase
What should be used as a header in the error page body. Usually we use
everything behind the space, which is an emptry string here. Before the
patch we would switch to the standard status 500, although the status
line was valid. Should we use something like "Unknown Reason" in the
error page headline but keep status_line as is ("NNN ")? In this case I
would also suggest to set the title of the page to "NNN Unknown Reason"
instead of "NNN ".
