Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14087
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 Dec 2004 11:02:43 -0700
Message-ID: <5367F26C013DE8429873569307F6F4A382F963@OCC01MX023.na.simplot.com>
Thread-Topic: [PHP-DEV] ftp_get_resp & ftp_get_conv functions
Thread-Index: AcTjdxLFGxT8Bn1ITimuu4lk2zNXMAAIDDDA
To: "Kamesh Jayachandran" <kameshj@fastmail.fm>, <internals@lists.php.net>
Subject: RE: [PHP-DEV] ftp_get_resp & ftp_get_conv functions
From: Jesse.Binam@simplot.com ("Binam, Jesse")

Agreed. That was a bad idea.

After I slept on it, I regreted sending that, cause the default memory
limit is 8M (with the exception of the cli sapi). With no option on
whether or not to do the trace and 2500x4096 being a 10M buffer, I
imagine just calling ftp_connect would put you over your memory limit.
So I will change it to allocate the memory dynamically, and an optional
parmeter to ftp_connect on whether or not to do the trace at all.

But now I need some advise from you experts...
I can't imagine getting a 4k response or sending a 4k command on the
control channel of an FTP session. So that is a lot of unused memory, on
the other hand, that's how big the input/output buffers are and without
knowing what the length of the longest response/command is until the
whole conversation is finished, if my string buffer is to small, it will
either truncate the string (with proper bounds checking) or create the
potential for a buffer overflow. I could check the length of the string
and if it is longer than the current length of the string array, then
allocate enough memory to hold it, increasing the length of the element
for all the other strings. In which case I would think it appropriate to
#define MAX_RESP_LENGTH to prevent potential for a DOS.

Also allocating N+1 elements every time a command is sent or a response
is received would create a ton of overhead because wouldn't I would have
to allocate the new buffer, then copy the current buffer in to it
resulting in a serious performance hit?

Regretfully ignorant,
Jess

-----Original Message-----
From: Kamesh Jayachandran [mailto:kameshj@fastmail.fm]=20
Sent: Thursday, December 16, 2004 6:57 AM
To: Binam, Jesse; internals@lists.php.net
Subject: Re: [PHP-DEV] ftp_get_resp & ftp_get_conv functions

Hi Jesse,
2500*4096 =3D 10M on ftpbuf would be too much for the user who is not
interested in this functionality.=20
It should be allocating the memory dynamically instead of hardcoding the
size to 2500.=20
This need to happen only when requested, may be some option argument to
ftp_connect whether to track the ftp conversation.

With regards
Kamesh Jayachandran
On Wed, 15 Dec 2004 21:47:09 -0700, "Binam, Jesse"
<Jesse.Binam@simplot.com> said:
> The attached diff adds 2 ftp functions. I read the=20
> README.SUBMITTING_PATCH and went thru all the steps, but there are no=20
> tests for ftp, and I didn't understand how to update the docs. So if=20
> someone would like to help me with that, great.
>=20
> Basically, I modifed ftpbuf_t adding a 2 dimensional array (array of
> strings) to store the conversation, and an int that indicates the next

> element in first dimension the array. I modified ftp_putcmd and=20
> ftp_getresp to add what gets sent/recvd in the conversation. And=20
> lastly I added ftp_get_resp which returns the 3 digit return code from

> the server of the last command sent, and ftp_get_conv (which I would=20
> not be opposed to changing the name of, that's just what I came up=20
> with) that returns the ftp conversation as an array. Both functions=20
> must be called before ftp_close (or ftp_quit) because it frees the
resource.
>=20
> The array I defined is 2500x4096. 4096 was already there as the=20
> FTP_BUFSIZE, 2500 maybe a little excesive but in my environment it=20
> could get that bad. :/ So I was thinking that maybe I should add a=20
> optional flag on ftp_connect on where or not to trace the
conversation? Thoughts?
>=20
> Jess