Use of webob.Reponse in AuthProtocol middleware break content-type handling

[Chris Dent]

Commit 675729be2e3073204e6acc1627394f53f3e3cf51[1] introduces webob into the middeware handling: the enclosed app is called with `request.get_response(self._app).

If the self._app returns a response with no content-type then webob will apply a default header[2]. For responses that have bodies this is okay, but for responses that do not, such as 204 or 304 this is invalid and breaks tests that lint WSGI responses[3].

Earlier versions of keystonemiddleware didn't use webob so this problem didn't raise its head.

One might argue that the bug here is in webob (I'll report one there too) but in the meantime a solution might be to create a subclass of Response (or otherwise invade Reponse) that does not have a default_content_type.

[1] https://github.com/openstack/keystonemiddleware/blob/675729be2e3073204e6acc1627394f53f3e3cf51/keystonemiddleware/auth_token/__init__.py#L606

[2] https://github.com/Pylons/webob/blob/58654bb0e43ad56c322b290422eef7a281c9c64a/webob/response.py#L113

[3] https://review.openstack.org/#/c/193036/

[David Stanek (dstanek)]

We should definitely fix this in ksm, but I would agree the behavior in WebOb is questionable. We have to deal with similar behaviors in Keystone already: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/wsgi.py#n770

I wouldn't be surprised if they mark the bug as "won't fix" because it would break their consumers who may be expecting that behavior.

[Chris Dent (cdent)]

WebOb bug, for reference: https://github.com/Pylons/webob/issues/205

[Dolph Mathews (dolph)]

I believe keystone itself used to have this issue as well. If you can cause an error that keystone can't catch itself, then I think you should still be able to reproduce this against keystone.