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.
