Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Sun, 8 Aug 2004 00:22:23 +0200
From: =?ISO-8859-15?Q?Andr=E9?= Malo <nd@perlig.de>
To: dev@httpd.apache.org
Subject: Re: POST without Content-Length
Message-Id: <20040808002223.505ada33@parker>
In-Reply-To: <9D695FD4-E8BE-11D8-A007-000393753936@gbiv.com>
References: <20040807221748.6fbfad8b@parker>
	<9D695FD4-E8BE-11D8-A007-000393753936@gbiv.com>
Organization: TIMTOWTDI
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

* Roy T. Fielding <fielding@gbiv.com> wrote:

> On Saturday, August 7, 2004, at 01:17  PM, Andr=E9 Malo wrote:
>=20
> > * Nick Kew <nick@webthing.com> wrote:
> >
> >> It occurs to me that a similar situation arises with CGI and chunked
> >> input.  The CGI spec guarantees a content-length header,
> >
> > ah, no.
> >
> > | * CONTENT_LENGTH
> > |
> > | The length of the said content as given by the client.
> >
> > That's rather, *if* the client says something about the length, then
> > CONTENT_LENGTH tells about it. One should not trust it anyway, since=20
> > inflating
> > compressed content with mod_deflate (for example), changes the length,=
=20
> > but
> > neither changes the Header nor the environment variable.
>=20
> CGI would happen after mod_deflate.  If mod_deflate changes the request
> body without also (un)setting content-length, then it is broken. =20

Huh? Input filters are pulled, so they run *after* the handler has been
started. And - CONTENT_LENGTH (if any - It's unset for chunked as well) sti=
ll
reflects the Content-Length sent by the client. So the current behaviour is
correct in all cases.

A CGI script therefore should never trust Content-Length, but just read
stdin until it meets an EOF.

> However,
> I suspect you are thinking of a response body, not the request.

No.

nd
--=20
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =3D>__PACKAGE__]}~;

#  Andr=E9 Malo  #  http://www.perlig.de  #