> -----Original Message----- > From: Ian Cordasco [mailto:ian.corda...@rackspace.com] > Sent: Friday, July 24, 2015 4:58 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [glance][api] Response when a illegal body is > sent > > > > On 7/23/15, 19:38, "michael mccune" <m...@redhat.com> wrote: > > >On 07/23/2015 12:43 PM, Ryan Brown wrote: > >> On 07/23/2015 12:13 PM, Jay Pipes wrote: > >>> On 07/23/2015 10:53 AM, Bunting, Niall wrote: > >>>> Hi, > >>>> > >>>> Currently when a body is passed to an API operation that explicitly > >>>> does not allow bodies Glance throws a 500. > >>>> > >>>> Such as in this bug report: > >>>> https://bugs.launchpad.net/glance/+bug/1475647 This is an example > >>>> of a GET however this also applies to other requests. > >>>> > >>>> What should Glance do rather than throwing a 500, should it return > >>>> a > >>>> 400 as the user provided an illegal body > >>> > >>> Yep, this. > >> > >> +1, this should be a 400. It would also be acceptable (though less > >> preferable) to ignore any body on GET requests and execute the > >> request as normal. > >> > >>> Best, > >>> -jay > > > >i'm also +1 on the 400 band wagon > > 400 feels right for when Glance is operating without anything in front of it. > However, let me present a hypothetical situation: > > Company X is operating Glance behind a load-balancing proxy. Most users > talk to Glance behind the LB. If someone writes a quick script to send a GET > and (for whatever reason) includes a body, they'll get a 200 with the data > that would otherwise have been sent if they didn't include a body. > This is because most such proxies will strip the body on a GET (even though > RFC 7231 allows for bodies on a GET and explicitly refuses to define semantic > meaning for them). If later that script is updated to work behind the load > balancer it will be broken, because Glance is choosing to error instead of > ignoring it. > > Note: I'm not arguing that the user is correct in sending a body when there > shouldn't be one sent, just that we're going to confuse a lot of people with > this. > > I'm also fine with either a 400 or a 200.
I'd be pro 400 series here. Firstly because our Images API v2 documentation clearly states """This operation does not accept a request body.""" Under GET section of most of our paths: http://developer.openstack.org/api-ref-image-v2.html I do not think we should change that just to facilitate someone who is breaking our API and happens to be lucky to have the proxy sanitizing the request in between (which IMO is the second wrong in this corner, the proxy should not alter the request content in the first place). Based on our API documentation I can see 400 series catch being bug fix and I'll be more than happy to throw the discussion about changing our APIs accepting body in the get request as a spec and object it there. It's just wrong to send the message that it's ok to send any garbage to us with your request and consume the extra resources by doing so. - Erno > > __________________________________________________________ > ________________ > 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
