httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 54946] New: Missing Reason-Phrase in HTTP response header for *standard* 3-digit status codes
Date Thu, 09 May 2013 19:13:47 GMT

            Bug ID: 54946
           Summary: Missing Reason-Phrase in HTTP response header for
                    *standard* 3-digit status codes
           Product: Apache httpd-2
           Version: 2.2.24
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Core
    Classification: Unclassified

We moved from Apache 2.2.22 to 2.2.24 and found a change in behavior that is
breaking our embedded non-changeable clients. This behavior is changed in 2.2.4
and on the HEAD also.

Previously, when we used Apache 2.2.22 and Phusion Passenger 3.0.14 with a
Rails/Sinatra app that returned any 3-digit status code like 200, we would get
a http status-line pulled from a standard table like:


Now, in Apache 2.2.24 we are getting:


We tracked this down into a change made for apache bug 44995 that caused this
new behavior. The bug was a fix to handle custom status codes, but it also
ended up breaking standard codes such that it no longer returned standard
reason-phrase enhanced responses.

I realize that the RFC2616 specification allows for the HTTP/1.1<sp>200<sp>
response, but our client is not changeable and crashes on receiving no

The code in question is in http_filters.c method validate_status_line(r).

Previously in 2.2.22 it did:

if (  len <= 4 ) ... r->status_line = NULL

and then in http_filters.c method basic_http_header_check(r,protocol) it would:

if ( !r->status_line) {
  r->status_line = ap_get_status_line(r->status);

which would effectively convert the 3-digit status code into a full status line
complete with matching reason-phrase. I think the intention for the code is
that if you have a 3-digit status code that it would look up in
ap_get_status_line to find a standard reason-phrase

The new code in 2.2.24 in http_filters.c method validate_status_line(r) does:

if ( len < 3 ... ) {
} else if ( len == 3 ) {
  r->status_line = apr_pstrcat(r->pool, r->status_line, " ", NULL);

which appends the space at the end. The http_filters.c call to
ap_get_status_line therefore never gets triggered and the standard 3-digit code
does not get the full matching reason-phrase. Notice that previously if the
status code was 4 or less in length, and valid, it would NULL it out, but now
it adds the space instead for *all* codes standard or custom.

I don't think the intention of the bug fix in 44995 was to affect the behavior
for standard status code, but only change the behavior for custom status codes.

We made a simple change to the new code to check for len <= 4 and it started
working again, so this is definitely the cause of the new behavior. But this of
course, reverted the enhancement in 44995

A fix for this, then, would be to change the logic to something like this:

- If it's a 3-digit status code (NNN)
   - If it's known (i.e. has a valid response from ap_get_status_line) then use
the valid response.
   - If it's unknown (i.e. has an invalid response from ap_get_status_line)
then set status line to (NNN<sp>)
- If it's a 4-digit status code (NNN<sp>) already, then filter did not intend
for there to be a reason phrase, so use that as the status_line
- The other logic would remain the same for nulling it out if it is improperly
formed and returning 500 if the code can't figure out what to do with it.

This would cause non-standard responses to return NNN<sp> and standard status
codes to be converted to their standard reason phrase.

To test this you can use jsp:
or a rails controller action:
  def standard_response
    render :nothing => true, :status => 200
or a sinatra action:
  get '/standard_response' do

Please let me know if you need any help seeing this problem, or understanding
it. It is not allowing us to move to the latest secure apache without breaking
our clients.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message