Have you considered the possibility that it would be a client/browser
side error?
Both windows7 and chrome have a known open bug with large file
uploads. Many of my customers have reported this bug, all of them
using windows7 and chrome.
Has anyone seen this happening from a Mac or from Linux?
On Feb 4, 2:28 am, Tai Lee <real.hu...@mrmachine.net> wrote:
> Thanks for your detailed explanation, Graham. I'll try to approach
> this from another angle and see if I can determine what is actually
> causing the connections to be dropped, as I'm seeing this error a few
> times a day on a low traffic site using Apache at the front for static
> media, with proxy pass to Django under Apache/mod_wsgi.
>
> Cheers.
> Tai.
>
> On Feb 4, 6:17 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>
>
>
> > The problem is you can't just catch IOError, because the presence of WSGI
> > middleware may mean that IOError could be generated for other reasons when
> > reading wsgi.input. To base detection on the description in the IOError,
> > ie., 'request data read error', would mean having to know what that
> > description could be on all WSGI hosting mechanisms, and then just hope that
> > there aren't other reasons why it could arise from WSGI middleware.
>
> > So, no simple solution. This unfortunately is one of the short comings of
> > the WSGI specification. That is, there is no standardised exception type to
> > represent actual real problems with reading original wsgi.input. Part of the
> > reason is that there is no standard module associated with the WSGI
> > specification to hold the exception type, so nothing to compare against. The
> > only solution would be for WSGI specification to be enhanced to require a
> > unique exception type to be used for wsgi.input exceptions such as aborted
> > connection, with the type of that exception being passed through in the WSGI
> > environ dictionary so it could be compare against. For example something
> > like:
>
> > try:
> > data = environ['wsgi.input'].read()
> > except wsgi['wsgi.input_exception], e:
> > # ignore it
>
> > In summary, no real practical solution at this time for this.
>
> > Graham
>
> > On Friday, February 4, 2011 1:55:25 PM UTC+11, Tai Lee wrote:
>
> > > There are many questions about this on django-users. The usual answer
> > > is to ignore the errors, which are probably generated as a result of
> > > the client prematurely terminating a connection, usually during an
> > > upload.
>
> > > Nobody seems to be able to reliably reproduce the error, and it seems
> > > to happen with large and small uploads alike, but always
> > > intermittently.
>
> > > It has been suggested that a client dropping the connection should be
> > > within what one can expect from a networked client, and thus Django
> > > should not email the exception and traceback to the admins in this
> > > case. From my preliminary investigation with this issue, I tend to
> > > agree.
>
> > > Is it feasible to handle this exception in Django, or are there other
> > > issues that would prevent us from isolating this case from other
> > > legitimate exceptions that may be raised at this point?
>
> > > Here's a recent traceback:
>
> > > Traceback (most recent call last):
>
> > > File "/home/tailee/django/core/handlers/base.py", line 105, in
> > > get_response
> > > response = middleware_method(request, callback, callback_args,
> > > callback_kwargs)
>
> > > File "/home/tailee/django/middleware/csrf.py", line 224, in
> > > process_view
> > > request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
>
> > > File "/home/tailee/django/core/handlers/wsgi.py", line 209, in
> > > _get_post
> > > self._load_post_and_files()
>
> > > File "/home/tailee/django/http/__init__.py", line 207, in
> > > _load_post_and_files
> > > self._post, self._files = self.parse_file_upload(self.META, self)
>
> > > File "/home/tailee/django/http/__init__.py", line 169, in
> > > parse_file_upload
> > > return parser.parse()
>
> > > File "/home/tailee/django/http/multipartparser.py", line 192, in
> > > parse
> > > for chunk in field_stream:
>
> > > File "/home/tailee/django/http/multipartparser.py", line 314, in next
> > > output = self._producer.next()
>
> > > File "/home/tailee/django/http/multipartparser.py", line 468, in next
> > > for bytes in stream:
>
> > > File "/home/tailee/django/http/multipartparser.py", line 314, in next
> > > output = self._producer.next()
>
> > > File "/home/tailee/django/http/multipartparser.py", line 375, in next
> > > data = self.flo.read(self.chunk_size)
>
> > > File "/home/tailee/django/http/multipartparser.py", line 405, in read
> > > return self._file.read(num_bytes)
>
> > > File "/home/tailee/django/http/__init__.py", line 231, in read
> > > return self._stream.read(*args, **kwargs)
>
> > > IOError: request data read error
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
