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);%>
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.
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.
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.
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 */ }
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.
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
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.
Patches committed to trunk, r693108
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.