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

[Jan Lehnardt]

On 13 Feb 2009, at 20:08, Sverker Eriksson wrote:

> Jan Lehnardt wrote:
>> [...]
>> CouchDB (and other implementors of HTTP extending standards) would
>> benefit from the inclusion of the methods in RFC 2518. While CouchDB
>> only needs COPY and MOVE (for now), adding the complete suite of
>> additional HTTP methods seems sensible. Please consider the patch
>> for inclusion into the next OTP release.
>>  --- a/erts/emulator/beam/packet_parser.c	2009-02-09  
>> 00:14:24.000000000  +0100
>> +++ b/erts/emulator/beam/packet_parser.c	2009-02-09  
>> 00:12:56.000000000  +0100
>> @@ -139,6 +139,13 @@
>>     "PUT",
>>     "DELETE",
>>     "TRACE",
>> +    "PROPFIND",
>> +    "PROPPATCH",
>> +    "MKCOL",
>> +    "COPY",
>> +    "MOVE",
>> +    "LOCK",
>> +    "UNLOCK",
>>      NULL
>
>
> What do you think about the risk of applications that may break  
> expecting any of these methods as strings and not as atoms?

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.

I found http://code.google.com/p/webdav4erlang/ which
doesn't have any code.

I'd argue that if nobody has stepped up to "fix" this problem,
as it is a relatively simple patch, this hasn't gotten a lot of
attention at all.

An inquiry on erlang-questions@ might be a good idea.

If really needed, it might be worth the time to make the
old or the new code optional. With say,

     inet:setopts(Socket, [{packet, http}]), % http + webdav, this patch
     inet:setopts(Socket, [{packet, http_strict}]), % RFC 2616 only,  
old behaviour

or

     inet:setopts(Socket, [{packet, http}]), % RFC 2616 only, old  
behaviour
     inet:setopts(Socket, [{packet, webdav}]), % RFC 2518, this patch

If at all, I'd go for the first option (the naming of the PacketType
atom is just a suggestion). Legacy  applications (the number
I believe to be in the single digits) can be fixed by either removing
their special handling of the non-standard methods or
using `http_strict`.

The second option is more defensive for legacy applications
and would require us to patch MochiWeb (and hope for acceptance).
I don't know how feasible or not this is.



Cheers
Jan
--