Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Proposal: adoption of mod_policy subproject
From: Graham Leggett <minfrin@sharp.fm>
In-Reply-To: <4EE79BDD.3050208@rowe-clan.net>
Date: Tue, 13 Dec 2011 21:57:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B420CCD-D181-4C5B-960A-08B8C3F01A9E@sharp.fm>
References: <6FA5AFBB-FDD7-43DF-9E5D-4AA94A85529D@sharp.fm>
 <4EE79BDD.3050208@rowe-clan.net>
To: dev@httpd.apache.org

On 13 Dec 2011, at 8:39 PM, William A. Rowe Jr. wrote:

>> The set of policies to apply is as follows, but is expected to change =
with time:
>>=20
>> o Content-Type: check that it's present and valid
>> o Content-Length: check that it is present and valid (used to ensure =
that keepalive requests between httpd and load balancers aren't =
prematurely terminated by a Connection: close)
>=20
> Presume this means C-L and/or T-E chunked?

The content length filter just does a simple check for content length, =
while the keepalive filter takes into account T/E chunked in far more =
detail.

What we've discovered is that our restful service layer was receiving a =
lot of HTTP/1.0 requests from client libraries (not entirely sure why, =
seems HTTP/1.0 is the default request version for some well used HTTP =
client libraries out there). If your service leaves off content length, =
and the client is HTTP/1.0, then the server indicates the end of the =
request by terminating the connection, which in turn makes the load =
balancers less effective than they should have been. We started with =
complaining about keepalive, and then switching to complaining about =
content-length so that HTTP/1.0 requests were taken into account.

Regards,
Graham
--