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
-~----------~----~----~----~------~----~------~--~---
