Re: [Seaside] Managing Large File Uploads in Seaside
Tom Robinson <[email protected]>
| Newsgroups | gmane.comp.lang.smalltalk.vwnc,gmane.comp.lang.smalltalk.squeak.seaside |
|---|---|
| Message-ID | <[email protected]> |
Hi Karsten, This appears to be a common issue. As such, rather than just using an override, maybe Cincom should be asked for an implementation change that would ALLOW subclasses to customize this without too much code duplication. In my opinion, if an override is needed, in most cases it indicates that more flexibility in the original implementation is needed. Tom On 5/8/2019 11:30 AM, Karsten Kusche wrote: > What do you mean by body size limit? Is that a http thing? > > As for subclassing, the method in question isn’t written in a way that > would allow subclasses to customize something without copying too much > code. In that case an override is better, because there’s tool support > to find overrides and inspect them upon migration. > > Karsten > > > > > Am 8. Mai 2019 um 19:23:15 MESZ schrieb Esteban Maringolo > <[email protected]>: >> Hi Karsten, >> >> I didn't think about an override and went subclassing directly (I'm >> not keen/not used to method overrides), but your approach of having a >> threshold seems like a good tradeoff to preserve the simplicity for >> small files. >> >> What I couldn't find is whether the maximum request body size is >> enforced with Seaside (I placed a few breakpoints around senders of >> #requestBodyLimit without any luck). >> >> Regards, >> >> Esteban A. Maringolo >> >> >> On Wed, May 8, 2019 at 1:59 PM Karsten Kusche <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi Esteban, >>> >>> we have an override in SeasideResponder>>asSeasideFileStream: where >>> we do something differently in „stream isExternalStream ifTrue:[…]“ >>> >>> There we ask the stream for #fileName (returns a Filename object) >>> and test the file size. That’s the file that contains the data that >>> was uploaded. If the file’s size exceeds a certain threshold we >>> return a subclass of WAFile that knows the file and not its contents. >>> >>> Kind Regards >>> Karsten >>> >>> Georg Heeg eK >>> >>> Wallstraße 22 >>> >>> 06366 Köthen >>> >>> >>> >>> Tel.: 03496/214328 >>> >>> FAX: 03496/214712 >>> >>> Amtsgericht Dortmund HRA 12812 >>> >>> Am 8. Mai 2019 um 16:29:29, Esteban Maringolo ([email protected] >>> <mailto:[email protected]>) schrieb: >>> >>>> I found that SiouX is effectively uploading the contents to an >>>> attachment file directory. >>>> >>>> Maybe there is a way to avoid instantiating a WAFile and use a >>>> WAExternalFile poiting to the file on disk, or simply using my >>>> custom SeasideResponder subclass. >>>> >>>> This won't save VW from reading the whole file into memory before >>>> saving it to disk (or will it?) but it certainly will only keep the >>>> reference during the request/response of SiouX, which will be >>>> garbage collected faster than anything on a Seaside Component. >>>> >>>> Regards, >>>> >>>> Esteban A. Maringolo >>>> >>>> >>>> On Wed, May 8, 2019 at 10:10 AM Esteban Maringolo >>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> Hi Felix, >>>>> >>>>> That is similar to what Johan proposes in his article, but the >>>>> goal is to achieve the same thing by using SiouX (VW's latest HTTP >>>>> server) responders, maybe using a chunked read/write approach (so >>>>> there is no more than a certain buffer in the object memory). >>>>> >>>>> Regards, >>>>> >>>>> Esteban A. Maringolo >>>>> >>>>> >>>>> On Wed, May 8, 2019 at 9:46 AM Félix Madrid <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> Hi Esteban, >>>>>> >>>>>> Maybe this article (and project) from Nick Ager can help you: >>>>>> >>>>>> http://nickager.com/blog/2011/07/01/File-upload-using-Nginx-and-Seaside >>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nickager.com_blog_2011_07_01_File-2Dupload-2Dusing-2DNginx-2Dand-2DSeaside&d=DwMGaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=dvjp1HPIw2veDqoXGboS25_BQZgS48rpxicfFO4TU2Q&m=ONky_HujutcG36aWWzrUjY_6ahacPyYsjpo6Eh2OWzE&s=8CLW_694Cyyfynuhkv78YvThaum8a0bjQgvr5Vp6qEA&e=> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Félix >>>>>> >>>>>> On Wed, May 8, 2019 at 2:39 PM Esteban Maringolo >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>> I'm trying to use the SiouX responder fortification to limit a >>>>>>> large file upload from blocking the whole image and/or filling >>>>>>> its memory. >>>>>>> >>>>>>> Looking at the options I found there is a "save attachments as >>>>>>> files", which seems like a similar approach as the one proposed >>>>>>> at <https://jbrichau.github.io/blog/large-file-upload-in-seaside >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jbrichau.github.io_blog_large-2Dfile-2Dupload-2Din-2Dseaside&d=DwMGaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=dvjp1HPIw2veDqoXGboS25_BQZgS48rpxicfFO4TU2Q&m=ONky_HujutcG36aWWzrUjY_6ahacPyYsjpo6Eh2OWzE&s=62wmHVN59u1Z0_tP2CcYdpULLFAPtfQxL8OupcfF8dA&e=> > >>>>>>> using NGINX or Apache, but apparently that option only works at >>>>>>> NetHttpResponder, but it's not applied in Seaside. >>>>>>> >>>>>>> Did anybody integrate this feature or a similar one with Seaside >>>>>>> in VW? (otherwise I'd have to do it myself). >>>>>>> >>>>>>> Regards! >>>>>>> >>>>>>> Esteban A. Maringolo >>>>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> [email protected] >>>> <mailto:[email protected]> >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.squeakfoundation.org_cgi-2Dbin_mailman_listinfo_seaside&d=DwMGaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=dvjp1HPIw2veDqoXGboS25_BQZgS48rpxicfFO4TU2Q&m=ONky_HujutcG36aWWzrUjY_6ahacPyYsjpo6Eh2OWzE&s=nHlYojUD1UOoH_oDklxP36VzZwCUmqixZ28E7uSyI_E&e=>