$_POST adding whitespace to variable value

[Mason Barge]

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'];
.. . .
<div class="tr">
<div class="tdfl">
ZIP code (5 digit):
</div>
<div class="tdfr">
<input type="text" name="zip" size="5" maxlength="5" value="<?php
if(isset($_POST['submit'])) {
echo $_POST['zip'];
} else {
echo $zip;
} ?>
" />
</div>
</div>

Does anyone have an idea why this happens? I can work around it (with a lot
of spaghetti code) but it's unsettling to have so little understanding or
control of the transition: database->form input->Post variable->regex.

TIA :)
--
Mason Barge

[Good Man]

"Mason Barge" <ma********@comcast.netwrote in
news:Nf******************************@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?

[Rik Wasmus]

On Tue, 15 Jan 2008 17:28:59 +0100, Mason Barge <ma********@comcast.net>
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...

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:
<input type="text" name="zip" size="5" maxlength="5"
value="<?php if(isset($_POST['submit'])) {
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

[Mason Barge]

"Good Man" <he***@letsgo.comwrote in message
news:Xn************************@216.196.97.131...

"Mason Barge" <ma********@comcast.netwrote in
news:Nf******************************@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.

[Rik Wasmus]

On Tue, 15 Jan 2008 18:06:21 +0100, Good Man <he***@letsgo.comwrote:

>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

[Good Man]

"Rik Wasmus" <lu************@hotmail.comwrote in
news:op***************@metallium.lan:

On Tue, 15 Jan 2008 18:06:21 +0100, Good Man <he***@letsgo.comwrote:

>>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.

[Rik Wasmus]

On Tue, 15 Jan 2008 18:26:12 +0100, Good Man <he***@letsgo.comwrote:

"Rik Wasmus" <lu************@hotmail.comwrote in
news:op***************@metallium.lan:

>On Tue, 15 Jan 2008 18:06:21 +0100, Good Man <he***@letsgo.comwrote:

>>>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

[Steve]

"Rik Wasmus" <lu************@hotmail.comwrote in message
news:op***************@metallium.lan...

On Tue, 15 Jan 2008 18:26:12 +0100, Good Man <he***@letsgo.comwrote:

>"Rik Wasmus" <lu************@hotmail.comwrote in
news:op***************@metallium.lan:

>>On Tue, 15 Jan 2008 18:06:21 +0100, Good Man <he***@letsgo.comwrote:
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."

;^)

[Rik Wasmus]

On Tue, 15 Jan 2008 19:04:51 +0100, Steve <no****@example.comwrote:

"Rik Wasmus" <lu************@hotmail.comwrote in message
news:op***************@metallium.lan...

>On Tue, 15 Jan 2008 18:26:12 +0100, Good Man <he***@letsgo.comwrote:

>>"Rik Wasmus" <lu************@hotmail.comwrote in
news:op***************@metallium.lan:
On Tue, 15 Jan 2008 18:06:21 +0100, Good Man <he***@letsgo.comwrote:
>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

[Mason Barge]

"Rik Wasmus" <lu************@hotmail.comwrote in message
news:op***************@metallium.lan...
On Tue, 15 Jan 2008 17:28:59 +0100, Mason Barge <ma********@comcast.net>
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:
<input type="text" name="zip" size="5" maxlength="5"
value="<?php if(isset($_POST['submit'])) {
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.

[Steve]

"Rik Wasmus" <lu************@hotmail.comwrote in message
news:op***************@metallium.lan...

On Tue, 15 Jan 2008 19:04:51 +0100, Steve <no****@example.comwrote:

>"Rik Wasmus" <lu************@hotmail.comwrote in message
news:op***************@metallium.lan...

>>On Tue, 15 Jan 2008 18:26:12 +0100, Good Man <he***@letsgo.comwrote:
"Rik Wasmus" <lu************@hotmail.comwrote in
news:op***************@metallium.lan:
On Tue, 15 Jan 2008 18:06:21 +0100, Good Man <he***@letsgo.comwrote:
>>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. :)