W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: GET/POST parameters question

From: Philipp Junghannß <teamhydro55555@gmail.com>
Date: Tue, 12 Jun 2018 11:35:21 +0200
Message-ID: <CACHSkNo5pt0ny6WLh2__=9gAd5zZe8hQFLdith7ZrarzT=yUtw@mail.gmail.com>
To: jim@manicode.com
Cc: Grahame Grieve <grahame@healthintersections.com.au>, Willy Tarreau <w@1wt.eu>, fielding@gbiv.com, HTTP Working Group <ietf-http-wg@w3.org>
and that is not just for pre-rest.

HTTP isnt just for Rest APIs but also for websites and when you have one
endpoint capable of doing multiple things you obviously throw what generic
thing to do into the GET because you want it as a link.

when you now want to POST something on that page the advantage if that your
script doesnt need to put the get parameters into the form as hidden inputs
or whatever but they just come along as get parameters because they have
already been there, which simplifies it a bit.

Am Di., 12. Juni 2018 um 01:30 Uhr schrieb Jim Manico <jim@manicode.com>:

> Pre REST I might want to add non-sensitive data to my action to determine
> WHAT action I want from a service endpoint. Like...
>
> https://posting.something.com/to?action=updateUser
>
> ... then I want my sensitive data in the POST payload/body. This is old
> school but not uncommon.
>
> But in my world I would never clobber URL and payload variable names so
> these issues never showed up.
>
> Aloha, Jim
>
> On Jun 11, 2018, at 6:11 PM, Grahame Grieve <
> grahame@healthintersections.com.au> wrote:
>
> why is it useful?
>
> grahame
>
>
> On Tue, Jun 12, 2018 at 9:10 AM, Philipp Junghannß <
> teamhydro55555@gmail.com> wrote:
>
>> 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
>>>
>>
>
>
> --
> -----
> http://www.healthintersections.com.au / grahame@healthintersections.com.au
> / +61 411 867 065
>
>
Received on Tuesday, 12 June 2018 09:36:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC