API responds with incorrect Content-Type on HTTP errors

Bug #1409109 reported by Gilbert Pilz on 2015-01-09
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Solum
Medium
Gilbert Pilz

Bug Description

Solum resources that are exposed with "@pecan.expose" (not sure about those exposed by "@wsme_pecan.expose()") have an incorrect Content-Type value when the response is an HTTP error. For example, the response body might be something like "Plan is invalid ..." but the value of the Content-Type header will be "application/x-yaml" when it should be "text/plain". This causes problems for client side tooling (like tempest) that attempts to interpret the response body based on the value of the Content-Type header.

The reason for this is that our common exception handling code (enabled by "@exception.wrap_pecan_controller_exception") attempts to manually set the correct 'content_type' value (1), but this value is later overwritten by the pecan framework code (2). The correct mechanism to set a Content-Type that is different from the expected Content-Type is to override the declared controller template using the "pecan.override_template()" (3) method.

1.) https://github.com/stackforge/solum/blob/master/solum/common/exception.py#L154

2.) https://github.com/stackforge/pecan/blob/master/pecan/core.py#L601

3.) https://pecan.readthedocs.org/en/latest/pecan_core.html

Changed in solum:
assignee: nobody → Gilbert Pilz (gilbert.pilz)
Adrian Otto (aotto) on 2015-01-13
Changed in solum:
importance: Undecided → Medium
status: New → Triaged
Gilbert Pilz (gilbert.pilz) wrote :

I checked and controllers that are exposed by "@wsme_pecan.expose()" do not have this problem. The exception handling logic in " @exception.wrap_wsme_controller_exception" format the message body resulting from an exception in JSON with a Content-Type of "application/json".

This, however, brings up another issue. Right now, if you use the Solum API, most methods of most resources will return a JSON body with any HTTP error but *some* methods of *some* resources will return a plain text message body. This seems less than ideal. We are requiring well-written clients to be aware of this behavior. It would be better if *all* methods of *all* resources either returned plain text error messages or JSON error messages.

Adrian Otto (aotto) wrote :

Shouldn't the error be returned in the same format the client requested the resource with?

Changed in solum:
milestone: none → 2015.1.1

@gilbert.pilz:

I was wondering if you could point out which methods on which resources are only returning plain text?

It will be good to have this list to enable us to fix it.

Devdatta

tags: added: solum-api

@devdatta:

It's been a while since I looked at this code but, if I remember correctly, it is the methods on any resource that uses just the @pecan.expose annotations and not the @wsme_pecan.expose annotations. I forget exactly why some resources needed to do this - except I remember the WSME made it hard/impossible to do some things.

~ gp

On Nov 2, 2015, at 2:02 PM, Devdatta Kulkarni <email address hidden> wrote:

> @gilbert.pilz:
>
> I was wondering if you could point out which methods on which resources
> are only returning plain text?
>
> It will be good to have this list to enable us to fix it.
>
> Devdatta
>
> ** Tags added: solum-api
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1409109
>
> Title:
> API responds with incorrect Content-Type on HTTP errors
>
> Status in Solum:
> Triaged
>
> Bug description:
> Solum resources that are exposed with "@pecan.expose" (not sure about
> those exposed by "@wsme_pecan.expose()") have an incorrect Content-
> Type value when the response is an HTTP error. For example, the
> response body might be something like "Plan is invalid ..." but the
> value of the Content-Type header will be "application/x-yaml" when it
> should be "text/plain". This causes problems for client side tooling
> (like tempest) that attempts to interpret the response body based on
> the value of the Content-Type header.
>
> The reason for this is that our common exception handling code
> (enabled by "@exception.wrap_pecan_controller_exception") attempts to
> manually set the correct 'content_type' value (1), but this value is
> later overwritten by the pecan framework code (2). The correct
> mechanism to set a Content-Type that is different from the expected
> Content-Type is to override the declared controller template using the
> "pecan.override_template()" (3) method.
>
> 1.)
> https://github.com/stackforge/solum/blob/master/solum/common/exception.py#L154
>
> 2.) https://github.com/stackforge/pecan/blob/master/pecan/core.py#L601
>
> 3.) https://pecan.readthedocs.org/en/latest/pecan_core.html
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/solum/+bug/1409109/+subscriptions

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers