Re: GET/POST parameters question

Philipp Junghannß <teamhydro55555@gmail.com> Tue, 12 June 2018 09:39 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB4513112B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Jun 2018 02:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.76
X-Spam-Level:
X-Spam-Status: No, score=-7.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo0-IzlAmFM5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Jun 2018 02:39:10 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F67131133 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 Jun 2018 02:39:10 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1fSfiz-0004tu-5m for ietf-http-wg-dist@listhub.w3.org; Tue, 12 Jun 2018 09:36:25 +0000
Resent-Date: Tue, 12 Jun 2018 09:36:25 +0000
Resent-Message-Id: <E1fSfiz-0004tu-5m@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <teamhydro55555@gmail.com>) id 1fSfiv-0004rn-Ep for ietf-http-wg@listhub.w3.org; Tue, 12 Jun 2018 09:36:21 +0000
Received: from mail-oi0-f41.google.com ([209.85.218.41]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <teamhydro55555@gmail.com>) id 1fSfis-0007iZ-PT for ietf-http-wg@w3.org; Tue, 12 Jun 2018 09:36:20 +0000
Received: by mail-oi0-f41.google.com with SMTP id e8-v6so20514885oii.2 for <ietf-http-wg@w3.org>; Tue, 12 Jun 2018 02:35:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FVeiuZ/D2mahNX4n19detRcv7UjvqgjXGkIa+YK4N/8=; b=tKiW4WnfcVe281J9bT1no3b1ZSizLSK66oS3zBxjFUq+viVJvvExrjKwNOSHv4C+Og 0vdQJ9Y/fnq+4VhNvuovYjHiOpH3emGM1+fX8ZBN8d7eZm4EVE+RZoLY2ghWP7Ew3ZzX YIYu74n/br+jJrFfmUre0slnGn/FpDdRum4P9cVD5xKoetufZEGj9b4WKt4DOBnCxN3U n694UhZrqhY4tLaUT0OYYN/RV71zmdXOq8s+icoYHhietoJ9H9vPlE67Z+p+h6WJ2o8d Kw32cP3TAkNi/zt5RrwPqPrnj7edbcOuWDjrxE+OiLAO2MKJD1HSYR4XKG3Z6hMX8euj pNyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FVeiuZ/D2mahNX4n19detRcv7UjvqgjXGkIa+YK4N/8=; b=LgVA5sE/Aa9cQEMaG+8AEnItOyUmsdghihZ2xX9f0ne0SvI3c00LlvDytxTUpICH6t D2z1EaWTuOjVxGYwwkoPI3pYt1/DQ6bMyrpCmI6Z2Azb5PMFavjluVVhS2pioR9TV1Pt g0hxC54or/7cpu2+lSQmB09RHlT7WfdA4w2B3CnijC3rUp8C6maotWwriFs+e96mdUX7 qUf5sDbLYTS9833u2XrWD/+Vhs1lO1QIkxiIu5Wiaj2s0+WZz+7E0jG09f8JhX7WoHJh u40GoKOCwF57/2N1WhncTSuVjP7QsiXF4W/MYThWmFmMT5WNYH6NUlGDI3116/e7vpi9 M94A==
X-Gm-Message-State: APt69E2rTky7qSuxRkXOCYY5GvSjxyRHjuhCE1xq/BzSZnph5ORb3axn V5apLGdazxrFEvzwNtwjG6RDeTFBBnfaFEAyXbnHmFa7
X-Google-Smtp-Source: ADUXVKJhoYJSPrCLIRQn2GI/4ruRMPMsi/LAA4vfrAigRCqiu02atF7LbRj6M0p+5UdPWOAmaIoaKEDEbb2bxMc6+5g=
X-Received: by 2002:aca:4c0d:: with SMTP id z13-v6mr1389906oia.343.1528796157970; Tue, 12 Jun 2018 02:35:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAG47hGbUL_vLuUcnTf71E-bU87fg5w_WhrVRcvnQQ39JSL0N8A@mail.gmail.com> <A117A789-61A8-456B-9AFC-4D5D96658DAA@gbiv.com> <20180611212057.GA2779@1wt.eu> <CAG47hGbWeGR-qFM_ivohcM1oVwx9ftNn_82rvHhcYMohEF0D=w@mail.gmail.com> <CACHSkNr1mu-3=itNwHkGBPWfh5SWK5c2Z77-NtdoCoGo19-Abg@mail.gmail.com> <CAG47hGbfF677OKOyU8sZSm003OCaiDfNo-0VrDT6HC7xvQbgiw@mail.gmail.com> <1F087959-0E85-4229-BCE6-CAB179E14725@manicode.com>
In-Reply-To: <1F087959-0E85-4229-BCE6-CAB179E14725@manicode.com>
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>
Content-Type: multipart/alternative; boundary="000000000000ee0ed5056e6e9750"
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=-0.880, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1fSfis-0007iZ-PT 028c0d0de7f9193cd19393c74d59b946
X-Original-To: ietf-http-wg@w3.org
Subject: Re: GET/POST parameters question
Archived-At: <https://www.w3.org/mid/CACHSkNo5pt0ny6WLh2__=9gAd5zZe8hQFLdith7ZrarzT=yUtw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35538
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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
>
>