From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Wolfgang Bumiller <w.bumiller@proxmox.com>
Subject: Re: [pve-devel] applied: [PATCH http-server v3 1/2] proxy request: forward json content type and parameters
Date: Wed, 7 Jun 2023 14:14:37 +0200 [thread overview]
Message-ID: <c95abd41-54d5-44c5-357d-2b075216165b@proxmox.com> (raw)
In-Reply-To: <iazko36nnxk67pmy5rcsos7i4snhotn5t3bofkzeazmgb2uial@rc6a7hw72nt4>
Am 07/06/2023 um 14:08 schrieb Wolfgang Bumiller:
> On Wed, Jun 07, 2023 at 01:59:26PM +0200, Thomas Lamprecht wrote:
>> Am 07/06/2023 um 13:49 schrieb Dominik Csapak:
>>>
>>>
>>> On 6/7/23 13:47, Thomas Lamprecht wrote:
>>>> Am 07/06/2023 um 13:23 schrieb Wolfgang Bumiller:
>>>>> applied both & bumped dependency for pve-common
>>>>>
>>>>
>>>> Isn't this breaking older common too?
>>>>
>>>
>>> no it just forwards the parameters to either the daemon or the other nodes as json if the proxy received it as json, should not have
>>> any other effects...
>>
>> not this one 2/2, just replied here as it was the applied patch
>
> Meh, I suppose technically it does, but requires a... broken(?) client
> to trigger it, since no API endpoints with arrays which reach this case
> existed before?
>
But Dominik writes in a reply to 2/2:
>
> this patch breaks pve-common without the common 1/3 applied
> since the gui sends arrays when the api expects a '-list'
> and the api treats '-list' and '-alist' the same
I.e., this breaks manager, and the workaround for that is in common, so either
http-server breaks older manager (i.e., the version before increasing the
versioned dependency for libpve-common-perl >= the one containing 1/3 in manager.
Alternatively this could break older libpve-common-perl, enforcing that manager
always gets a workable set of packages for it's state.
But not doing any breaks, if Dominik's reply is correct, is just plain wrong.
(Potentially) breaking external client's is then something else, not fully ideal
but if risk was evaluated and deemed impractical then OK, otherwise it's a rather
less ideal..
next prev parent reply other threads:[~2023-06-07 12:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 13:08 [pve-devel] [PATCH common/http/guest-common/qemu-server v3] schema/config array support Dominik Csapak
2023-06-06 13:08 ` [pve-devel] [PATCH common v3 1/3] JSONSchema: add support for array parameter in api calls, cli and config Dominik Csapak
2023-06-07 11:15 ` [pve-devel] applied: " Wolfgang Bumiller
2023-06-06 13:08 ` [pve-devel] [PATCH common v3 2/3] section config: implement array support Dominik Csapak
2023-06-06 13:08 ` [pve-devel] [PATCH common v3 3/3] JSONSchema: disable '-alist' format Dominik Csapak
2023-06-06 13:08 ` [pve-devel] [PATCH http-server v3 1/2] proxy request: forward json content type and parameters Dominik Csapak
2023-06-07 11:23 ` [pve-devel] applied: " Wolfgang Bumiller
2023-06-07 11:47 ` Thomas Lamprecht
2023-06-07 11:49 ` Dominik Csapak
2023-06-07 11:59 ` Thomas Lamprecht
2023-06-07 12:08 ` Wolfgang Bumiller
2023-06-07 12:14 ` Thomas Lamprecht [this message]
2023-06-07 12:23 ` Wolfgang Bumiller
2023-06-07 12:25 ` Wolfgang Bumiller
2023-06-07 12:32 ` Thomas Lamprecht
2023-06-06 13:08 ` [pve-devel] [PATCH http-server v3 2/2] use proper arrays for array parameter Dominik Csapak
2023-06-07 5:24 ` Dominik Csapak
2023-06-06 13:08 ` [pve-devel] [PATCH guest-common v3 1/1] vzdump: change 'exclude-path' from alist to an array format Dominik Csapak
2023-06-07 11:43 ` [pve-devel] applied: " Wolfgang Bumiller
2023-06-06 13:08 ` [pve-devel] [PATCH qemu-server v3 1/1] api: switch agent api call to 'array' type Dominik Csapak
2023-06-07 11:55 ` [pve-devel] applied: " Wolfgang Bumiller
2023-06-07 11:55 ` [pve-devel] applied-series: [PATCH common/http/guest-common/qemu-server v3] schema/config array support Wolfgang Bumiller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c95abd41-54d5-44c5-357d-2b075216165b@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=w.bumiller@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox