On Sep 10, 10:42 am, Tom <[email protected]> wrote:
> Sorry, I cannot find this quote anywhere. But thank you very much for
> your help.
Okay, I double checked and although he cc'd it back to list, he isn't
list member so it bounced.
Graham
> 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
-~----------~----~----~----~------~----~------~--~---
