From: Sean H. <Sea...@t-...> - 2003-08-10 21:01:08
|
Hi, > I have been looking at the code related to partial_post_size, because > I wanted to make my CGI code make work with (which it doesn't at the > moment). This would indeed be useful, as there is no reason to buffer > the entire post data, which will be interpreted by the CGI script. I > would like to have some issues resolved first, however. > > It seems that the current code assumes that partial posts will only > happen for file uploads, ie multipart/form-data. The content type of > a post and it being large should be considered independent properties. Agreed. I wrote it like that because that was my need at the time. Please go ahead and make this more generic if you have the need. > > Also the interaction of the server code and the code implementing the > dynamic file by repeatedly calling the dynamic code with different > arguments seems quite un-Erlang-ish to me, if this is of any > importance. Two other approaches come to my mind: > > * Have the dynamic code spawn a process that communicates with the > server process similarly to the stream content handling. > > * Have the dynamic code return {get_more, Cont} where Cont is a real > continuation, that is then called by the server code with the next > chunk of data as the argument. The reason for the current implementation is that this is the way the re-entrant multipart parser holds state. Works for me! > > Independently of this, an api function to wrap partial post unaware > dynamic code would be beneficial, such that > > <erl> > out(A) -> > % code that does not know about partial posts, possibly calling > % parse_post or using the raw A#arg.clidata > </erl> > > could be easily replaced by > > <erl> > > out(A) -> > yaws_api:call_with_entire_post_data(A, fun out_old/1). > > out_old(A) -> > % code that does not know about partial posts, possibly calling > % parse_post or using the raw A#arg.clidata > </erl> > > One could also think of always calling out/1 with the entire post > data, but calling out_partial if it exists. I fear that setting > partial_post_size to a value different from nolimit might break a lot > of existing code, especially if the value is small. Just think of > large text fields. Yes, this will cause problems. The intent of partial post size is to stop *massive* uploads blowing up the emulator/machine. Most web servers allow you to specify a max post size for self preservation and just fail the request if it is exceeded - maybe it is not of such use to genericise partial post size to normal POSTs? Hmmm Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. |
From: Carsten S. <ca...@gn...> - 2003-08-11 18:34:01
|
I seem to be too stupid to hit `L' instead of `r', ie reply to the list. I am therefore attaching the message I wanted to send before. In the meantime I have made yaws_cgi work with partial_post_size set. It seems I had not fully understood Sean's code when sending the initial message. Greetings, Carsten -- Carsten Schultz (2:40, 33:47), FB Mathematik, FU Berlin http://carsten.fu-mathe-team.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. |