PDA

Bekijk Volledige Versie : Passing objects from one page to another



Marcel
09/11/06, 14:05
I have a person class adn i want to derive an object of that class on one
page and pass that object to a next page but that does not work for me and i
do not understand why.

Here is de code:

class.person.php
-----------------------------------
class person {

private $_name;

public function setName($name) {

$this->_name = $name;

}

public function getName() {

return $this->_name;

}

}
--------------------------------------------



person1.php // here is the object created
-------------------------------------------
require_once("class.person.php");

$p = new person();

$p->setName("Jim");

$safep = urlencode(serialize($p));

header("Location:person2.php?data=".$safep);

exit;


person2.php // page where the object is transfered to
---------------------------------------------------
require_once("class.person.php");

$p = unserialize(urldecode($_GET['data']));

echo $p->getName();

ZeldorBlat
09/11/06, 14:06
Marcel wrote:
> I have a person class adn i want to derive an object of that class on one
> page and pass that object to a next page but that does not work for me and i
> do not understand why.
>
> Here is de code:
>
> class.person.php
> -----------------------------------
> class person {
>
> private $_name;
>
> public function setName($name) {
>
> $this->_name = $name;
>
> }
>
> public function getName() {
>
> return $this->_name;
>
> }
>
> }
> --------------------------------------------
>
>
>
> person1.php // here is the object created
> -------------------------------------------
> require_once("class.person.php");
>
> $p = new person();
>
> $p->setName("Jim");
>
> $safep = urlencode(serialize($p));
>
> header("Location:person2.php?data=".$safep);
>
> exit;
>
>
> person2.php // page where the object is transfered to
> ---------------------------------------------------
> require_once("class.person.php");
>
> $p = unserialize(urldecode($_GET['data']));
>
> echo $p->getName();

Difficult to say since you haven't told us what doesn't work. As in
you get some error that you can't unserialize it? Or no error at all
(as in your error reporting is turned off)?

My guess would be that
$p = unserialize(urldecode($_GET['data']));
should really be just
$p = unserialize($_GET['data']);

But I didn't test it.

Marcel
09/11/06, 14:06
"ZeldorBlat" <zeldorblat@gmail.com> schreef in bericht
news:1162998447.934912.233680@i42g2000cwa.googlegr oups.com...
>
> Marcel wrote:
>> I have a person class adn i want to derive an object of that class on one
>> page and pass that object to a next page but that does not work for me
>> and i
>> do not understand why.
>>
>> Here is de code:
>>
>> class.person.php
>> -----------------------------------
>> class person {
>>
>> private $_name;
>>
>> public function setName($name) {
>>
>> $this->_name = $name;
>>
>> }
>>
>> public function getName() {
>>
>> return $this->_name;
>>
>> }
>>
>> }
>> --------------------------------------------
>>
>>
>>
>> person1.php // here is the object created
>> -------------------------------------------
>> require_once("class.person.php");
>>
>> $p = new person();
>>
>> $p->setName("Jim");
>>
>> $safep = urlencode(serialize($p));
>>
>> header("Location:person2.php?data=".$safep);
>>
>> exit;
>>
>>
>> person2.php // page where the object is transfered to
>> ---------------------------------------------------
>> require_once("class.person.php");
>>
>> $p = unserialize(urldecode($_GET['data']));
>>
>> echo $p->getName();
>
> Difficult to say since you haven't told us what doesn't work. As in
> you get some error that you can't unserialize it? Or no error at all
> (as in your error reporting is turned off)?
>
> My guess would be that
> $p = unserialize(urldecode($_GET['data']));
> should really be just
> $p = unserialize($_GET['data']);
>
> But I didn't test it.
>

Yes you are right, the errorcode i am getting is:

Fatal error: Call to a member function getName() on a non-object in
D:\public_html\person2.php on line 7

Regards,

Marcel

Marcin Dobrucki
09/11/06, 14:06
Marcel wrote:
> I have a person class adn i want to derive an object of that class on one
> page and pass that object to a next page but that does not work for me and i
> do not understand why.
....
I tried this code, and it works just fine. You didn't include the rest
of the code, so maybe there is something there that breaks it?

<?php
class A {
var $name;
function A($name) {
$this->name = $name; }
function getName() {
return $this->name; }
}

$a = new A("my name");
$a_serialized = urlencode(serialize($a));
header("Location: obj2.php?data=".$a_serialized);
?>

and:

<?php
class A {
var $name;
function A($name) {
$this->name = $name; }
function getName() {
return $this->name; }
}

$a = unserialize(urldecode($_GET['data']));
echo get_class($a);
echo "<br>";
echo $a->getName();
?>

Marcin Dobrucki
09/11/06, 14:06
Marcel wrote:

> Yes you are right, the errorcode i am getting is:
>
> Fatal error: Call to a member function getName() on a non-object in
> D:\public_html\person2.php on line 7

One step at a time: what do you get out of "urldecode" and then what
do you get from "unserialize"? Check the return values.

Marcel
09/11/06, 14:06
"Marcin Dobrucki" <Marcin.Dobrucki@TAKETHISAWAY.nokia.com> schreef in
bericht news:lJm4h.42490$_k2.774821@news2.nokia.com...
> Marcel wrote:
>> I have a person class adn i want to derive an object of that class on one
>> page and pass that object to a next page but that does not work for me
>> and i do not understand why.
> ...
> I tried this code, and it works just fine. You didn't include the rest of
> the code, so maybe there is something there that breaks it?
>
> <?php
> class A {
> var $name;
> function A($name) {
> $this->name = $name; }
> function getName() {
> return $this->name; }
> }
>
> $a = new A("my name");
> $a_serialized = urlencode(serialize($a));
> header("Location: obj2.php?data=".$a_serialized);
> ?>
>
> and:
>
> <?php
> class A {
> var $name;
> function A($name) {
> $this->name = $name; }
> function getName() {
> return $this->name; }
> }
>
> $a = unserialize(urldecode($_GET['data']));
> echo get_class($a);
> echo "<br>";
> echo $a->getName();
> ?>

Hi Marcin,

I tried your example but i am getting the same error: Call to a member
function getName() on a non-object in

Maybe it is a php.ini issue? I do not know what can be another reason....
maybe magicquotes have to do something with this?

Do you have any ideas?

Marcel

Marcel
09/11/06, 14:06
"Marcin Dobrucki" <Marcin.Dobrucki@TAKETHISAWAY.nokia.com> schreef in
bericht news:VKm4h.42491$_k2.774821@news2.nokia.com...
> Marcel wrote:
>
>> Yes you are right, the errorcode i am getting is:
>>
>> Fatal error: Call to a member function getName() on a non-object in
>> D:\public_html\person2.php on line 7
>
> One step at a time: what do you get out of "urldecode" and then what do
> you get from "unserialize"? Check the return values.

It seems the unserialize function does not seem to work properly... i will
do a little research at that first ok...

thehuby@gmail.com
09/11/06, 14:06
Wouldn't you be better using sessions?

If you register a session variable you won't need to use the query
string and you won't need to serialize and deserialise it.

Take a look at http://uk2.php.net/manual/en/ref.session.php for some
more details.

Rick
www.e-connected.com

Michael Fesser
09/11/06, 14:06
..oO(Marcel)

>I tried your example but i am getting the same error: Call to a member
>function getName() on a non-object in

error_reporting set to E_ALL? What browser do you use?

>Maybe it is a php.ini issue? I do not know what can be another reason....
>maybe magicquotes have to do something with this?

First you should fix the error in the redirect. The Location header
requires an absolute URL.

Micha

Marcel
09/11/06, 14:06
"Marcin Dobrucki" <Marcin.Dobrucki@TAKETHISAWAY.nokia.com> schreef in
bericht news:VKm4h.42491$_k2.774821@news2.nokia.com...
> Marcel wrote:
>
>> Yes you are right, the errorcode i am getting is:
>>
>> Fatal error: Call to a member function getName() on a non-object in
>> D:\public_html\person2.php on line 7
>
> One step at a time: what do you get out of "urldecode" and then what do
> you get from "unserialize"? Check the return values.

The unserialize function in person2.php did not return anything. I tried all
scripts on another server with the same PHP version installed and there
everything just worked fine. One difference i can think of is the fact that
the server where my script did not work is protected trough https

Marcin Dobrucki
09/11/06, 14:06
Michael Fesser wrote:
> First you should fix the error in the redirect. The Location header
> requires an absolute URL.

True. But it seems to work with relative URLs as well.

Jerry Stuckle
09/11/06, 14:06
Marcel wrote:
> "Marcin Dobrucki" <Marcin.Dobrucki@TAKETHISAWAY.nokia.com> schreef in
> bericht news:VKm4h.42491$_k2.774821@news2.nokia.com...
>
>>Marcel wrote:
>>
>>
>>>Yes you are right, the errorcode i am getting is:
>>>
>>>Fatal error: Call to a member function getName() on a non-object in
>>>D:\public_html\person2.php on line 7
>>
>> One step at a time: what do you get out of "urldecode" and then what do
>>you get from "unserialize"? Check the return values.
>
>
> The unserialize function in person2.php did not return anything. I tried all
> scripts on another server with the same PHP version installed and there
> everything just worked fine. One difference i can think of is the fact that
> the server where my script did not work is protected trough https
>
>

Marcel,

http vs. https shouldn't make a difference, unless you're trying to mix
the two. That is, storing it in the session when using http and reading
it back with https (or vice versa).

Also, is the domain *exactly* the same? i.e. you don't have one as
www.example.com and the other as example.com?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Michael Fesser
09/11/06, 19:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Michael Fesser
09/11/06, 21:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Michael Fesser
09/11/06, 23:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Michael Fesser
10/11/06, 01:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Michael Fesser
10/11/06, 03:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Michael Fesser
10/11/06, 05:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Michael Fesser
10/11/06, 07:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Michael Fesser
10/11/06, 09:00
..oO(Marcin Dobrucki)

>Michael Fesser wrote:
>> First you should fix the error in the redirect. The Location header
>> requires an absolute URL.
>
> True. But it seems to work with relative URLs as well.

A bug is a bug and should be fixed, especially if you're searching for
the reason of another bug, which could be caused by the first.

Micha

Jerry Stuckle
16/11/06, 02:39
Michael Fesser wrote:
> .oO(Marcin Dobrucki)
>
>
>>Michael Fesser wrote:
>>
>>>First you should fix the error in the redirect. The Location header
>>>requires an absolute URL.
>>
>> True. But it seems to work with relative URLs as well.
>
>
> A bug is a bug and should be fixed, especially if you're searching for
> the reason of another bug, which could be caused by the first.
>
> Micha

Yep, bugs need to be fixed. But how many times do people have to tell
you that PHP is working exactly according to the RFC's?

Additionally, it's not just PHP. It's every browser on the market.
Session ID's are kept in cookies. And even the browsers agree that
example.com is not the same as www.example.com - and will not send a
cookie generated by one host to the other.

If you don't like it, fine. Put in your own RFC and get the entire
internet to change. But don't keep complaining about it being a bug
just because it doesn't work like *you* would like it to. It's been
like that for almost 40 years, since it was arpanet. I know for sure it
was like that in the early 70's when I was on arpanet. And that's the
way it's designed to work.

As much as I hate to tell you, the internet does NOT revolve around Micha.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Michael Fesser
16/11/06, 02:39
..oO(Jerry Stuckle)

>If you don't like it, fine. Put in your own RFC and get the entire
>internet to change. But don't keep complaining about it being a bug
>just because it doesn't work like *you* would like it to.

RFC 2616, section 14.30 "Location":

| The field value consists of a single absolute URI.

Micha

Jerry Stuckle
16/11/06, 02:39
Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>
>>If you don't like it, fine. Put in your own RFC and get the entire
>>internet to change. But don't keep complaining about it being a bug
>>just because it doesn't work like *you* would like it to.
>
>
> RFC 2616, section 14.30 "Location":
>
> | The field value consists of a single absolute URI.
>
> Micha

And there isn't a browser currently made which doesn't understand the
relative URI here.

Agreed the RFC indicates we need to use an absolute URI. And he should
be using one.

But that isn't his problem.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Michael Fesser
16/11/06, 02:39
..oO(Jerry Stuckle)

>And there isn't a browser currently made which doesn't understand the
>relative URI here.

Browsers are not the only user agents. It's impossible to test them all,
so you can't be sure that all of them will handle a relative redirect
with a query string correctly. Some of them even show a warning (Lynx
for example).

>Agreed the RFC indicates we need to use an absolute URI. And he should
>be using one.
>
>But that isn't his problem.

It could be, depending on the used combination of server and browser.
Unlikely, but not impossible.

Micha

Jerry Stuckle
16/11/06, 02:39
Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>
>>And there isn't a browser currently made which doesn't understand the
>>relative URI here.
>
>
> Browsers are not the only user agents. It's impossible to test them all,
> so you can't be sure that all of them will handle a relative redirect
> with a query string correctly. Some of them even show a warning (Lynx
> for example).
>

True, some are better than others. But can you name one http agent
which doesn't understand relative URI's?

>
>>Agreed the RFC indicates we need to use an absolute URI. And he should
>>be using one.
>>
>>But that isn't his problem.
>
>
> It could be, depending on the used combination of server and browser.
> Unlikely, but not impossible.
>
> Micha

Nope. Guaranteed.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Andy Hassall
16/11/06, 02:39
On Sat, 11 Nov 2006 22:31:23 -0500, Jerry Stuckle <jstucklex@attglobal.net>
wrote:

>Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>>And there isn't a browser currently made which doesn't understand the
>>>relative URI here.
>>
>> Browsers are not the only user agents. It's impossible to test them all,
>> so you can't be sure that all of them will handle a relative redirect
>> with a query string correctly. Some of them even show a warning (Lynx
>> for example).
>
>True, some are better than others. But can you name one http agent
>which doesn't understand relative URI's?
[for context: in Location response headers]

If you search Google, you will find several references where HTTP client
libraries in various languages fail when they encounter invalid Location
headers, and some other cases where there are issues with the code added to
work around the invalid Location headers - and so it goes on.

For example, cURL has the following comments:

if(2 != sscanf(newurl, "%15[^?&/:]://%c", prot, &letter)) {
/***
*DANG* this is an RFC 2068 violation. The URL is supposed
to be absolute and this doesn't seem to be that!
***
Instead, we have to TRY to append this new path to the old URL
to the right of the host part. Oh crap, this is doomed to cause
problems in the future...
*/

Followed by 93 lines of trying to sort the mess out.

PHP 4.3.0 apparently core dumped in some situations with relative Location
headers (bug#22283). There was also bug #21267, in CVS the comment on the
changed file was "opening URLs that result in redirection to a relative path
was failing".

The minefield can be avoided by following the spec, or you can hope that all
HTTP client library developers have heard of this issue and have added bug-free
code and that their expectation of what to do in this unspecified case is
consistent with other implementations.

Back in the real world, here's an example, let's call it redirect.php:

<?php
if (isset($_GET['value']))
{
print $_GET['value'];
}
else
{
header('Location: ?value=test');
}
?>

Let's say that's on http://example.com/redirect.php

Access it with Firefox 2.0, IE 7 and Opera 9.02 and you get redirected to:
http://example.com/redirect.php?value=test

Access it with cURL 7.14.0, Lynx 2.8.5 and it takes you to:
http://example.com/?value=test

Access it using PHP 5.2.0's HTTP fopen wrapper and it takes you to:
http://example.com//?value=test
(complete with weird double slash).

I wasn't trying very hard to find a case that would produce inconsistent
results, and I found one straight off. That's enough of an indication of the
can of worms that is opened by not following the standards to continue to
always insist that you always write absolute Location headers.

--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

Andy Hassall
16/11/06, 02:39
On Thu, 09 Nov 2006 23:15:25 -0500, Jerry Stuckle <jstucklex@attglobal.net>
wrote:

>> A bug is a bug and should be fixed, especially if you're searching for
>> the reason of another bug, which could be caused by the first.
>
>Yep, bugs need to be fixed. But how many times do people have to tell
>you that PHP is working exactly according to the RFC's?
>
>Additionally, it's not just PHP. It's every browser on the market.
>Session ID's are kept in cookies. And even the browsers agree that
>example.com is not the same as www.example.com - and will not send a
>cookie generated by one host to the other.

Er, you seem to have crossed threads here? The "session cookies must magically
cross subdomains according to my own arbitrary criteria" guy was on another
thread.

--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

Michael Fesser
16/11/06, 02:39
..oO(Andy Hassall)

> I wasn't trying very hard to find a case that would produce inconsistent
>results, and I found one straight off. That's enough of an indication of the
>can of worms that is opened by not following the standards to continue to
>always insist that you always write absolute Location headers.

I also read multiple times about users having problems with relative
Location headers, especially when there was a query string appended.
This is just one of them (German): <news:ctab04$vns$1@online.de>.

In short: User has a problem with

header("Location: /index.php?pid=5");

His script didn't receive the parameter (like the OP's script). After
fixing it and using an absolute URI it worked as expected. Too bad he
didn't mention the used server and browser.

But he was not the only one encountering this problem.

Micha

Jerry Stuckle
16/11/06, 02:39
Andy Hassall wrote:
> On Sat, 11 Nov 2006 22:31:23 -0500, Jerry Stuckle <jstucklex@attglobal.net>
> wrote:
>
>
>>Michael Fesser wrote:
>>
>>>.oO(Jerry Stuckle)
>>>
>>>
>>>>And there isn't a browser currently made which doesn't understand the
>>>>relative URI here.
>>>
>>>Browsers are not the only user agents. It's impossible to test them all,
>>>so you can't be sure that all of them will handle a relative redirect
>>>with a query string correctly. Some of them even show a warning (Lynx
>>>for example).
>>
>>True, some are better than others. But can you name one http agent
>>which doesn't understand relative URI's?
>
> [for context: in Location response headers]
>
> If you search Google, you will find several references where HTTP client
> libraries in various languages fail when they encounter invalid Location
> headers, and some other cases where there are issues with the code added to
> work around the invalid Location headers - and so it goes on.
>

That isn't what I asked, Andy. And how many of those libraries actually
apply to this problem.

<snip>
>
> Back in the real world, here's an example, let's call it redirect.php:
>
> <?php
> if (isset($_GET['value']))
> {
> print $_GET['value'];
> }
> else
> {
> header('Location: ?value=test');
> }
> ?>
>
> Let's say that's on http://example.com/redirect.php
>
> Access it with Firefox 2.0, IE 7 and Opera 9.02 and you get redirected to:
> http://example.com/redirect.php?value=test
>
> Access it with cURL 7.14.0, Lynx 2.8.5 and it takes you to:
> http://example.com/?value=test
>
> Access it using PHP 5.2.0's HTTP fopen wrapper and it takes you to:
> http://example.com//?value=test
> (complete with weird double slash).
>
> I wasn't trying very hard to find a case that would produce inconsistent
> results, and I found one straight off. That's enough of an indication of the
> can of worms that is opened by not following the standards to continue to
> always insist that you always write absolute Location headers.
>

Again, how does that apply to this problem?

I'm not saying you shouldn't use them. I'm saying that's not the
original poster's problem.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle
16/11/06, 02:39
Andy Hassall wrote:
> On Thu, 09 Nov 2006 23:15:25 -0500, Jerry Stuckle <jstucklex@attglobal.net>
> wrote:
>
>
>>>A bug is a bug and should be fixed, especially if you're searching for
>>>the reason of another bug, which could be caused by the first.
>>
>>Yep, bugs need to be fixed. But how many times do people have to tell
>>you that PHP is working exactly according to the RFC's?
>>
>>Additionally, it's not just PHP. It's every browser on the market.
>>Session ID's are kept in cookies. And even the browsers agree that
>>example.com is not the same as www.example.com - and will not send a
>>cookie generated by one host to the other.
>
>
> Er, you seem to have crossed threads here? The "session cookies must magically
> cross subdomains according to my own arbitrary criteria" guy was on another
> thread.
>

Yep, sorry. It got posted to the wrong thread. Too many windows open! :-)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Andy Hassall
16/11/06, 02:39
On Sun, 12 Nov 2006 17:02:33 -0500, Jerry Stuckle <jstucklex@attglobal.net>
wrote:

>>>True, some are better than others. But can you name one http agent
>>>which doesn't understand relative URI's?
>
[snip the first part of my response]
>
>That isn't what I asked, Andy.

I'll summarise the rest of my post then and repeat the answer: PHP's
fopen_wrappers HTTP user agent doesn't properly (*) understand illegal relative
URIs in Location headers. Amongst others.

(*) whatever properly means here, but it's inconsistent with other well-known
HTTP user agents in this undefined area.

>And how many of those libraries actually apply to this problem.

That isn't what you asked, Jerry!

--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

Jerry Stuckle
16/11/06, 02:39
Andy Hassall wrote:
> On Sun, 12 Nov 2006 17:02:33 -0500, Jerry Stuckle <jstucklex@attglobal.net>
> wrote:
>
>
>>>>True, some are better than others. But can you name one http agent
>>>>which doesn't understand relative URI's?
>>
> [snip the first part of my response]
>
>>That isn't what I asked, Andy.
>
>
> I'll summarise the rest of my post then and repeat the answer: PHP's
> fopen_wrappers HTTP user agent doesn't properly (*) understand illegal relative
> URIs in Location headers. Amongst others.
>
> (*) whatever properly means here, but it's inconsistent with other well-known
> HTTP user agents in this undefined area.
>
>
>>And how many of those libraries actually apply to this problem.
>
>
> That isn't what you asked, Jerry!
>

My question was how many clients have a real problem with it. You
mentioned some client libraries - which are not the same thing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

mannerboy
16/11/06, 02:39
class.A.php
----------------------------------------------
class A
{
var $name;
function A($name = ''){
$this->name = $name;
}
}

source.php
------------------------------
include("class.A.php");
$p = new A('arknoah');
header('Location:dest.php?data='.urlencode(seriali ze($p)));


dest.php
-------------------------------
include("class.A.php");
$q = unserialize(urldecode(stripslashes($_GET['data'])));
//get_magic_quotes_gpc() = 1
echo $q->name;exit;

"Marcel дµÀ£º
"
> I have a person class adn i want to derive an object of that class on one
> page and pass that object to a next page but that does not work for me and i
> do not understand why.
>
> Here is de code:
>
> class.person.php
> -----------------------------------
> class person {
>
> private $_name;
>
> public function setName($name) {
>
> $this->_name = $name;
>
> }
>
> public function getName() {
>
> return $this->_name;
>
> }
>
> }
> --------------------------------------------
>
>
>
> person1.php // here is the object created
> -------------------------------------------
> require_once("class.person.php");
>
> $p = new person();
>
> $p->setName("Jim");
>
> $safep = urlencode(serialize($p));
>
> header("Location:person2.php?data=".$safep);
>
> exit;
>
>
> person2.php // page where the object is transfered to
> ---------------------------------------------------
> require_once("class.person.php");
>
> $p = unserialize(urldecode($_GET['data']));
>
> echo $p->getName();