[openstack-dev] [nova] solving API case sensitivity issues

Mooney, Sean K sean.k.mooney at intel.com
Wed Feb 24 20:13:31 UTC 2016



> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com]
> Sent: Wednesday, February 24, 2016 5:46 PM
> To: Sean Dague <sean at dague.net>; openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] solving API case sensitivity issues
> 
> On Wed, 2016-02-24 at 11:40 -0500, Sean Dague wrote:
> > On 02/24/2016 11:28 AM, James Bottomley wrote:
> > > On Wed, 2016-02-24 at 07:48 -0500, Sean Dague wrote:
> > > > We have a specific bug around aggregrate metadata setting in Nova
> > > > which exposes a larger issue with our mysql schema.
> > > > https://bugs.launchpad.net/nova/+bug/1538011
> > > >
> > > > On mysql the following will explode with a 500:
> > > >
> > > > > nova aggregate-create agg1
> > > > > nova aggregate-set-metadata agg1 abc=1 nova
> > > > > aggregate-set-metadata agg1 ABC=2
> > > >
> > > > mysql (by default) treats abc == ABC. However the python code does
> > > > not.
Personally I would argue that the python code is correct
and they should not be considered the same. ABC and abc are two different keys
in the aggregate metadata and I do not think it is correct to treat them the same.
Assuming the above commands I would expect the metadata to contain  two key pairs [abc=1,ABC=2]

> > > >
> > > > We have a couple of options:
> > > >
> > > > 1) make the API explicitly case fold
> > > >
> > > > 2) update the mysql DB to use latin_bin collation for these
> > > > columns
This should not be latin_bin as Unicode is allowed in URLs this should really be utf8_bin
> > > >
> > > > 3) make this a 400 error because duplicates were found
> > > >
> > > >
> > > > Options 1 & 2 make all OpenStack environments consistent
> > > > regardless of backend.
> > > >
> > > > Option 2 is potentially expensive TABLE alter.
> > > >
> > > > Option 3 gets rid of the 500 error, however at the risk that the
> > > > behavior for this API is different depending on DB backend. Which
> > > > is less than ideal.
> > > >
> > > >
> > > > My preference is slightly towards #1. It's taken a long time for
> > > > someone to report this issue, so I think it's an edge case, and
> > > > people weren't think about this being case sensitive. It has the
> > > > risk of impacting someone on an odd db platform that has been
> > > > using that feature.
> > > >
> > > > There are going to be a few other APIs to clean up in a similar
> > > > way.
> > > > I don't think this comes in under a microversion because of how
> > > > deep in the db api layer this is, and it's just not viable to keep
> > > > both paths.
> > >
> > > This is actually one of the curses wished on us by REST.  Since the
> > > intent is to use web requests for the API, the API name must follow
> > > the case sensitivity rules for URL matching (case insensitive).
> >
> > Um... since when are URLs generically case insensitive? The host
> > portion is - https://tools.ietf.org/html/r
> > https://tools.ietf.org/html/rfc3986#section-3.2.2c3986#section-3.2.2
> > and the scheme
> > portion is - https://tools.ietf.org/html/rfc3986#section-3.1 however
> > nothing about the PATH specifies that it should or must be (in section
> > 3.3)
I would agree with this we should not assume that URLs are case sensitive nor should
We assume they are ascii. I would be in favor of option 2 with utf8_bin as this support
Both Unicode and case sensitivity.
> 
> Heh, OK, I'm out of date.  When we first argued over this, Microsoft
> required case insensitive matching for the path component because IIS
> was doing lookups on vfat filesystems which are naturally case
> insensitive.  If that's been excised from the standard, I'm happy to
> keep it in the dustbin of history.
> 
> > While it's a little off topic, this is the 2nd time in a month it came
> > up, so I'd like to know if there is a reference for the case
> > insensitive pov.
> 
> I checked; it looks to be implementation specific.  So php, for
> instance, does case sensitive
> 
> /index.php != /Index.php
> 
> But drupal does case insensitive
> 
> /node/6 == /Node/6 == /NoDe/6
> 
> So all in all, a bit of a mess.
> 
> James
> 
> 
> ________________________________________________________________________
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list