[erlang-patches] Patch for packet_parser.c to Include HTTP Methods Defined in RFC 2518 / WebDAV

Jan Lehnardt <>
Mon Feb 16 12:46:46 CET 2009

Hi Oscar,

thanks for your comments.

On 16 Feb 2009, at 12:04, Oscar Hellström wrote:
> Firstly, I fail to understand why this is an issue that need to be
> "fixed"? Except the increased size and a few more CPU cycles when
> matching (which should quite small any way) why is it it a problem
> having the methods as strings? Personally I wouldn't mind if *all*
> methods would have been strings since mixing types makes programming a
> bit bloated, but this obviously can't be changed.

I wouldn't mind atoms or strings either, what's weird is that the API
returns both and clients have to deal with whether they use RFC 2616-
defined methods or not. Either asking explicitly for WebDAV methods
using `inet:setopts(Socket, [{packet, webdav}])` or just handling all
known HTTP extension methods as atoms (for backwards compatibility),
"fixes" that.

The reasoning behind the patch is less code (less code is good), not

> Anyway, for the legacy discussion. Looking at the yaws code, your
> assumption seems wrong. In handle_extension_method/4 the code assumes
> that the extension method is a string, at least in the rather old
> version that I looked at. It would certainly be possible to add clause
> before the last one such as:
> handle_extension_method(Method, CliSock, Req, Head) when  
> is_atom(Methed) ->
>    handle_extension_method(atom_to_list(Method), CliSock, Req, Head);
> but without this, it looks to me as if yaws would fail.

My version of `handle_extension_method()` reads:

handle_extension_method("PROPFIND", CliSock, Req, Head) ->
     'PROPFIND'(CliSock, Req, Head);
handle_extension_method("MKCOL", CliSock, Req, Head) ->
     'MKCOL'(CliSock, Req, Head);
handle_extension_method("MOVE", CliSock, Req, Head) ->
     'MOVE'(CliSock, Req, Head);
handle_extension_method("COPY", CliSock, Req, Head) ->
     'COPY'(CliSock, Req, Head);
handle_extension_method(_Method, CliSock, Req, Head) ->
     not_implemented(CliSock, Req, Head).

It gets called from:

call_method(Method, CliSock, Req, H) ->
     case Method of
         F when atom(F) ->
             ?MODULE:F(CliSock, Req, H);
         L when list(L) ->
             handle_extension_method(L, CliSock, Req, H)

I.e. "METHOD" is routed through `handle_extension_method()`
to call `'METHOD'()` in `call_method()` while 'METHOD' directly
calls `'METHOD'()`.

Again, Yaws 1.79.

So earlier versions of YAWS break.

> Jan Lehnardt wrote:
>> On 14 Feb 2009, at 14:17, Jan Lehnardt wrote:
>>> Good point. I'm not aware of any Erlang WebDAV server
>>> but I do not constantly monitor the application space and
>>> I'm relatively new to Erlang (2 years now). I certainly have
>>> no idea about internal applications that use the WebDAV
>>> protocol or use any other non-standard HTTP extensions.
>> A little more digging.
>> YAWS has a WevDAV extension and it uses this code to
>> solve the issue:
>> call_method(Method, CliSock, Req, H) ->
>>     case Method of
>>         F when atom(F) ->
>>             ?MODULE:F(CliSock, Req, H);
>>         L when list(L) ->
>>             handle_extension_method(L, CliSock, Req, H)
>>     end.
>> (YAWS 1.79 source src/yaws_server.erl line 1155 ff.)
>> YAWS hence, wouldn't break. Maybe because Klacke
>> was smart enough to foresee that this is getting fixed
>> eventually :)
>> --
>> Erlware includes a WebDAV module and as far as I
>> understand*, it does its own http parsing and always
>> uses lists / strings, not atoms for methods.
>> * http://git.erlware.org/web?p=crary_dav.git;a=blob_plain;f=crary_dav/src/crary_dav.erl;hb=HEAD
>>  and
>> http://git.erlware.org/web?p=crary.git;a=blob_plain;f=src/crary_sock.erl;hb=HEAD
>> Cheers,
>> Jan
>> --
>> _______________________________________________
>> erlang-patches mailing list
>> http://www.erlang.org/mailman/listinfo/erlang-patches
> -- 
> Oscar Hellström, 
> Office: +44 20 7655 0337
> Mobile: +44 798 45 44 773
> Erlang Training and Consulting
> http://www.erlang-consulting.com/

More information about the erlang-patches mailing list