Barbian for secret POST API returns response with content-type text/plain for a BadRequest when Accept Header */*

[Meera Belur]

Here's a request with empty payload and the return response content-type is text/plain when Accept Header is */*.
Should content-type be application/json?

curl -iv http://<IP>:9311/v1/2104755767dc43d888296049d3ae5cb0/secrets -HX-Auth-Token:7e586f8adf3f47ed8f40cdd68ed1b330 -XPOST -d '{"name": "AES key","expiration": "2014-06-28T19:14:44.180394","algorithm": "aes","bit_length": 256,"mode": "cbc","payload": "","payload_content_type": "application/octet-stream","payload_content_encoding": "base64"}'
* About to connect() to <IP> port 9311 (#0)
* Trying <IP>...
* Adding handle: conn: 0xed4c20
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipel
ine: length: 1
* - Conn 0 (0xed4c20) send_pipe: 1, recv_pipe: 0
* Connected to <IP> (<IP>) port 9311 (#0)
> POST /v1/2104755767dc43d888296049d3ae5cb0/secrets HTTP/1.1
> User-Agent: curl/7.32.0
> Host: <IP>:9311
> Accept: */*
> X-Auth-Token:7e586f8adf3f47ed8f40cdd68ed1b330
> Content-Length: 215
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 215 out of 215 bytes
< HTTP/1.1 400 Bad Request
HTTP/1.1 400 Bad Request
< content-length: 108
content-length: 108
< content-type: text/plain
content-type: text/plain
< x-openstack-request-id: req-87144a54-6b23-43a2-8fc2-739aa81c39ad
x-openstack-request-id: req-87144a54-6b23-43a2-8fc2-739aa81c39ad

<
{
    "title": "Provided object does not match schema 'Secret': If 'payload' specified, must be non empty"
* Connection #0 to host <IP> left intact
}

Here's the request with Accept Header set to application/json
curl -iv http://<IP>:9311/v1/2104755767dc43d888296049d3ae5cb0/secrets -HX-Auth-Token:7e586f8adf3f47ed8f40cdd68ed1b330 -XPOST -d '{"name": "AES key","expiration": "2014-06-28T19:14:44.180394","algorithm": "aes","bit_length": 256,"mode": "cbc","payload": "","payload_content_type": "application/octet-stream","payload_content_encoding": "base64"}' -HAccept:'application/json'
* About to connect() to <IP> port 9311 (#0)
* Trying <IP>...
* Adding handle: conn: 0x1845c60
* Adding handle: send: 0
* Adding handle: rec
v: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x1845c60) send_pipe: 1, recv_pipe: 0
* Connected to <IP> (<IP>) port 9311 (#0)
> POST /v1/2104755767dc43d888296049d3ae5cb0/secrets HTTP/1.1
> User-Agent: curl/7.32.0
> Host: <IP>:9311
> X-Auth-Token:7e586f8adf3f47ed8f40cdd68ed1b330
> Accept:application/json
> Content-Length: 215
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 215 out of 215 bytes
< HTTP/1.1 400 Bad Request
HTTP/1.1 400 Bad Request
< content-length: 108
content-length: 108
< content-type: application/json; charset=utf-8
content-type: application/json; charset=utf-8
< x-openstack-request-id: req-b39e9692-6d33-473a-837f-df352a120c05
x-openstack-request-id: req-b39e9692-6d33-473a-837f-df352a120c05

<
{
    "title": "Provided object does not match schema 'Secret': If 'payload' specified, must be non empty"
* Connection #0 to host <IP> left intact
}

[OpenStack Infra (hudson-openstack)]

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

[Arun Kant (arukant)]

With curl if Content-Type header is not specified, then curl uses its default Content-Type header which is not expected / support content format from barbican perspective (even though actual content can be json format). So made change to address this case via adding default content-type support for POST, PUT and PATCH methods in case its missing or is passed in as 'application/x-www-form-urlencoded' (not expected content type).

Also just now noticed that there is another similar change: https://review.openstack.org/#/c/97554/. So either of that change will address the above mentioned issue.

[Steve Heyman (sheyman)]

Yes this one does look like the same problem that was fixed in https://review.openstack.org/#/c/97554/.

If there is a use case or scenario that the existing CR doesn't cover then we need to address that.

However, if it is the same case then I will suggest that https://review.openstack.org/#/c/97554/ is sufficient because:

1) it doesn't penalize (with additional pathlength) those who do pass in content type of application/json

2) it doesn't change the user's content type, but rather just ensure that we can read in and parse the JSON code

Ideally the fix for all of this would be for pecan (actually webob) to change their default content type from application-x-www-form-urlencoded to application/json.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Arun Kant (<email address hidden>) on branch: master
Review: https://review.openstack.org/99423
Reason: Abandoning as Steve has proposed a blueprint around this (https://review.openstack.org/#/c/100625) which will require clients to pass valid Content-Type header as part of request otherwise 415 error will be raised