[erlang-questions] inets mod_get mishandles inaccessible files (Paul Fisher)

Ingela Anderton Andin ingela@REDACTED
Fri May 9 15:45:25 CEST 2008


Hi!

Thank you for pointing this out.
I do however not think that any non-trivial patch will be needed. This 
should do the trick:

--- mod_get.erl@@/inets-5.0.8   2008-02-07 09:57:55.000000000 +0100
+++ mod_get.erl 2008-05-09 15:30:54.000000000 +0200
@@ -52,18 +52,17 @@
     ?DEBUG("do_get -> Request URI: ~p",[Info#mod.request_uri]),
     Path = mod_alias:path(Info#mod.data, Info#mod.config_db,
                          Info#mod.request_uri),
-    {FileInfo, LastModified} = get_modification_date(Path),
-
-    send_response(Info#mod.socket,Info#mod.socket_type, Path, Info,
-                 FileInfo, LastModified).
+
+    send_response(Info#mod.socket,Info#mod.socket_type, Path, Info).


 %% The common case when no range is specified
-send_response(_Socket, _SocketType, Path, Info, FileInfo, LastModified)->
+send_response(_Socket, _SocketType, Path, Info)->
     %% Send the file!
     %% Find the modification date of the file
     case file:open(Path,[raw,binary]) of
        {ok, FileDescriptor} ->
+           {FileInfo, LastModified} = get_modification_date(Path),
            ?DEBUG("do_get -> FileDescriptor: ~p",[FileDescriptor]),
            Suffix = httpd_util:suffix(Path),
            MimeType = httpd_util:lookup_mime_default(Info#mod.config_db,

>
> When the inets httpd mod_get processes a request for a non-existent file
> the connection is closed without a response.  I would expect it to
> return a 404 instead.  Here is what comes out in the error_log:
>
> [08/May/2008:21:47:08 -0500], traverse exit from apply: mod_get:do => 
> {{badmatch,{error,enoent}},
>  [{mod_get,get_modification_date,1},
>   {mod_get,do_get,1},
>   {httpd_response,traverse_modules,2},
>   {httpd_response,generate_and_send_response,1},
>   {httpd_request_handler,handle_response,1},
>   {gen_server,handle_msg,5},
>   {proc_lib,init_p,5}]}
>
> ?Apparently mod_get:do_get/1 (and associated functions) is not prepared
> to get {error, enoent} back from mod_alias:path/3, 
It does not get {error, enoent} from mod_alias:path/3. The badmatch 
occurs in the function
get_modification_date.

get_modification_date(Path)->
    {ok, FileInfo0} = file:read_file_info(Path),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Here was the badmatch

    LastModified =
    case catch httpd_util:rfc1123_date(FileInfo0#file_info.mtime) of
        Date when is_list(Date) -> [{last_modified, Date}];
        _ -> []
    end,
    {FileInfo0, LastModified}.

> and there seems to be
> no provision for generating a 404 response in do_get.  It also looks
> like files/directories with invalid permissions within the document_root
> would also generate the same issue.
>
>   
File errors are handeled by the module httpd_fil:handle_error.
 
[...]
case file:open(Path,[raw,binary]) of
    {ok, FileDescriptor} ->
          [...]
    {error, Reason} ->
        Status = httpd_file:handle_error(Reason, "open", Info, Path),
        {proceed,
         [{status, Status}| Info#mod.data]}

> In the end it appears that a non-trivial patch would be required to
> handle all of the cases and return appropriate responses in all cases.
> Would such a patch be acceptable for integration into a future OTP
> release?
>
> This is with R12B-2.
>
>   
All relevant patches will of course be considered. 

Regards Ingela Erlang/OTP Ericsson






More information about the erlang-questions mailing list