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

[Back to original message]