perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Ho <and...@tellme.com>
Subject Re: [OT]: POST/GET semantics
Date Wed, 11 Apr 2001 17:45:52 GMT
Hello,

JZ>I have found that having a session object is a rather bad idea. What
JZ>happens if there is such a beast is essentially communication of
JZ>functions through global variables. So I thought about the cure and
JZ>found that having server side "objects" that can be retrieved through an
JZ>id enables "passing of parameters by reference". The client does a
JZ>request and gets an id with the response, which he will return to the
JZ>server with further requests to refer to an object created with the
JZ>first request.

What you describe is exactly, I think, what most people think of when they
talk about a session object. The client must always somehow indicate who
they are, so you know what session to associate them with.

JZ>The question however is: If I create an object on the server that is
JZ>only accessible to the requesting client (the id can be thaught of as a
JZ>password) - may this be done with a GET request? RFC 2616 says that the
JZ>idea of GET is that the client can not be held accountable for the side
JZ>effects of GET. If I however return an id to the client so that only
JZ>this client has access to the effects of the request this client is in
JZ>full control.

It can be done with either GET or POST. However, if you use GET, you have
to prepare for receiving GET requests possibly more than once (although
sending Cache-Control headers should minimize this). In your case, since
your search application does not change any permanent server state, it's
fine to use either GET or POST.

Note: in HTTP, the client is ALWAYS in "full control". HTTP is always a
client-pull model. Whether you use GET or POST, the client can always
choose to replay a previous request. So you have to prepare to handle this
case no matter what.

You may want to read the chapter on server-side state in the Eagle book.

Humbly,

Andrew

----------------------------------------------------------------------
Andrew Ho               http://www.tellme.com/       andrew@tellme.com
Engineer                   info@tellme.com          Voice 650-930-9062
Tellme Networks, Inc.       1-800-555-TELL            Fax 650-930-9101
----------------------------------------------------------------------


Mime
View raw message