Excerpts from Ian Cordasco's message of 2015-07-24 11:22:33 -0700:
On 7/24/15, 13:16, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Ian Cordasco's message of 2015-07-24 08:58:06 -0700:
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.
Nice succinct description of an interesting corner case.
This is indeed one of those scenarios that should be defended against
at the edges, but it's worth considering what will make things simplest
for users.
If we believe in Postel's robustness principle[1], then Glance would
probably just drop the body as something we liberally accept because
it doesn't harm anything to do so. If we don't believe thats a good
principle, then 400 or maybe 413 would be the right codes I think.
So the real question is, do we follow Postel's principle or not? That
might even be something to add to OpenStack's design principles... which
I seem to remember at one time we had written down somewhere.
[1] https://en.wikipedia.org/wiki/Robustness_principle
Just to throw a monkey-wrench in,
https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
To be clear, I agree with Thomson, and think that's the way to go.
However, I believe we haven't stated either in our principles (and if
somebody has a link to those principles, or a clear assertion that we
do not have them and why we don't have them, that would be helpful).
Adding tc to bump the people most likely to respond to that.
It may not always be possible to check whether a body exists, as the has body
can sometimes end up being ignored depending in on the HTTP method being used
when using chunked encoding. Unless anyone knows how to always check for a
body, as webobs implementation is to use the HTTP method to make an informed
guess it appears.
If we try and return a 400. This could lead to different results such as a body
with a non chunked encoding returning a 400, and a body with a chunked encoding
not returning a 400. Therefore would it be better to ignore the body in all
cases, as that would mean the results will always be the same with different
encodings.
Niall
__
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
