On May 11, 2015, at 1:05 PM, Dean Troyer <dtro...@gmail.com<mailto:dtro...@gmail.com>> wrote:
On Mon, May 11, 2015 at 11:44 AM, Rosa, Andrea (HP Cloud Services) <andrea.r...@hp.com<mailto:andrea.r...@hp.com>> wrote: > Agreed. Violating the HTTP spec is something that should be avoided. Actually it is not violating the HTTP spec, from RFC: " A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request." The RFC prohibit the use of a body just for the TRACE: " A client MUST NOT send a message body in a TRACE request." When playing in undefined areas such as this it is best to keep in ming Jon Postel's RFC 1122 principle: "Be liberal in what you accept, and conservative in what you send". I'll put it this way: An RFC not prohibiting something does not make it a good idea. This is not how we build a robust API that developers and user can easily adopt. I’m agreed that this is not a good idea. I’d also invoke the principle of least astonishment here. Because it’s a de facto standard (so much so that some proxy in the middle may alter or reject such a request), it would be surprising to developers to allow such requests. REST APIs are difficult enough. Let’s avoid things with "no defined semantics". I’d comment on the review but Gerrit is having a fit so I filed a bug. https://code.google.com/p/gerrit/issues/detail?id=3361 Everett
__________________________________________________________________________ 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
