On Aug 12, 2010, at 11:59 PM, mdipierro wrote: > I originally misunderstood the issue. I thought the problem was with > Rocket. web2py.com runs on Apache+mod_wsgi. > In this case Apache decides on chunking, not web2py. > > It is strange but I do not know what is the Apache policy in this > respect.
There's a bit of explanation here, along with a fragment of relevant Apache source (in the comments): http://bytes.com/topic/php/answers/10395-chunked-encoding-php-apache2 > > Massimo > > > > On Aug 12, 9:59 pm, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Aug 12, 2010, at 5:13 PM, mdipierro wrote: >> >> >> >>> I looked at the Rocket web server: >> >>> 1) it always responds with HTTP/1.1 even if client is HTTP/1.0. I am >>> not sure this is allowed. I think not. A response must follow a >>> protocol that is same or lower then requested protocol >>> 2) it seems Rocket responds with chunked encoding in two cases: a) the >>> request was chunked; b) if the wsgi app returns a list with more than >>> one element (web2py can do this but normally does not do it). >> >>> There is one caveat abdou 2) There is this code >> >>> def write(self, data, sections=None): >>> """ Write the data to the output socket. """ >>> .... >>> if not self.headers_sent: >>> self.send_headers(data, sections) >> >>> If it happens that self.send_headers(data, None) is called, it will >>> force chunked-encoding. I do not see how that can happen but I cannot >>> exclude since I do not see the logic behind calling send_headers in >>> two places. >> >> What's odd is that we see the different cases on identical calls to the same >> URL. >> >> I found the chunked logic a little confusing, probably because I don't >> really understand what it's trying to do, or how it gets called. >> >> At least it seems easy to reproduce. >> >> At least in my tests (through web2py.com), I'm seeing Apache. Is that >> mod_proxy? >> >> >> >>> On Aug 12, 12:48 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: >>>> In my testings the errors were actually 500 internal server errors, >>>> not content length issues. These pages were dynamic in that they >>>> returned information from the database, but it was always the exact >>>> same 10 records. The content length was not one of the reported failed >>>> requests types. I can even replicate this with the welcome app, just >>>> add a friends table, and a sqltable on the default/index page, insert >>>> some records, then run ab on the index page, it always return sthe >>>> same thing, but will generate roughly 15% error ratios not related to >>>> content length (since it stays the same) >> >>>> -- >>>> Thadeus >> >>>> On Thu, Aug 12, 2010 at 12:27 PM, mdipierro <mdipie...@cs.depaul.edu> >>>> wrote: >>>>> I think I figure it. It is not a bug in web2py. The Content-Length is >>>>> not computed by web2py but it is computed by the web server and it is >>>>> computed correctly. >> >>>>> The length is actually different at each request. >> >>>>> This is because: >>>>> 1) in forms it contains the CSRF token with is a uuid and is different >>>>> at each request >>>>> 2) forms that contain a date may have different rounding for seconds >>>>> 3) pages with display [request], [response], etc also contain datetime >>>>> info which have different length at every request >> >>>>> The second link Jonathan posted says: >> >>>>> "Quite often you may see in the statistics "Failed requests: 5" or >>>>> similar, followed by a list of the types of failure: "(Connect: 0, >>>>> Receive: 0, Length: 5, Exceptions: 0)". If the only type of failure >>>>> that actually occurred is 'Length' then don't be alarmed. This simply >>>>> means that each request (for the same URL) returned a different length >>>>> response, which ab regards as suspicious. However it's perfectly >>>>> normal for dynamic webpages, especially if they include the time or >>>>> other very dynamic data on the page. " >> >>>>> This our case. >> >>>>> Case closed? >> >>>>> Massimo >> >>>>> On Aug 12, 12:00 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: >>>>>> You are the man. >> >>>>>> For the page I am considering the fail requests are not a real failure >>>>>> but declare a content-length of 19383 (wrong) instead of 19384 >>>>>> (correct). Let's continue investigate... >> >>>>>> Massimo >> >>>>>> On Aug 12, 11:53 am, Jonathan Lundell <jlund...@pobox.com> wrote: >> >>>>>>> On Aug 12, 2010, at 8:44 AM, David Marko wrote: >> >>>>>>>> Failed requests: 19 >>>>>>>> (Connect: 0, Receive: 0, Length: 19, Exceptions: 0) >> >>>>>>> Even more reassurance: >> >>>>>>> http://stackoverflow.com/questions/1512304/failed-requests-by-length-... >> >>>>>>> http://alwaysthecritic.typepad.com/atc/2009/04/apache-bench-notes.html >> >>>>>>> The length variation should be checked, of course, but it may well be >>>>>>> harmless. >> >>>>>>> If the length variation is under our control (cookie format, maybe?), >>>>>>> perhaps we could make an effort to make it the same.
