Arvados

Sending JSON data via curl is working correctly:

$ curl -v -X PUT --data '{"collection":{"name":"[Deprecated]"}}' -H "Authorization: OAuth2 xxxtokenxxx" -H "Content-Type: application/json" https://ce8i5.arvadosapi.com/arvados/v1/collections/ce8i5-4zz18-9m0e1jso8boqqxy

OTOH, Chrome's inspector shows what seems to be a correct request body, for example while creating a new collection

{"name":"{A new coll","description":null,"preserve_version":true}

...so I'm not sure what's going on yet.

I've found different behaviors depending on the shape of the passed JSON payload.

This is what wb2 is trying to pass (failing request):

{"name":"[Some name]"}

...but the following does work ok:

{"collection":{"name":"[Some name]"}}

...so I'm wondering now whether this is a client or a backend bug.

From chat:

Tom: I suspect it's either controller or rails that needs fixing. foo=[true] and foo="bar" are ambiguous in a form-encoded body, but {"foo":"[bar]"} is not ambiguous in a json-encoded body, so we should be able to handle that correctly.
Suspect part/all of the fix will be making controller use a JSON request body instead of formencoded. I'm not sure why we ever would have used formencoded. I vaguely recall it could be that _method=GET didn't work in a JSON body... if that's the case, maybe we can use the X-Http-Method-Override header instead?

in (*lib/controller/router.router)loadRequestParams():

                                // The Ruby "arv" cli tool sends a                                                                                     
                                // JSON-encode params map with                                                                                         
                                // JSON-encoded values.                                                                                                

It seems that in order for "arv" to work, we double-decode a top level params, so this works:

{"properties":"{\"foo\":\"bar\"}"}

...but we don't double-decode lower levels, so this also works:

{"collection":{"name":"{\"foo\":\"bar\"}"}}

fwiw the examples at https://doc.arvados.org/main/api/requests.html put updated fields at lower levels.

Is it really annoying to change workbench2 to send a body like {"collection":{"name":"[foo]"}} instead of {"name":"foo"}?

• detect afflicted versions of Ruby CLI/SDK (via user-agent?), fix current Ruby CLI/SDK, and turn off this weird behavior for normal clients
• treat malformed JSON as a string, which would probably solve most real-world cases (like "[foo]") but would still break confusingly on other cases (like "[]").

17582-failing-test @ 0e1853309e69b6be2a214ccf66a335e39e8eaa4a -- developer-run-tests: #2466

Ok, so as suggested by Tom, I fixed it on the wb2 side: arvados-workbench2|c0d7c33 - branch: 17582-square-brackets-on-names-fix
Test run: developer-tests-workbench2: #407

• Updated the common resource service to send payloads of the form {rsc_name: { data }} instead of just a JSON object with the plain data.
• Updated tests.

Rebased and added integration tests at arvados-workbench2|d1400d7
Test run: developer-tests-workbench2: #409

Fixes cypress test to support testing names with {curly braces} at arvados-workbench2|52517c0
Test run: developer-tests-workbench2: #412

This LGTM, thanks!