tg-php@xxxxxxxxxxxxxxxxxxxxxx wrote: > If your question is a matter of "Is this a good programming practice" then > I think it's ok. There are times when something like this could be really > useful. There are many scripts I write which provide results for either GET or POST data interchangably, so that links or forms can be used in the other pages to fit in with their look/feel. As far as mixing GET/POST goes, one reason for doing it would be this: Suppose throughout your whole site, you are passing $username via GET. But you have a FORM on one page with other information being sent via POST, for the minor convenience benefits that POST provides. To *keep* your username usage consistent, you pass username in the URL being POSTed to. This makes perfect sense to me, even if some don't like the idiom. > Should people get into the practice of using this kind of thing? I think > it really depends on the circumstances and there's definitely times when > it would just make things more confusing which is bad programming practice > in general. > > So unless there's a web server that looks for POST data and ignores any > GET data sent (which I've never heard of but I'm guessing that someone's > managed to create a web server at one point that did this.. on purpose or > not), then I think this is an ok technique if there's not a simpler one > that does the same thing. It's trivial to configure Apache to allow only GET or POST (or neither) for any given directory: http://httpd.apache.org/docs/mod/core.html#limit > Simplicity is really the key, but it's nice to know that you CAN use GET > and POST together if you want/need to. Just as long as it's not > complicating the situation for no reason. > = = = Original message = = = > > Browser history: I do not want it to contain any URIs to files which > require > some sort of id variable passed. > > Example: > 1. http://www.entity.org/edit.php > (should produce an error or redirect to entity list) > > 2. http://www.entity.org/edit.php?id=1 > (should display editing interface) > > Now I really do not like to use redirects in case of errors. So I could > constantly use (2) second form of URI, even in POST requests. > > But then, if I already have "id" in $_GET, why the redundancy of sending > another "id" to $_POST? Don't send the "id" in $_POST. That's too confusing -- to have the same thing coming in via two vehicles. You *can* do it, and consistently use either $_POST or $_GET to read the variable, and ignore the other one, but why send data you *know* you'll ignore? >> Is it just me or ... why on earth would you want to populate both GET >> and >> POST arrays through this obscure way of coding ? See above. >> If you really have a form where you dont have a clue wether your data >> comes >> from GET or POST, It's more like: "I don't care if the other programmer asks for my content via GET or POST, I'll give it to him either way." >> > Now what I am interested in is if this is valid behaviour regarding >> HTTP >> > specification and if other platforms support this interference of GET >> and >> > POST variables in request? Completely valid, and that's why PHP has settings in php.ini to determine precisely which ones over-ride with others in $_REQUEST (an array combining POST+GET+COOKIES) as well as in the global variables if you turn register_globals "ON" which you shouldn't. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
