**WARNING** longer post that usual **WARNING** longer post that usual **WARNING**
At 07:54 12.11.2002, Chris Shiflett said: --------------------[snip]-------------------- >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?). --------------------[snip]-------------------- 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 superglobal... 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 POST, PUT 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. However, 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 side effects, caches MUST NOT treat responses to such URIs as fresh unless 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
