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.
