[erlang-patches] Patch for packet_parser.c to Include HTTP Methods Defined in RFC 2518 / WebDAV
Jan Lehnardt
jan@REDACTED
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
speed.
> 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)
end.
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.
Cheers
Jan
--
>
>
> 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
>> erlang-patches@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-patches
>>
>
>
> --
> Oscar Hellström, oscar@REDACTED
> 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