Incorrect response returned for invalid Accept header

[Niraj Singh]

As of now, when user passes 'Accept' header in request other than JSON and XML using curl command then it returns 200 OK response with json format data.

In api-ref guide [1] also it's not clearly mentioned about what response it should return if invalid value for 'Accept' header is specified. IMO instead of 'HTTP 200 OK' it should return 'HTTP 406 Not Acceptable' response.

Steps to reproduce:

Request:
curl -g -i -X GET http://controller/volume/v2/c72e66cc4f1341f381e0c2eb7b28b443/volumes/detail -H "User-Agent: python-cinderclient" -H "Accept: application/abc" -H "X-Auth-Token: cd85aff745ce4dc0a04f686b52cf7e4f"

Response:
HTTP/1.1 200 OK
Date: Thu, 31 Aug 2017 07:12:18 GMT
Server: Apache/2.4.18 (Ubuntu)
x-compute-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df
Content-Type: application/json
Content-Length: 2681
x-openstack-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df
Connection: close

[1] https://developer.openstack.org/api-ref/block-storage/v2/#list-volumes-with-details

[Chris Dent (cdent)]

I generally agree that this is bad behavior and it would be nice if 406 were the response.

However, this isn't violating the HTTP 1.1 RFCs. https://tools.ietf.org/html/rfc7231#section-5.3.2 says:

"If the header field is
present in a request and none of the available representations for
the response have a media type that is listed as acceptable, the
origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation."

As far as I'm aware very very few (if any) openstack services do content negotiation. They only return JSON. Given that, it is acceptable (ha!) for the header to be disregarded if that's what people choose.

[Sean McGinnis (sean-mcginnis)]

Further discussion was here:

http://lists.openstack.org/pipermail/openstack-dev/2017-September/121778.html

I do agree with the consensus there. Worth having the discussion and increasing the visibility with this bug, but at least for Cinder I am going to mark this as Won't Fix unless there is a more compelling argument to change it. Thanks for bringing it up.

[Brian Rosmaita (brian-rosmaita)]

Glance is behaving within acceptable parameters of RFC 7231 ("HTTP/1.1 Semantics and Content") on this [0].

If we suddenly begin enforcing this, we're likely to break currently working clients who specify "Accept: aplication/json". On one hand, it's their fault for having a typo, but on the other hand, it's not clear to me what we gain by enforcing the 406. I think we want to err on the side of backward compatibility.

[0] https://tools.ietf.org/html/rfc7231#section-5.3.2 (see the fifth paragraph counting backwards from the end of the section)

[Lance Bragstad (lbragstad)]

Keystone will require some sort of versioning change in order to fix this (e.g. microverions).