> -----Original Message----- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Wednesday, February 24, 2016 5:46 PM > To: Sean Dague <s...@dague.net>; openstack-dev@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- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev