[openstack-dev] [nova][cinder][glance] What should be the response for invalid 'Accpet' header?

Erno Kuvaja ekuvaja at redhat.com
Mon Sep 4 15:55:15 UTC 2017

On Fri, Sep 1, 2017 at 6:53 PM, Chris Dent <cdent+os at anticdent.org> wrote:
> On Fri, 1 Sep 2017, Sean McGinnis wrote:
>> Thanks Chris, I wasn't aware of that. What's your opinion - change
>> it to be more strict, or leave it as is?
> Ideally we'd have true content negotiation and support multiple
> representations with different content types and diferent versions.
> ;)/2
> But since we don't I think existing services can probably forgo
> making any changes unless they are eager to tighten things up.
> For some additional context:
> Placement vaguely supports content negotiation but not in any
> significant way. The docstring of a check_accept decorator says:
> "If accept is set explicitly, try to follow it. If there is no match
> for the incoming accept header send a 406 response code.  If accept
> is not set send our usual content-type in response."
> Because of the way placement uses webob, and the way webob uses the
> accept header to control the formatting of error responses then
> content negotiation comes into play on error responses: They are
> text/html unless there is an accept header of application/json.
> --
> Chris Dent                      (⊙_⊙')         https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I'm with Chris on this.

We're behaving according to RFC and I'm not convinced that any change
is necessary nor helping anyone out. Specially as mentioned we really
don't have any content delivery negotiation ongoing. The client tells
he API "Hey I can deal with XYZ (as well)" we don't know what that
means and we provide the response as per documented.

How about we continue business as usual and not break this for anyone?

Erno "jokke" Kuvaja

More information about the OpenStack-dev mailing list