You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Joachim Zobel <nc...@netcologne.de> on 2001/04/11 13:58:38 UTC
[OT]: POST/GET semantics
Hi.
I have found that having a session object is a rather bad idea. What
happens if there is such a beast is essentially communication of functions
through global variables. So I thought about the cure and found that having
server side "objects" that can be retrieved through an id enables "passing
of parameters by reference". The client does a request and gets an id with
the response, which he will return to the server with further requests to
refer to an object created with the first request.
The question however is: If I create an object on the server that is only
accessible to the requesting client (the id can be thaught of as a
password) - may this be done with a GET request? RFC 2616 says that the
idea of GET is that the client can not be held accountable for the side
effects of GET. If I however return an id to the client so that only this
client has access to the effects of the request this client is in full control.
An application for this would be to have a request that creates a result
set for an expensive search and returns an id to this.
Any comments appreciated,
Joachim
Is there a better place to discuss such a question?
--
"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden
koennen." - Bertolt Brecht - Leben des Galilei
Re: [OT]: POST/GET semantics
Posted by Joachim Zobel <nc...@netcologne.de>.
At 10:45 11.04.2001 -0700, Andrew Ho <an...@tellme.com> wrote:
>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.
No. I have found that having a session object creates maintenance problems.
People start to pass things on the server side. Pages depend on a certain
order of calling to work properly. Pretty soon the session object holds 30
properties (or however you call them). Noboby knows what they do, nobody
knows why they are there. The (anti-)pattern for this is "communication of
functions through global variables".
So what I want is replace the session object by multiple objects that are
refered to by ids that are _explicitely_ passed as parameters. This looks
exactly like "passing parameters by reference".
In general I think that people are pretty much obscured by objects. Things
get pretty straight forward if I think of HTTP requests as function calls.
Joachim
--
"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden
koennen." - Bertolt Brecht - Leben des Galilei
Re: [OT]:/GET header
Posted by Wim Kerkhoff <wi...@merilus.com>.
dreamwvr@dreamwvr.com wrote:
>
> hi,
> anyone recall howto get 'only' the initial header from http servers?
> TIA
HEAD is the command you want:
cuvarack:~/$ telnet impetus 80
Trying 192.168.20.3...
Connected to impetus.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 11 Apr 2001 18:24:40 GMT
Server: Apache/1.3.17 (Unix) mod_perl/1.25 mod_ssl/2.8.0 OpenSSL/0.9.6
Content-Length: 787
Connection: close
Content-Type: text/html
Connection closed by foreign host.
cuvarack:~/$
--
Regards,
Wim Kerkhoff, Software Engineer
Merilus, Inc. -|- http://www.merilus.com
Email: wim@merilus.com
Re: [OT]:/GET header
Posted by dr...@dreamwvr.com.
hi,
anyone recall howto get 'only' the initial header from http servers?
TIA
Re: [OT]: POST/GET semantics
Posted by Andrew Ho <an...@tellme.com>.
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
----------------------------------------------------------------------