Sorry, I cannot find this quote anywhere. But thank you very much for your help.
Regards, Tom On Sep 10, 2:28 am, Graham Dumpleton <[email protected]> wrote: > On Sep 10, 5:54 am, tom <[email protected]> wrote: > > > Hello, > > > I've asked this question in the modwsgi group but it seems that it is > > more likely to do with Werkzeug. I hope this kind of cross-posting is > > not frowned upon. > > Armin already replied on mod_wsgi list and said: > > """That's the case and I think 0.5 had that bug. It is fixed in 0.5.1 > as > far as I know and it's fixed for sure in the tip version. The latest > code properly aborts on an empty string. > """ > > Did you not see that response? > > Graham > > > > > >> I am using Werkzeug as a framework, and want to upload files of up to > > >> 300MB size. It all works well, but if the user wants to cancel his > > >> upload, and thus clicks the cancel button, reloads the page or closes > > >> the tab, an apache thread maxes out at 100% CPU and doesn't seem to > > >> stop until killed. > > >> This seems to happen regardless whether a simple form, an iframe or > > >> middleware is used, as long as modwsgi is involved, leading me to look > > >> into this direction. I tried to find out what the apache thread is > > >> doing while maxing out, but no luck so far. My best guess is that the > > >> "chunk saving loop" that must be used to build the temp file from > > >> chunks is waiting for more data. > > >> Has anybody experienced something similar, and can point me in the > > >> right direction? I'd be happy to add more info if needed. > > > > I would say that the loop, rather than waiting for more data, is > > > actually reading it but getting back empty string instead rather than > > > a read failure exception. > > > The latest Werkzeug code tries to be WSGI 1.0 compliant and not rely > > > on the end sentinel and instead keep reading until it gets all the > > > data it expects. Thinking about it, this shows that WSGI 1.0 is > > > perhaps flawed in not requiring an empty string as end sentinel to be > > > mandatory because possibly can't guarantee that exception will be > > > raised if socket closed early. > > > Even if the Werkzeug code tries to rely on content length only, seems > > > like it should also still try and deal with where an empty string is > > > returned prior to content length being read. > > > So I guess it boils down to the parse_multipart function in > > formparser.py in werkzeug. But to be honest I don't quite see what to > > change there. Any ideas? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pocoo-libs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pocoo-libs?hl=en -~----------~----~----~----~------~----~------~--~---
