Object name restrictions not documented

[wolever]

The fact that object names can have arbitrary, provider-defined, restrictions is not documented anywhere developers might reasonably notice it.

At very least it should be mentioned:
- In the API documentation: https://developer.openstack.org/api-ref/object-storage/?expanded=get-object-content-and-metadata-detail
- In the documentation for client libraries (ex, so when I look up the Python swiftclient documentation, there's a big warning in the `get_object` method that it will fail with an HTTP 400 if the object name contains certain arbitrary characters)
- How to determine which characters the provider has decided to restrict (see https://review.openstack.org/#/c/442859/)

[clayg (clay-gerrard)]

I think https://review.openstack.org/#/c/442859 is on the right track for the swift end

I think the python-swiftclient get_object handling mostly exposes the right hint from the command line:

ubuntu@saio:~$ swift download test "a b"
Error downloading object 'test/a b': Object GET failed: http://saio:8080/v1/AUTH_test/test/a%20b 400 Bad Request [first 60 chars of response] Object/Container/Account name contains forbidden chars from

I think the programmatic guidelines could better discuss the right way to handle errors the ensure the maximum amount of detail is exposed to the caller

https://docs.openstack.org/developer/python-swiftclient/service-api.html#available-operations

https://docs.openstack.org/developer/python-swiftclient/client-api.html#examples

Some of the python-swiftclient stuff might be better addressed in lp bug #1670917

[wolever (david-wolever)]

The correct behaviour is definitely exposed.

The issue is that the "correct" behaviour is surprising: the default set of characters ('"<>`) are valid URL path components, they aren't blocked by S3 (or any other object storage, as far as I know), and the fact that cluster administrators can arbitrarily forbid characters isn't mentioned anywhere developers might find it.

This can present a major issue in migrating to Swift because (as happened to me) the failure is very unlikely to be discovered before production… which is why I think it's fairly important to make note that the restriction exists as often as possible, even when it's potentially redundant.

[clayg (clay-gerrard)]

I agree migration and interop concerns are the major issue here and quite frustrating. It was certainly discussed when the issue was originally raised [1] - perhaps better foresight could have caused the maintainers at the time to push back harder?

Looking back at the original reviews; it's hard to imagine the mind of the maintainers at the time. There sure didn't seem to be much discussion on what a reasonable default might be?

https://review.openstack.org/#/c/4918
https://review.openstack.org/#/c/9365

Either no one really expected public operators to acctually *use* this middleware, or since they already had clusters they figured their boat had sailed and someone starting fresh would have a better opinion as to what's reasonable?

Maybe https://review.openstack.org/#/c/442859 doesn't go far enough? Can we *deprecate* name_check!?

I would love to point the operator/deployer of the cluster that bit you at this issue and get their feedback? Did they just stick name_check in the pipeline with default configs because why not kitchen sink? Is there some deployment guide floating around the internet that recommends the use of name_check!? Can they just take it out of the pipeline? Do they have any preference on what a more reasonable set of restrictions might be?

1. https://bugs.launchpad.net/swift/+bug/903232

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/442859
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=cd39778824970a696c221f394e70bcee6a9d0001
Submitter: Jenkins
Branch: master

commit cd39778824970a696c221f394e70bcee6a9d0001
Author: John Dickinson <email address hidden>
Date: Tue Mar 7 15:06:13 2017 -0800

    add name_check to /info

    Also removed a bunch of unnecessary unquotes. Just use path_info
    instead (it's already unquoted).

    Partial-Bug: #1670915

    Change-Id: If1af43485b4708cab6c4b5d7f6f0a334d8752518