On Oct 2, 2006, at 3:24 AM, [EMAIL PROTECTED] wrote:
If the r->method_number is unknown the r->method
is unknown or corrupted as well. Log the method number
that was not recognized.
I can't tell from this snippet whether you are talking about the
HTTP method received or some bit of marshalled AJP.
If it is an unknown HTTP method, then the real data is in r->method
and the method number is irrelevant to the log message aside from
being a more efficient comparison (in that case, -1 to the commit).
If it is some bit of AJP, then the log message should say what bit
of AJP is wrong in the AJP message -- i.e., the current message is
still ambiguous.
In the long term, this section of code prevents a Java servlet from
handling new methods, which itself is a violation of HTTP's design.
However, that may be a constraint inherent within the servlet spec.
AJP should have a mechanism for extension methods. OTOH, that is
more of a long term consideration, and I expect AJP (and servlets)
to be replaced before it is fixed.
....Roy
Modified:
httpd/httpd/trunk/modules/proxy/ajp_header.c
Modified: httpd/httpd/trunk/modules/proxy/ajp_header.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/
ajp_header.c?view=diff&rev=451951&r1=451950&r2=451951
======================================================================
========
--- httpd/httpd/trunk/modules/proxy/ajp_header.c (original)
+++ httpd/httpd/trunk/modules/proxy/ajp_header.c Mon Oct 2
03:24:45 2006
@@ -220,8 +220,8 @@
if ((method = sc_for_req_method_by_id(r->method_number)) ==
UNKNOWN_METHOD) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
- "ajp_marshal_into_msgb - No such method %s",
- r->method);
+ "ajp_marshal_into_msgb - No such method number %s",
+ r->method_number);
return AJP_EBAD_METHOD;
}
