handle http verbs when erlang:decode_packet/3 returns a string instead o...

...f an atom

Webmachine uses mochiweb to handle the http protocol communication.  When a http request comes in, the code in mochiweb_http:request/3 calls erlang:decode_packet/3 to parse out the method, path, and http version.  When the method is one of "OPTIONS", "GET", "HEAD", "POST", "PUT", "DELETE", or "TRACE",  decode_packet converts it to an atom and returns it to mochiweb which, in turn, returns it to webmachine.  If the http method is not one of the 7 mentioned earlier, decode_packet returns the method as a list (ie. string).

There are 3 places in the webmachine code that rely on the method being an atom and do not handle the case where the method is a list.

In webmachine_logger:format_req/1, the local function fmt_method/1 is used to convert the method from an atom to a list in order to put it into the log message.  The fmt_method/1 function does not deal with the method properly when it is already a list.  I have modified this function to cope with both atoms and lists and moved it into webmachine_util so it can be used in other modules.

In webmachine_perf_logger:format_req/1, the atom_to_list function is used on the method to put it into a log message.  This also will not work when the method is a list.  I have replaced the atom_to_list call with a webmachine_util:fmt_method call.

In wmtrace_resource:encode_request/1, the atom_to_list function is used on the method which doesn't work if the method is already a list.  I have replaced the atom_to_list call with a webmachine_util:fmt_method call.

I discovered these problems when I tried sending a non-standard method to webmachine.  Not only did the logging not work but I was unable to use the trace facility since wmtrace_resource:encode_request/1 couldn't cope with a non-standard method.