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.
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.
