**WARNING** longer post that usual **WARNING** longer post that usual

At 07:54 12.11.2002, Chris Shiflett said:
>Anyway, thanks for your insight. Some of these slightly off-topic issues 
>are more interesting than the on-topic ones. :-) Maybe our community 
>needs a historian to collect some of this information for those of us 
>who are interested (or am I the only one?).

It's slightly more than historical - in fact the behavior of GET and POST
is quite clearly laid out in RFC2616
(http://ftp.rfc-editor.org/in-notes/rfc2616.txt) which represents the
"proposed standard" for HTTP/1.1.

To start with, data passed within the URI is called "query", as laid out in
rfc2616, 3.2.2:

        3.2.2 http URL

           The "http" scheme is used to locate network resources via the HTTP
           protocol. This section defines the scheme-specific syntax and
           semantics for http URLs.

           http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Si I assume the "correct" way to call our GET variables would be query
variables, and the $_GET superglobal should rather be the $_QUERY

Rfc2616 also deals with the server side implications of GET and POST methods:

        9.1.1 Safe Methods

           Implementors should be aware that the software represents the
user in
           their interactions over the Internet, and should be careful to allow
           the user to be aware of any actions they might take which may
have an
           unexpected significance to themselves or others.

           In particular, the convention has been established that the GET and
           HEAD methods SHOULD NOT have the significance of taking an action
           other than retrieval. These methods ought to be considered "safe".
           This allows user agents to represent other methods, such as
           and DELETE, in a special way, so that the user is made aware of the
           fact that a possibly unsafe action is being requested.

           Naturally, it is not possible to ensure that the server does not
           generate side-effects as a result of performing a GET request; in
           fact, some dynamic resources consider that a feature. The important
           distinction here is that the user did not request the side-effects,
           so therefore cannot be held accountable for them.

In plain english, developers SHOULD use $_GET variables only to _compose_
information, not to take some action to _create_ information. We should
always be aware that an URI can always be saved in a link collection
("Favirites"), or used as a link target, as opposed to POSTed data.

        9.5 POST

           The POST method is used to request that the origin server accept the
           entity enclosed in the request as a new subordinate of the resource
           identified by the Request-URI in the Request-Line. POST is designed
           to allow a uniform method to cover the following functions:

              - Annotation of existing resources;

              - Posting a message to a bulletin board, newsgroup, mailing list,
                or similar group of articles;

              - Providing a block of data, such as the result of submitting a
                form, to a data-handling process;

              - Extending a database through an append operation.

           The actual function performed by the POST method is determined
by the
           server and is usually dependent on the Request-URI. 

           Responses to this method are not cacheable, unless the response
           includes appropriate Cache-Control or Expires header fields.
           the 303 (See Other) response can be used to direct the user agent to
           retrieve a cacheable resource.


This is as clear as it can be - use POST to perform server-side actions
with side effects, like creating a database entity, modifying/deleting a
document, etc. Contrary to GET, a POST URI cannot be saved or hyperlinked
to, at least not in conjunction with posted data.

Of course the RFC is quite alert of any side effects that might be
introduced by us developers ;-> and adds as a note:

        13.9 Side Effects of GET and HEAD

           Unless the origin server explicitly prohibits the caching of their
           responses, the application of GET and HEAD methods to any resources
           SHOULD NOT have side effects that would lead to erroneous
behavior if
           these responses are taken from a cache. They MAY still have side
           effects, but a cache is not required to consider such side
effects in
           its caching decisions. Caches are always expected to observe an
           origin server's explicit restrictions on caching.

           We note one exception to this rule: since some applications have
           traditionally used GETs and HEADs with query URLs (those
containing a
           "?" in the rel_path part) to perform operations with significant
           effects, caches MUST NOT treat responses to such URIs as fresh
           the server provides an explicit expiration time. This specifically
           means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
           be taken from a cache. See section 9.1.1 for related information.

It is beyond my knowledge why this rule is seemingly ignored most of the
time - maybe most web servers automatically include their default cache
mime headers in a response to a GET request, ignoring if it contains a
query or not.

Personally I try to use GET (with or without a session identifier) only in
application environments that are not security related. When a user is
logged in, and this login gets recorded in a SID that is part of a GET
request URI, this session can easily ba shared among others while it is
active. That wouldn't even be session "hijacking" as it is acceptable to
pass an URI along...

But that would be the topic of another thread.

Sorry for the long post, but I believe it is important to have a look at
the relevant standards from time to time.

   >O     Ernest E. Vogelsinger
   (\)    ICQ #13394035
    ^     http://www.vogelsinger.at/

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to