Bug 44995 - Custom HTTP-Error codes get remapped to 500er codes
Summary: Custom HTTP-Error codes get remapped to 500er codes
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Other Modules (show other bugs)
Version: 2.2.8
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk, PatchAvailable
Depends on:
Blocks:
 
Reported: 2008-05-14 00:37 UTC by Jan Schulte
Modified: 2014-02-17 13:56 UTC (History)
1 user (show)



Attachments
Make httpd tolerate empty reason phrases in status line (1.04 KB, patch)
2008-05-27 12:12 UTC, Rainer Jung
Details | Diff
Make httpd tolerate more status lines in combination with error pages (1.91 KB, patch)
2008-05-27 12:17 UTC, Rainer Jung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Schulte 2008-05-14 00:37:27 UTC
We use Apache 2.2.8 with mod_JK 1.2.26 with a Tomcat 5.5 cluster.
We use Custom HTTP-Error codes like 450 for authentication-purposes. Those codes get remapped to 500.
The Error-Code 450 is in the RFC2616 described as valid return code so this is a bug.

The custom error-codes worked fine in Apache 1.3.41 with MOD_JK/1.2.25.


You can easily reproduce this bug by writing a jsp-page with the following line:
<%response.setStatus(450);%>
Comment 1 Nick Kew 2008-05-14 01:46:39 UTC
Whatever this is, it's not a bug in the Apache core, since other generators (e.g. CGI, asis) can send a 450 response just fine, and mod_proxy will happily relay it from a backend.

That leaves mod_proxy_ajp or mod_jk as possible culprits, but I'd suspect it's more likely your backend.  Please reopen if and when you can identify an Apache component being at fault here.
Comment 2 Jan Schulte 2008-05-14 02:14:12 UTC
It's quite clear that this is not an environmental issue as we have seen this behaviour in different installations. So it seems that mod_JK is the faulty component.

Comment 3 Nick Kew 2008-05-15 10:06:30 UTC
mod_jk is a tomcat component.  We (httpd) don't maintain it, so if there is a bug, it won't get noticed or fixed here.
Comment 4 Jan Schulte 2008-05-19 02:54:17 UTC
Couldn't the below listed function from http_protocol.c the probem?
With defines 
#define LEVEL_400   19  
#define LEVEL_500   44
#define  RESPONSE_CODES  55   

I can't see how an valid index for 450 could be returned with this function



/* The index is found by its offset from the x00 code of each level.
 * Although this is fast, it will need to be replaced if some nutcase
 * decides to define a high-numbered code before the lower numbers.
 * If that sad event occurs, replace the code below with a linear search
 * from status_lines[shortcut[i]] to status_lines[shortcut[i+1]-1];
 */
AP_DECLARE(int) ap_index_of_response(int status)
{
    static int shortcut[6] = {0, LEVEL_200, LEVEL_300, LEVEL_400,
    LEVEL_500, RESPONSE_CODES};
    int i, pos;

    if (status < 100) {               /* Below 100 is illegal for HTTP
status */
        return LEVEL_500;
    }

    for (i = 0; i < 5; i++) {
        status -= 100;
        if (status < 100) {
            pos = (status + shortcut[i]);
            if (pos < shortcut[i + 1]) {
                return pos;
            }
            else {
                return LEVEL_500;            /* status unknown (falls in
gap) */
            }
        }
    }
    return LEVEL_500;                         /* 600 or above is also
illegal */
}

Comment 5 Rainer Jung 2008-05-24 09:10:33 UTC
There is a discussion on httpd-dev about this problem. See

http://marc.info/?t=121128830700002&r=1&w=2

and the related entry BZ 45026

https://issues.apache.org/bugzilla/show_bug.cgi?id=45026

The analysis is done. The custom status code leads to an empty reason phrase (e.g. the status line is of the form "NNN " and no textual message behind the trailing space. This is legal per RFC 2616, but leads to a replacement with status code 500 inside httpd.

There are three places, where we could fix the problematic status line:

1) Tomcat sending "NNN NNN" instead of "NNN " (likely to happen)
2) mod_jk fixing "NNN " to "NNN NNN" (likely to happen)
3) httpd either allowing "NNN " or alternatively also rewriting it to "NNN NNN".

This is under discussion, so I'm reopening the bug as a reminder.

All three options above make sense together, in order to fix the problem whenever at least one of the three components is recent enough.
Comment 6 Rainer Jung 2008-05-27 12:12:21 UTC
Created attachment 22018 [details]
Make httpd tolerate empty reason phrases in status line

This patch changes the validity check for the httpd status line in the following ways:

- Allow empty reason phrase
- Allow status line of the form "NNN" but add mandatory trailing space
- replace comparison for ' ' with apr_isspace for better consistency with second part of the patch
Comment 7 Rainer Jung 2008-05-27 12:17:35 UTC
Created attachment 22019 [details]
Make httpd tolerate more status lines in combination with error pages

This patch changes the rules whether to include the status line in the error page response in the following ways:

- Allow empty reason phrase, but add "Unknown Reason" in this case
- Allow status line of the form "NNN" but add mandatory trailing space and "Unknown Reason"
- replace previous check if first 3 chars in status line are numeric with the test for the correct status int used in http_filters.c

Both patches are not yet thoroughly tested. If the point into the right direction, I'll test.
Comment 8 Nick Kew 2008-09-08 07:21:16 UTC
Patches committed to trunk, r693108
Comment 9 Nick Kew 2009-12-26 12:05:00 UTC
Fixed in trunk long ago, but I don't feel motivated to propose for backport just in case anything breaks.  Will come for free in 2.3/2.4, so I guess that counts as LATER.

Also it's only an enhancement, since it's just error-tolerance.