Bug 60706

Summary: Undefined behavior in http_protocol::ap_method_name_of
Product: Apache httpd-2 Reporter: mustangcoupe69
Component: CoreAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: NEW ---    
Severity: normal CC: mike, szg0000
Priority: P2    
Version: 2.4.25   
Target Milestone: ---   
Hardware: All   
OS: All   

Description mustangcoupe69 2017-02-08 00:08:49 UTC
We are using a module that makes use of http_protocol::ap_method_name_of.  The behavior seems to have changed and it returns HEAD or GET rather than the expected GET.  Restarting httpd randomly changes which method is returned for the duration of the runtime.  This commit shows a change between 2.4.25 and 2.4.23 and seems potentially accounts for the behavior.  https://github.com/apache/httpd/commit/2ba0ab8759920e11ecff5f2e04d7f019437a91c7#diff-e7207107d352028110203509bdfd8130
Comment 1 Eric Covener 2017-02-08 01:48:20 UTC
A little more info about the original change in the backport:

-  *) mod_http: Add the HEAD method to the lookup hash for completeness.
-      Trunk version of patch:
-         http://svn.apache.org/r1753257
-      Backport version for 2.4.x of patch:
-         Trunk version of patch works
-      +1: wrowe, ylavic, sf

 * Get the method name associated with the given internal method
 * number.  Returns NULL if not recognized.
 * @param p A pool to use for temporary allocations.
 * @param methnum An integer value corresponding to an internal method number
 * @return The name corresponding to the method number
AP_DECLARE(const char *) ap_method_name_of(apr_pool_t *p, int methnum);

Revert or special case the reverse lookup of M_GET?
Comment 2 Ruediger Pluem 2017-02-08 08:24:05 UTC
(In reply to Eric Covener from comment #1)

> Revert or special case the reverse lookup of M_GET?

I guess we need a special case (no idea how to do it) as otherwise HTTPProtocolOptions registeredmethods becomes broken. Or we revert and fix HTTPProtocolOptions registeredmethods by other means for HEAD requests.
Comment 3 Mike Lothian 2017-09-11 23:47:50 UTC
*** Bug 61501 has been marked as a duplicate of this bug. ***