[pve-devel] applied: [PATCH http-server v3 1/2] proxy request: forward json content type and parameters

[Thomas Lamprecht]

Am 07/06/2023 um 14:25 schrieb Wolfgang Bumiller:
> On Wed, Jun 07, 2023 at 02:23:36PM +0200, Wolfgang Bumiller wrote:
>> On Wed, Jun 07, 2023 at 02:14:37PM +0200, Thomas Lamprecht wrote:
>>> 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.
>>
>> Right, I'll add a breaks entry for common.
> 
> Actually this has a *depends* on newer common?
> 

Yes, I read it backwards, seems this is fine – I'll check more calmly first next time,
sorry.