True. What about:
def parse_get_post_vars(request, environ):
....
try:
request.body = copystream_progress(request) ### stores request
body
except:
return False
...
return True
#in wsgibase
...
if not parse_get_post_vars(request, environ): return []
On May 10, 12:10 am, Thadeus Burgess <[email protected]> wrote:
> What if there was an IO error with cgi.FieldStorage ?
>
> --
> Thadeus
>
> On Mon, May 10, 2010 at 12:06 AM, mdipierro <[email protected]> wrote:
> > Yes. it is safe to ignore, but it still causes a minor slow down
> > because web2py issues a ticket and that may be unnecessary.
>
> > On May 10, 12:01 am, Thadeus Burgess <[email protected]> wrote:
> >> So you are saying that a user with a slow connection (which consists
> >> of a large portion of the sites user base) clicks reload, so their
> >> browser stops communicating with that request, so web2py catches it as
> >> an IOError... so then is this safe to ignore?
>
> >> Below is a log that I found in apache2.error.log
>
> >> [Sun Jan 31 13:42:50 2010] [error] [client ******] (70007)The timeout
> >> specified has expired: mod_wsgi (pid=3961): Unable to get bucket
> >> brigade for request., referer:http://mysite.com/page1
> >> [Sun Jan 31 13:42:51 2010] [error] [client ******] mod_wsgi
> >> (pid=3926): Exception occurred processing WSGI script
> >> '/web2py/wsgihandler.py'.
> >> [Sun Jan 31 13:42:51 2010] [error] [client ******] IOError: failed to
> >> write data
>
> >> --
> >> Thadeus
>
> >> On Sun, May 9, 2010 at 11:52 PM, Graham Dumpleton
>
> >> <[email protected]> wrote:
>
> >> > On May 10, 1:51 pm, Thadeus Burgess <[email protected]> wrote:
> >> >> Ticket. I usually see them the next day when I check admin.
>
> >> >> No, it is usually just one IP but it happens to a lot of people at the
> >> >> same time, scaled by the amount of traffic being put on the server.
>
> >> > Then it is likely that the ISP or network all the requests were routed
> >> > by dropped all the connections for whatever reason.
>
> >> >> Roughly about 10% of the requests generate this error.
>
> >> >> > A user not waiting for a request to complete before clicking on
> >> >> > another link or pressing reload. In other words, client dropped
> >> >> > original connection.
>
> >> >> Obviously this is a web2py issue then, because I don't have any
> >> >> problems when I go click-happy on other web sites.
>
> >> > Part of the problem is that there is no standard for what type of
> >> > Python exception is generated by a dropped connection. The mod_python
> >> > and mod_wsgi package so happens to use IOError, but different
> >> > descriptions. Other WSGI servers are within their rights to use a
> >> > completely different Python exception or yet another description
> >> > against an IOError. Thus, it becomes really hard for a generic
> >> > framework that can be hosted in various ways to make a judgement as to
> >> > whether a failure on read was due to a particular type of error. Thus
> >> > it becomes hard to ignore errors for loss of connection. You also by
> >> > ignoring them, limit an applications ability to take some special
> >> > action when connections are dropped.
>
> >> > It therefore isn't obvious what to do and most Python frameworks will
> >> > as a result just pass the exception up the stack and cause a 500
> >> > response. If you have a mailout option for errors back to system
> >> > administrators then you obviously may get an lot of emails. Best you
> >> > might do is for that mailout middleware to allow a user to supply
> >> > their own rules, ie., exception types and desription regex, for things
> >> > that should be ignored as far as mailout message to admin.
>
> >> > Graham
>
> >> >> On Sun, May 9, 2010 at 9:55 PM, mdipierro <[email protected]>
> >> >> wrote:
> >> >> > ure about the problem but I had a few instances of people
> >> >> > clicking reload a lot (and I mean a lot). So I use thi
