|
|
Posted by Richard Lynch on 10/04/65 11:05
tg-php@gryffyndevelopment.com 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
Navigation:
[Reply to this message]
|