On Fri, February 24, 2012 5:15 pm, Larry Garfield wrote:
> On 2/24/12 4:55 PM, Jeremiah Dodds wrote:
>
>>> Except that per HTTP, GET and POST are completely different
>>> operations. One
>>> is idempotent and cacheable, the other is not idempotent and not
>>> cacheable.
>>> I very much care whic
On Mon, Feb 27, 2012 at 6:17 PM, Richard Lynch wrote:
> On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote:
> > On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
> > wrote:
> >>> To me, it's just a request for some content, and in a REST API
> >>> that's
> >>> read-only, I just don't care if t
On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote:
> On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
> wrote:
>>> To me, it's just a request for some content, and in a REST API
>>> that's
>>> read-only, I just don't care if the consumer sends their request as
>>> GET or POST. I'll cheerfully
On Fri, February 24, 2012 4:40 pm, Larry Garfield wrote:
> On 2/24/12 4:34 PM, Richard Lynch wrote:
>> On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
>>> On 2/24/12 3:28 PM, Richard Lynch wrote:
> Except that per HTTP, GET and POST are completely different
> operations.
> One is idempo
On 2/24/12 4:55 PM, Jeremiah Dodds wrote:
Except that per HTTP, GET and POST are completely different operations. One
is idempotent and cacheable, the other is not idempotent and not cacheable.
I very much care which someone is using.
Correct me if I'm wrong, but you're referring to the HTT
On 2/24/12 5:04 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield wrote:
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
Except that per HTTP, GET and POST are completely different operations.
One
is idempotent and cacheable,
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield wrote:
> On 2/24/12 4:48 PM, Ronald Chmara wrote:
>>
>> On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
>>> Except that per HTTP, GET and POST are completely different operations.
>>> One
>>> is idempotent and cacheable, the other is not idempotent
On Fri, Feb 24, 2012 at 5:40 PM, Larry Garfield wrote:
> On 2/24/12 4:34 PM, Richard Lynch wrote:
>>
>> On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
>>>
>>> On 2/24/12 3:28 PM, Richard Lynch wrote:
>>> Because GET and POST are not even remotely the same thing and treating
>>> them as c
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield wrote:
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.
Ex
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield wrote:
>> To me, it's just a request for some content, and in a REST API that's
>> read-only, I just don't care if the consumer sends their request as
>> GET or POST. I'll cheerfully give them what they wanted.
> Except that per HTTP, GET and POST a
On 2/24/12 4:34 PM, Richard Lynch wrote:
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
On 2/24/12 3:28 PM, Richard Lynch wrote:
Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place.
We'll have to agree
On Friday, February 24, 2012 at 5:16 PM, Larry Garfield wrote:
> On 2/24/12 3:28 PM, Richard Lynch wrote:
> > On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
> > > $_REQUEST does nothing of the sort, and it's use is dangerous in
> > > RESTful architecture. $_REQUEST is a smash together of
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
> On 2/24/12 3:28 PM, Richard Lynch wrote:
> Because GET and POST are not even remotely the same thing and treating
> them as completely interchangeable is a bug in the first place.
We'll have to agree to disagree here.
To me, it's just a r
On 2/24/12 3:28 PM, Richard Lynch wrote:
On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can chang
On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
> $_REQUEST does nothing of the sort, and it's use is dangerous in
> RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
> and $_COOKIE, in that order but the php.ini directive can change it.
> Hence there's no way of knowin
On Wed, February 22, 2012 8:57 am, Michael Morris wrote:
> Before writing up a full RFC I want to put out a feeler on something.
> Currently we have several input parameter objects, chief among them
> $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
> of them are arrays and le
Yes, I'm agree with Will Fitch.
Handling this problem with PHP is a good idea and beneficial to programmer.
2012/2/23 Ángel González
> On 22/02/12 15:57, Michael Morris wrote:
> > Before writing up a full RFC I want to put out a feeler on something.
> > Currently we have several input paramet
On 22/02/12 15:57, Michael Morris wrote:
> Before writing up a full RFC I want to put out a feeler on something.
> Currently we have several input parameter objects, chief among them
> $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
> of them are arrays and legacy code someti
On Wed, 2012-02-22 at 09:57 -0500, Michael Morris wrote:
> Before writing up a full RFC I want to put out a feeler on something.
> Currently we have several input parameter objects, chief among them
> $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
> of them are arrays and le
On Wednesday, February 22, 2012 at 10:10 AM, Michael Morris wrote:
> $_REQUEST does nothing of the sort, and it's use is dangerous in
> RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
> and $_COOKIE, in that order but the php.ini directive can change it.
> Hence there's no way
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET,
Personally, I don't like this. We already have $_REQUEST which can accommodate
GET, POST, and COOKIE. I believe it should be up to framework/API authors to
implement there own methodologies behind accessing this data. Additional
functionality such as setting filters would be a part of that as
Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only ob
23 matches
Mail list logo
