
Has anyone managed to process the results of a "file upload" formular, such as <form action="input_file.htm" enctype="multipart/form-data"> <p>Choose a file: <input name="foobar" type="file" size="50" maxlength="100000" accept="text/*"> </p> </form> ..., with Network.CGI successfully? I have tried it, but it appears that the library can't handle the "multipart/form-data" encoding -- is that possible? I'll appreciate any suggestions how to work around (or fix) this problem. Peter P. S.: I have made a lot of changes to the CGI library already; does anyone actively maintain it? Or should I just post my diffs on the libraries list?

Peter Simons wrote:
Has anyone managed to process the results of a "file upload" formular, such as
<form action="input_file.htm" enctype="multipart/form-data"> <p>Choose a file: <input name="foobar" type="file" size="50" maxlength="100000" accept="text/*"> </p> </form>
..., with Network.CGI successfully? I have tried it, but it appears that the library can't handle the "multipart/form-data" encoding -- is that possible?
Given that most of the CGI library is essentially a decoder for
application/x-www-form-urlencoded data, it isn't much use if you
aren't actually processing such data.
About the only functions in Network.CGI which might be useful for
processing file uploads are getQueryString and getCgiVars, neither of
which are exported.
This seems to be a common problem with Haskell libraries, i.e. define
lots of useful low-level functions, use them to create a high-level
interface (which typically isn't as useful as the author assumes),
then only export the high-level interface.
--
Glynn Clements

Glynn Clements writes:
About the only functions in Network.CGI which might be useful for processing file uploads are getQueryString and getCgiVars, neither of which are exported.
Fortunately, another reader of this list has written the necessary parsers already and sent me a copy of the code via e-mail; so the file-upload problem is solved for now. I've essentially replaced Network.CGI with his code in my application altogether.
This seems to be a common problem with Haskell libraries, i.e. define lots of useful low-level functions, use them to create a high-level interface (which typically isn't as useful as the author assumes), then only export the high-level interface.
Yes, the Network.CGI library is particularly weird in that regard. The 'wrapper' API comes with several rather severe limitations: the hard-coded list of supported 'cgiVarNames', for example. I've also wondered why 'abort' isn't exported, and so on ... Peter
participants (2)
-
Glynn Clements
-
Peter Simons