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.
