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

Bug #1320276 reported by Meera Belur on 2014-05-16
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Barbican
Won't Fix
Undecided
Arun Kant

Bug Description

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
}

Changed in barbican:
assignee: nobody → Arvind Tiwari (arvind-tiwari)
Arun Kant (arunkant-uws) on 2014-06-06
Changed in barbican:
assignee: Arvind Tiwari (arvind-tiwari) → Arun Kant (arunkant-uws)
John Wood (john-wood-w) on 2014-06-06
Changed in barbican:
milestone: none → juno-1
John Wood (john-wood-w) on 2014-06-09
Changed in barbican:
milestone: juno-1 → juno-2

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

Changed in barbican:
status: New → In Progress
Arun Kant (arunkant-uws) wrote :

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) wrote :

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.

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

Changed in barbican:
status: In Progress → Won't Fix
milestone: juno-2 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers