Re: Delphi2009/Indy bug TIdCustomHTTPServer.DoExecute

Giganews Newsgroups
Subject: Re: Delphi2009/Indy bug TIdCustomHTTPServer.DoExecute
Posted by:  Remy Lebeau \(TeamB\) (no.spam@no.spam.com)
Date: Sat, 13 Sep 2008

"Marius" <tomuchspam@home.org> wrote in message
news:73689145D562E340tomuchspam@home.org...

> I downloaded the svn tiburon version of indy but i encountered 1 simple
> problem in the idCustomHttpServer.pas. The UnparsedParams is not
> filled correctly and that has something todo with the last update of the
> unit.

That is not a bug.  It is an intentional change.  The UnparsedParams
property only has meaning when using the FormParams property, and the
FormParams property only has meaning for "application/x-www-form-urlencoded"
requests.  The UnparsedParams property was incorrectly being filled in for
the wrong types of requests in previously versions.  That was the real bug
that the latest code finally fixes.

> I changed/fixed it by giving the UnparsedParams the right value first and
> then assigning that value to FormParams if contenttype =
> application/x-www-form-urlencoded.

Why?  That is the wrong thing to do.  You have reintroduced the past bug
again.

> This works for us at the moment, hope this is a correct solution.

Then you are relying on broken logic to begin with.

> LRequestInfo.UnparsedParams :=
> ReadStringFromStream(LRequestInfo.PostStream);

Reading a string from the PostStream unconditionally was a BAD BUG in past
versions.  Think what happens if the client tries to upload a binary file,
for instance.  The UnparsedParams, and thus the FormParams, tries to parse
the binary data when it should be, wasting memory and causing errors.  That
is why reading the PostStream like that is conditional on the ContentType
now, like it should be.

--
Remy Lebeau (TeamB)

Replies

In response to

Delphi2009/Indy bug TIdCustomHTTPServer.DoExecute posted by Marius on Thu, 11 Sep 2008