These people http://bugs.php.net/bug.php?id=40472
are seeing a similar problem wth apache and php. On Aug 13, 1:59 am, mdipierro <[email protected]> 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. > > Massimo > > On Aug 12, 9:59 pm, Jonathan Lundell <[email protected]> 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 <[email protected]> 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 <[email protected]> > > >> 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 <[email protected]> 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 <[email protected]> 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.
