(Added [api] to subject to bring in the attention of the API team.) On Mon, 2015-05-11 at 14:48 +0000, Rosa, Andrea (HP Cloud Services) wrote: > I noticed that in the nova API we allow to specify body just for the > PUT and POST requests [0], for all the other methods, if a body is > specified, it gets ignored. > > I had a look at the RFC 7231 [1] and I noticed that just the TRACE > must not have a body, for all the other request a body can be passed > and managing or ignoring it depends on the semantic of the request. > > For that reason my proposal is to allow at WSGI layer to define a body > for all the requests but for the TRACE then it is up to the specific > controller to ignore or deal with the body in the request. > > I put a WIP to implement that change [3]. > > The rationale behind it is double: > > - Be more in compliance with the RFC > > - Having more flexibility in our framework. I have a valid > (at least for me) use case here [4]: at the moment a volume detach is > implemented using a HTTP DELETE, I’d like to add the option for > calling from nova, the cinder –force-delete > > My idea to implement it is to add a parameter in the body of the > DELETE call, but at the moment the only valid option is to create a > new API using a POST method.
I have worked with client frameworks which raise exceptions if you attempt to pass a body using the DELETE method, and would presumably also prohibit a body with GET and HEAD, so I'm -1 on this: we should actively discourage service developers from requiring bodies on HTTP methods that a client framework may prohibit sending bodies with. -- Kevin L. Mitchell <kevin.mitch...@rackspace.com> Rackspace __________________________________________________________________________ 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
