--- "Sherlock, Ric" <[EMAIL PROTECTED]> wrote: > > [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko > > Please make sure that the current JHP code does not have > > anything missing from functionality that was in your code > > (except temp files). > I need to spend a bit more time studying exactly what is happening in > your code, but so far except for the filename storage decision discussed > below, I haven't noticed anything. > > > (One design decision: if method is not multipart, the file > > name is passed as the parameter value. In current JHP, file > > name is in qparamFile and content is in qparam. Should this > > be swapped for consistency? > > However, qparamFile is a good way to test if it's a file, > > whereas content may theoretically be zero--one rationale for > > keeping name in qparamFile.) > Yes that's a tough one. To enable consistent handling between the > methods, I think you'd have to add another boolean vector to signal if > it's a file, and I'm not sure it's worth it. On the other hand adding > the extra noun would make it more immediately obvious to users on how to > test for file existence?
I think I met it in one recent DSLs (D=Domain) that it's good to have a single point of change: if there is no file name, there is no file--that's the rationale behind testing 0<#qparamFile key instead of qparamFileExists key and I think it's less stressful not to worry about sync'ing another pair of variables. With current implementation, this workds perfectly. However, if app dev accidentally does not indicate "multipart", the file name will arrive in qparam instead. Whereas 0=#qparamFile key. A little inconsistency, but maybe it is for the better, because a <intput type=file > should not be used outside of "multipart". In other words, a file is really a file only if 0<#qparamFile key, in which case "qparam key" contains (reference to) its contents. Note: even should files be cached on disk, qparam could still re-read and return their contents. (Alternatively, when a config flag is set qparam will return the temp file path.) > The other thing I'm debating, is whether consolidating keys with the > same name into a vector should be left to the user if desired or be > handled by JHP. This would add an additional level of boxing to CGIVALS, > but given the array nature of J, I'm leaning towards JHP handling it. > This would mean for instance that a set of checkboxes or radio buttons > would be automatically become one entry in CGIKEYS and a vector in > CGIVALS. Something along the lines of: > CGIKEYS=: ~.CGIKEYS > CGIVALS=: CGIKEYS </. CGIVALS This is a good point. It is address under HTTP Parameters in http://www.jsoftware.com/jwiki/CGI/Design In other words, the "qparam key" will return the first value, where as a number of additional accessors will take care of arrays of grouped parameters: qparamList key - for same names; qparamPrefix prefix - for cluster of parameters with the same prefix (good for representing isolated entities on the same page, like DB records, paging/sorting, etc.) The goal of this and other API designs is to isolate the user from the global nouns and instead provide accessor verbs, which have the advantage of representing different views of the same underlying state. > > The very lastest JHP update contains a fix for stdin_w32 and > > an upload limit of 1Mb in the examples script. I discovered a > > funny thing in IIS stdin for CGI: it requires reading the > > stdin through, even if you decide it is exceeding the limit > > and you show error, or it will drop connection. > > Currently it is not addressed, I was not able to confirm by > > googling how to address that, except reading it through > > without storing (copy null, basically). > > No such problem for Unix, but it was only tested with 2-3Mb. > > > I wasn't clear from above whether the current implementation of JHP uses > the copy null idea if stdin exceeds the limit or whether there is no > handling of it at all currently. I'm picking the latter but can you > confirm? Correct, there is no support for handling refusal to read stdin under Windows right now (on Unix it works fine). There are a number of way to address this: copy null, or finding another workaround like may be closing stdin, etc. But it doesn't look right that is has to be done for Windows specifically. So it makes sense for all platforms to provide a boolean verb checkRequestLimit size which will merely do comparison on Unix, and will also clean-up stdin on Windows. It can be used in assert. No parameters will be availble. A more sophisticated approach would be to try to read stdin up to the specified limit and salvage parameters, but it won't work for Unix and those partial parameters may not have much sense. This is a reason why the best handled solution is functionally equivalent to current letting the server blow up with a warning on the previous screen "If you experince problem uploading, make sure your file does not exceed X Mb". ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
