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

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