Some bad parameters do not return 4xx

[Daisuke Morita]

In some cases, a request with an invalid parameter does not return 4xx, but 2xx.

For example, GET method to list containers or objects with the invalid "limit" parameter such as "?limit=no_integer" is expected to return 400. However, its response is 200 because an invalid parameter is not reported but ignored.

The only reasonable invalid parameter I can think of a client would be sending is "?limit=" - essentially empty string.

[Peter Portante (peter-a-portante)]

What does the Account Listing REST API documentation about the limit parameter values?

[anju Tiwari (anjutiwari5)]

Here is the output of the api:-

When the limit = a non integer value

curl -i http://127.0.0.1:8080/v1/AUTH_test/Anju?limit=x -X GET -H "X-Auth-Token: AUTH_tk56149046e6f543d582f75998edfe9f6f"
HTTP/1.1 200 OK

object.ring.gz
swift.conf
test.conf

[clayg (clay-gerrard)]

So this cannot change in the v1.0 API.

But i like the python philosophy of never silence errors unless explicitly silenced so I think a BadRequest would be better.

Maybe we can add this to the list of stuff to fix in v1.1 and in the re-crapifier middleware just find non-integer limit params and strip them off before sending them down to the app which now performs strict validation?

@notmyname - can we get a tag or something so we can start to build up a list of all the bugs we'd like to square in the api bump?

[Samuel Merritt (torgomatic)]

https://wiki.openstack.org/wiki/SwiftNextAPI has a list, but I agree some sort of tag on these bugs would be nice to have. I went ahead and added the limit stuff to that page.

[Daisuke Morita (morita-daisuke)]

Making bad parameters return 4xx errors in the next API seems good idea. I found this kind of errors other than limit parameter as follows. Before I edit SwiftNextAPI wiki, could you check following issues?

- PUT or POST request with Invalid values in X-Container-Read/Write headers (such as '######') returns 2xx
- Request with "X-Object-Meta-{Key}: {Value}" header containing non-unicoded Key or Value returns 2xx
- GET request with invalid "format" parameter like "jaon" (typo of json) returns 2xx in text format
- In using SLO, PUT method with invalid "multipart-manifest" parameter like "pur" (typo of put) ends up creating manifest file as a normal object by returning 2xx response (GET or DELETE with invalid multipart-manifest is also regarded as normal GET/DELETE request)
- Request with unacceptable Expect header like "Expect: 100cont" now returns 2xx (ignoring Expect header). In this case, proxy MUST return "417 Expectation Failed"
- Request with invalid Content-Type header like "Content-Type: json" now returns 2xx (ignored)
- PUT request with invalid value in X-Fresh-Metadata header (such as 'X-Fresh-Metadata: invalid') returns 2xx. This value range should be limited to True of False (case insensitive)
- GET request with invalid value in X-Newest returns 2xx as with above.

[janonymous (janonymous)]

Hi ,
   I have a question:
 ->Is the issue fixed
 ->If not when is it planned to fix.
I am happy to contribute on this if not fixed and if possible.

[Christian Schwede (cschwede)]

@janonymous: it is not fixed, but as Clay wrote a while ago it is not possible to fix this with the current API version, otherwise it will break things.

It might be changed sometime in the future, but there are currently no plans for a new API version.

-> Marking as Wishlist

[janonymous (janonymous)]

Thanks Christian for the update.

[Matthew Oliver (matt-0)]

Marking as triaged as I think this has been discussed enough and we know it will have to wait.. and it definitely isn't new anymore.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/299225

[clayg (clay-gerrard)]

I can also sort of imagine a client sending '?limit=None' basically on accident and it has been happily ignored for 5 years. So I'm a little scared to change it.

... maybe there's other strange "not a value" strings that could show up from clients developed in other languages - not sure.

If there is a really really severe consequence of *not* changing it we should capture it here as well. For now I think the bug should still be tagged needs-next-api - but I don't want to be a bully about it. If a couple for core maintainers disagree the *worst* thing that will happen is we revert the change and I get to say I told you so. OTOH, if years from now this is fixed clients sing the praises of beautiful and pure API and no one has ever complained I can totally be called a worry wort!

[OpenStack Infra (hudson-openstack)]

Change abandoned by Tim Burke (<email address hidden>) on branch: master
Review: https://review.openstack.org/299225
Reason: Following http://eavesdrop.openstack.org/meetings/swift/2017/swift.2017-01-18-21.00.log.html the Swift community decided the needs-new-api tag was applied correctly and the risk of breaking clients that currently send non-integer limits is too great. Abandoning as I cannot imagine Swift ever actually *doing* a breaking API bump :-/