Re: U

On Wed, January 16, 2008 2:17 pm, Stefan Esser wrote: > It would have been a good idea to have such a configuration option > that > allows to specify what is in _REQUEST and what not... Perhaps it would be wise to add yet another php.ini setting? [Yeah, I know the usual response to that. Just think about it, okay?] Or, perhaps, consider dropping COOKIE from _REQUEST?... I know I never quite understood why COOKIE was put into there in the first place, from a pragmatic stand-point... Sure, it's data coming to the HTTP request from the outside, but I've never really found it useful to have it in there. Does anybody have any real-world use for COOKIE data in _REQUEST? I have, obviously, found it useful for a web service (idempotent) to not really care if the data came from POST or GET in the bad old days of no CSS re-styling links/buttons. I think using $_REQUEST for a non-idempotent operation would be sheer follow, personally, since you're just ASKING search engines to wreak havoc on your site... I'm not sure how/where that would be best explained to the masses on php.net, or even if it would be appropriate to do so, but perhaps it would. Providing $_REQUEST without explaining what a legitimate usage is, and what a dangerous usage is, seems like a "Bad Idea" (tm). Perhaps something like: "$_REQUEST should be used only to allow using POST data in addition to GET data, never the other way around. Using $_REQUEST for operations non-idempotent operations (link to RFC) will cause search engines to carry out data-changing operations on your site." I'm sure the Doc guys could write this better, but it's a start... @Stefan Esser: Are you subscribed to php-internals@ or were you dragged into this by an off-list Cc:? (I.e., should I keep Cc:-ing you?) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So?