basho/webmachine — pull request #99 by kimshrier (2012-11-10 07:54:26+00:00)
Title: 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.