$_POST adding whitespace to variable value

I have a standard POST form consisting of two types of input: text input and
textarea. The form downloads current settings from a mysql database. The
user can update the information by modifying the text and clicking a
standard "submit" button.

MAIN PROBLEM:

My problem is that the information transmitted to the formhandler apparently
has some sort of whitespace added to it. If I simply use trim() on the POST
variable, it fails the regex. If I convert to POST variable to a single
variable and use trim(), it solves the problem.

I can just convert and trim every variable, but it would be a lot cleaner to
trim the entire POST array with a foreach(). Plus, I'd much rather
understand the problem. In other words:

This code works:
$zip=trim($_POST['zip']);
if (preg_match("/^[\d]{5}/", $zip)) {
$update.=" zip='$zip',";
} else {
error_alert('Zip code must be exactly 5 digits with no other characters. ');
}

This code throws a regex rejection:

$_POST['zip']=trim($_POST['zip']);
if (preg_match("/^[\d]{5}/", $_Post['zip'])) {
$zip = $_POST['zip'];
$update.=" zip='$zip',";
} else {
error_alert('Zip code must be exactly 5 digits with no other characters. ');
}

SECONDARY PROBLEM

Of course, my real problem is how the whitespace gets in there in the first
place. Or more accurately, why the regex would reject information from the
database. In the case of "$zip", the field is VARCHAR(5).

Here's the form entry:
$zip=$row['zip'];
.. . .

Re: $_POST adding whitespace to variable value

"Mason Barge" wrote in
news:NfidnfLSQ8PTQhHanZ2dnUVZ_hOdnZ2d@comcast.com:

> I have a standard POST form consisting of two types of input: text
> input and textarea. The form downloads current settings from a mysql
> database. The user can update the information by modifying the text
> and clicking a standard "submit" button.
>
> MAIN PROBLEM:
>
> My problem is that the information transmitted to the formhandler
> apparently has some sort of whitespace added to it. If I simply use
> trim() on the POST variable, it fails the regex.

No it doesn't. You are confused about what a post variable is. You
can't change what's been $_POSTed, but you can certainly ASSIGN the
value to your own variable and change *that*.

> If I convert to POST
> variable to a single variable and use trim(), it solves the problem.

As explained above.


> I can just convert and trim every variable, but it would be a lot
> cleaner to trim the entire POST array with a foreach(). Plus, I'd much
> rather understand the problem. In other words:
>
> This code works:
> $zip=trim($_POST['zip']);
> if (preg_match("/^[\d]{5}/", $zip)) {
> $update.=" zip='$zip',";
> } else {
> error_alert('Zip code must be exactly 5 digits with no other
> characters. '); }
>
> This code throws a regex rejection:
>
> $_POST['zip']=trim($_POST['zip']);

as hinted at above - what are you doing here? why are you trying to
*set* a $_POST variable, which has a very specific meaning? Why are you
using this code at all, as opposed to the code above which does what you
want in the correct way???

Are you trying to trim the $_POST elements in one fail swoop? Well you
can either use array_map to apply a trim-type function to the $_POST
array, but be aware that it will mess up any $_POST elements which are
arrays themselves (unless you use one of the user contributions on the
manual page). Personally, I specifically trim every $_POST'ed element.


> Of course, my real problem is how the whitespace gets in there in the
> first place.

Nope, who cares how it got in?

Re: $_POST adding whitespace to variable value

On Tue, 15 Jan 2008 17:28:59 +0100, Mason Barge =
=

wrote:
> My problem is that the information transmitted to the formhandler =

> apparently has some sort of whitespace added to it. If I simply use =

> trim() on the POST variable, it fails the regex. If I convert to POST=
=

> variable to a single variable and use trim(), it solves the problem.
>
> This code throws a regex rejection:
>
> $_POST['zip']=3Dtrim($_POST['zip']);
> if (preg_match("/^[\d]{5}/", $_Post['zip'])) {

$_Post !=3D $_Post
As soon as you've fixed that, this would work, but it is not =

recommendable. Having a clear view of what your user actually submitted,=
=

and how you've handled/altered the data after that will save you lots of=
=

debugging time.

And just on a side note: shouldn't it be "/^[\d]{5}$/" ? The regex now =

will consider '12345and then some arbitrary text or characters' valid...=


> SECONDARY PROBLEM
>
> Of course, my real problem is how the whitespace gets in there in the =
=

> first place. Or more accurately, why the regex would reject informati=
on =

> from the database. In the case of "$zip", the field is VARCHAR(5).
>
> Here's the form entry:
> =

> value=3D" > echo $_POST['zip'];
> } else {
> echo $zip;
> } ?>
> " />

Here is is. You have whitespace between '?>' and '" />', which will =

probably translate itself to a space in the field in HTML context.
Use:' } ?>" />'

-- =

Rik Wasmus

Re: $_POST adding whitespace to variable value

"Good Man" wrote in message
news:Xns9A267B2AAC6C7sonicyouth@216.196.97.131...
> "Mason Barge" wrote in
> news:NfidnfLSQ8PTQhHanZ2dnUVZ_hOdnZ2d@comcast.com:
>
>> I have a standard POST form consisting of two types of input: text
>> input and textarea. The form downloads current settings from a mysql
>> database. The user can update the information by modifying the text
>> and clicking a standard "submit" button.
>>
>> MAIN PROBLEM:
>>
>> My problem is that the information transmitted to the formhandler
>> apparently has some sort of whitespace added to it. If I simply use
>> trim() on the POST variable, it fails the regex.
>
> No it doesn't. You are confused about what a post variable is. You
> can't change what's been $_POSTed, but you can certainly ASSIGN the
> value to your own variable and change *that*.
>
>> If I convert to POST
>> variable to a single variable and use trim(), it solves the problem.
>
> As explained above.
>
>
>> I can just convert and trim every variable, but it would be a lot
>> cleaner to trim the entire POST array with a foreach(). Plus, I'd much
>> rather understand the problem. In other words:
>>
>> This code works:
>> $zip=trim($_POST['zip']);
>> if (preg_match("/^[\d]{5}/", $zip)) {
>> $update.=" zip='$zip',";
>> } else {
>> error_alert('Zip code must be exactly 5 digits with no other
>> characters. '); }
>>
>> This code throws a regex rejection:
>>
>> $_POST['zip']=trim($_POST['zip']);
>
> as hinted at above - what are you doing here? why are you trying to
> *set* a $_POST variable, which has a very specific meaning? Why are you
> using this code at all, as opposed to the code above which does what you
> want in the correct way???
>
> Are you trying to trim the $_POST elements in one fail swoop? Well you
> can either use array_map to apply a trim-type function to the $_POST
> array, but be aware that it will mess up any $_POST elements which are
> arrays themselves (unless you use one of the user contributions on the
> manual page). Personally, I specifically trim every $_POST'ed element.
>

Thanks for the response, it was very helpful.

Re: $_POST adding whitespace to variable value

On Tue, 15 Jan 2008 18:06:21 +0100, Good Man wrote:
>> Of course, my real problem is how the whitespace gets in there in the
>> first place.
>
> Nope, who cares how it got in?

Euhm, if I request a form editing some record, and I change one field, I
don't expect to get an 'invalid' error on another in my view unaltered
field. In this case, we KNOW whitespace is invalid, and will trim() it
out. However, if whitespace is valid, this could stack whitespace on the
end for every edit action. Not something you'd like.
--
Rik Wasmus

Re: $_POST adding whitespace to variable value

"Rik Wasmus" wrote in
news:op.t4zeklpi5bnjuv@metallium.lan:

> On Tue, 15 Jan 2008 18:06:21 +0100, Good Man wrote:
>>> Of course, my real problem is how the whitespace gets in there in
>>> the first place.
>>
>> Nope, who cares how it got in?
>
> Euhm, if I request a form editing some record, and I change one field,
> I don't expect to get an 'invalid' error on another in my view
> unaltered field. In this case, we KNOW whitespace is invalid, and
> will trim() it out. However, if whitespace is valid, this could stack
> whitespace on the end for every edit action. Not something you'd
> like.

true, i wasn't even imagining it being created on the back-end/server-side.

Re: $_POST adding whitespace to variable value

On Tue, 15 Jan 2008 18:26:12 +0100, Good Man wrote:

> "Rik Wasmus" wrote in
> news:op.t4zeklpi5bnjuv@metallium.lan:
>
>> On Tue, 15 Jan 2008 18:06:21 +0100, Good Man wrote:
>>>> Of course, my real problem is how the whitespace gets in there in
>>>> the first place.
>>>
>>> Nope, who cares how it got in?
>>
>> Euhm, if I request a form editing some record, and I change one field,
>> I don't expect to get an 'invalid' error on another in my view
>> unaltered field. In this case, we KNOW whitespace is invalid, and
>> will trim() it out. However, if whitespace is valid, this could stack
>> whitespace on the end for every edit action. Not something you'd
>> like.
>
> true, i wasn't even imagining it being created on the
> back-end/server-side.

The OP didn't mention it indeed. I assumed it because the zip code field
apparantly was filled with a $row['zip'] variable, which makes one
immediately think of a fetched row from a database result.
--
Rik Wasmus

Re: $_POST adding whitespace to variable value

"Rik Wasmus" wrote in message
news:op.t4zev7md5bnjuv@metallium.lan...
> On Tue, 15 Jan 2008 18:26:12 +0100, Good Man wrote:
>
>> "Rik Wasmus" wrote in
>> news:op.t4zeklpi5bnjuv@metallium.lan:
>>
>>> On Tue, 15 Jan 2008 18:06:21 +0100, Good Man wrote:
>>>>> Of course, my real problem is how the whitespace gets in there in
>>>>> the first place.
>>>>
>>>> Nope, who cares how it got in?
>>>
>>> Euhm, if I request a form editing some record, and I change one field,
>>> I don't expect to get an 'invalid' error on another in my view
>>> unaltered field. In this case, we KNOW whitespace is invalid, and
>>> will trim() it out. However, if whitespace is valid, this could stack
>>> whitespace on the end for every edit action. Not something you'd
>>> like.
>>
>> true, i wasn't even imagining it being created on the
>> back-end/server-side.
>
> The OP didn't mention it indeed.

"The form downloads current settings from a mysql database."

;^)

Re: $_POST adding whitespace to variable value

On Tue, 15 Jan 2008 19:04:51 +0100, Steve wrote:
> "Rik Wasmus" wrote in message
> news:op.t4zev7md5bnjuv@metallium.lan...
>> On Tue, 15 Jan 2008 18:26:12 +0100, Good Man wrote:
>>> "Rik Wasmus" wrote in
>>> news:op.t4zeklpi5bnjuv@metallium.lan:
>>>> On Tue, 15 Jan 2008 18:06:21 +0100, Good Man wrote:
>>>>>> Of course, my real problem is how the whitespace gets in there in
>>>>>> the first place.
>>>>>
>>>>> Nope, who cares how it got in?
>>>>
>>>> Euhm, if I request a form editing some record, and I change one field,
>>>> I don't expect to get an 'invalid' error on another in my view
>>>> unaltered field. In this case, we KNOW whitespace is invalid, and
>>>> will trim() it out. However, if whitespace is valid, this could stack
>>>> whitespace on the end for every edit action. Not something you'd
>>>> like.
>>>
>>> true, i wasn't even imagining it being created on the
>>> back-end/server-side.
>>
>> The OP didn't mention it indeed.
>
> "The form downloads current settings from a mysql database."

Ah, carefull reading code, less carefull reading introductions, my bad :).
--
Rik Wasmus

Re: $_POST adding whitespace to variable value

"Rik Wasmus" wrote in message
news:op.t4zefq1y5bnjuv@metallium.lan...
On Tue, 15 Jan 2008 17:28:59 +0100, Mason Barge
wrote:
> My problem is that the information transmitted to the formhandler
> apparently has some sort of whitespace added to it. If I simply use
> trim() on the POST variable, it fails the regex. If I convert to POST
> variable to a single variable and use trim(), it solves the problem.
>
> This code throws a regex rejection:
>
> $_POST['zip']=trim($_POST['zip']);
> if (preg_match("/^[\d]{5}/", $_Post['zip'])) {

$_Post != $_Post
As soon as you've fixed that, this would work, but it is not
recommendable. Having a clear view of what your user actually submitted,
and how you've handled/altered the data after that will save you lots of
debugging time.

And just on a side note: shouldn't it be "/^[\d]{5}$/" ? The regex now
will consider '12345and then some arbitrary text or characters' valid...

Yes, of course it should. I got sloppy because the input form is maximum
size 5.

> SECONDARY PROBLEM
>
> Of course, my real problem is how the whitespace gets in there in the
> first place. Or more accurately, why the regex would reject information
> from the database. In the case of "$zip", the field is VARCHAR(5).
>
> Here's the form entry:
> > value=" > echo $_POST['zip'];
> } else {
> echo $zip;
> } ?>
> " />

Here is is. You have whitespace between '?>' and '" />', which will
probably translate itself to a space in the field in HTML context.
Use:' } ?>" />'

--
Rik Wasmus

That's so dumb I can't even get embarrassed. Even worse, I've fixed the
exact problem before, LOL. Thanks for pointing it out.

I think I need a nap.

Re: $_POST adding whitespace to variable value

"Rik Wasmus" wrote in message
news:op.t4zgmgqe5bnjuv@metallium.lan...
> On Tue, 15 Jan 2008 19:04:51 +0100, Steve wrote:
>> "Rik Wasmus" wrote in message
>> news:op.t4zev7md5bnjuv@metallium.lan...
>>> On Tue, 15 Jan 2008 18:26:12 +0100, Good Man wrote:
>>>> "Rik Wasmus" wrote in
>>>> news:op.t4zeklpi5bnjuv@metallium.lan:
>>>>> On Tue, 15 Jan 2008 18:06:21 +0100, Good Man wrote:
>>>>>>> Of course, my real problem is how the whitespace gets in there in
>>>>>>> the first place.
>>>>>>
>>>>>> Nope, who cares how it got in?
>>>>>
>>>>> Euhm, if I request a form editing some record, and I change one field,
>>>>> I don't expect to get an 'invalid' error on another in my view
>>>>> unaltered field. In this case, we KNOW whitespace is invalid, and
>>>>> will trim() it out. However, if whitespace is valid, this could stack
>>>>> whitespace on the end for every edit action. Not something you'd
>>>>> like.
>>>>
>>>> true, i wasn't even imagining it being created on the
>>>> back-end/server-side.
>>>
>>> The OP didn't mention it indeed.
>>
>> "The form downloads current settings from a mysql database."
>
> Ah, carefull reading code, less carefull reading introductions, my bad :).

i'm just mess'n with you rik. even without, you still divined the correct
answer. :)