The way mod_python reads request content is a bit broken and can screw up in various ways, albeit rarely. This may be another example to add to the existing ones. The other known examples are:
http://issues.apache.org/jira/browse/MODPYTHON-212 http://issues.apache.org/jira/browse/MODPYTHON-234 I haven't sat down to try and work out how to fix the code in mod_python, but being mindful that it was doing the wrong thing, I completely wrote from scratch in mod_wsgi the input reading code and didn't rely on the mod_python code in any way. Thus, as far as I know these problems shouldn't occur with mod_wsgi. Graham On Oct 7, 2:06 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2007-10-06 at 15:20 +0000, Trey wrote: > > There are other people that have brought this up a little bit some > > time ago. I run a small to medium sized web application that takes > > profile pictures. By far my largest customer service issue is people > > not being able to upload their photos. > > > For the most part I have played it down as their connection sucking or > > perhaps doing something stupid with the browser, but there are a > > couple of things that I am running into that are causing an issue. > > I internally wince a bit every time this problem comes up. There's > something going on that makes it occur regularly for certain > combinations of browsers and servers (there's a report in Edgewall's own > Trac installation about a repeatable upload problem for one group of > people that is the same problem -- see [1]). However, it's not easily > reproducible for other people. > > [1]http://trac.edgewall.org/ticket/5226 > > > > > 1. I can't replicate this, no matter what I do with my browser in the > > middle of an upload. > > 2. Judging by the django code near the problem, this is working on > > information that has already been received. > > 3. I get this a few times a day at least, different people every time. > > > If someone with some knowledge of the core or http areas of django > > could speak up on this I would be very grateful. > > The error itself appears to be coming from inside mod_python. The > self._req attribute is mod_python's request object and we're in the > process of reading data from there. Unfortunately, that doesn't help > very much with the problem diagnosis, but if you Google around for the > exact error message, you'll see it appearing in other places as well. > Just not commonly enough to help work out what's really going on. I > don't think there's a lot we can do on the Django side to mitigate this. > > If it was me running a site that had this problem and I was really > dedicated to solving it, I'd try to put a rolling tcpdump on the > connection to try and capture the problem live. It will be a real bear > to try and interpret the results, but if you have accurate > (synchronised) clocks on all the machines in question and are capturing > the exception when it happens (with a timestamp), you should be able to > get close. Tcpdump has the ability to roll the logs after a certain size > and to create no more than a certain number of log files before reusing > the first ones (so it can use a ring of files, essentially). And > remember that it doesn't capture all the packets, only the first few > bytes -- enough to determine the protocol and see the start of the > message body. You can tweak this, of course, but the point is you won't > be capturing *all* of the traffic to your site, so storage requirements > won't be unmanageably huge (but they will be large). If you can set > aside a few gigabytes of disk space to capture logs and are able to > respond reasonably fast when the error occurs (so you can grab the log > that will contain the error before it gets overwritten next time > around), this is a viable technique. > > Unfortunately, it may not tell you a lot (it's always a good idea to > know what you hope to get out of a major debugging thing like this). You > might see that either there is a slight hold-up in the client sending > data and maybe you'll be able to see the browser type in the HTTP > headers. Or you might see no break in the packet timings at all, which > says there was a hold up inside application space (Apache, I guess). I'm > not sure how either piece of information will help much, although > knowing where to look further will always be a benefit. > > I guess I'd also try to ensure I was running the latest mod_python (and > Apache) in cases like this. The code is getting better all the time -- > you just don't see any huge "I upgrade mod_python and the wheels > completely fell off my site" problems -- so taking advantage of all the > bug fixes you can can't hurt here, just in case it is an > application-layer problem. > > Please realise that everything I've written here is along the lines of > how I would go about trying to gather more information. I have no > special insight into what is causing the problem, although from reading > a bunch of problem reports on the web, it sounds like it is repeatable > for certain client setups, so might not be just a sporadic connection > issue. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
