Re: GET/POST parameters question

>From my experience combining them can be pretty useful and I dont really
see any reason it shouldnt be allowed, but one important thing is that you
make sure that the server properly seperates any parameters you get by
their origin (post, get, cookies, anything else) or otherwise you may land
in some serious chaos (while on an API I doubt you would have users end in
that by any malicious means, if one on accident chooses a name for a
varable for POST that already exists in GET and you need both at the same
time and they arent seperated it wont be fun.

In other words do not use $_REQUEST of PHP or any equivalent in any given
language, but instead target post, get etc parameters specifically and you
are fine.

Regards.

Am Di., 12. Juni 2018 um 00:56 Uhr schrieb Grahame Grieve <
grahame@healthintersections.com.au>:

> thank you both
>
> Grahame
>
>
> On Tue, Jun 12, 2018 at 7:20 AM, Willy Tarreau <w@1wt.eu> wrote:
>
>> On Mon, Jun 11, 2018 at 02:05:00PM -0700, Roy T. Fielding wrote:
>> > Presumably, an application will use parameters when
>> > and where desired. If not desired, a 404 error is a normal response.
>>
>> Several years ago for an application I was working on, I explicitly
>> wanted to support both url-params and body for POST requests because
>> for me they are completely different and orthogonal beasts. But I
>> found that it doesn't cope well with a number of application frameworks
>> which are confused because (probably due to inheritance of the old days
>> of CGI), for them a parameter is a parameter, wherever it's found, so
>> these were completely mixed at various places in the chain. Thus I
>> gave up, a bit sadly, considering that I was prevented from doing it
>> just due to the risk of poor interoperability at some places and not
>> for any technical reason.
>>
>> Cheers,
>> Willy
>>
>
>
>
> --
> -----
> http://www.healthintersections.com.au / grahame@healthintersections.com.au
> / +61 411 867 065
>