Nova should not log 'Unrecognized content-type...' when none is provided

Bug #904473 reported by justinsb
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Medium
Mark McLoughlin

Bug Description

When python-novaclient makes the first request to novaadmin/servers/detail, it doesn't send the Content-Type. Although I think the v1.1 endpoint can tolerate that, if "someone" gets the URL wrong, then it may send a request without a Content-Type to an endpoint that can't.

From nova --debug list:

send: u'GET /novaadmin/servers/detail?fresh=1323816801.06 HTTP/1.1\r\nHost: 192.168.1.104:8774\r\nx-auth-project-id: novaadmin\r\nx-auth-token: AG5vdmFhZG1pbgAxNTA1ZjQwAG5vdmFhZG1pbgDBNU6C0L._kq3V7PEjlSTEgC33eg--\r\naccept-encoding: gzip, deflate\r\nuser-agent: python-novaclient\r\n\r\n'

The relevant section of the nova-api log:
2011-12-13 22:51:11,714 INFO nova.api.openstack.wsgi [-] http://192.168.1.104:8774/novaadmin/servers/detail?fresh=1323816671.7 returned with HTTP 300
2011-12-13 22:53:02,260 INFO nova.api.openstack.wsgi [-] GET http://192.168.1.104:8774/novaadmin/servers/detail?fresh=1323816782.25
2011-12-13 22:53:02,260 DEBUG nova.api.openstack.wsgi [-] Unrecognized Content-Type provided in request from (pid=4938) deserialize_body /usr/lib/python2.6/site-packages/nova-

Thierry Carrez (ttx)
tags: added: python-novaclient
Thierry Carrez (ttx)
Changed in nova:
importance: Undecided → Low
status: New → Confirmed
Changed in nova:
assignee: nobody → Dean Troyer (dtroyer)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-novaclient (master)

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

Changed in nova:
status: Confirmed → In Progress
Dean Troyer (dtroyer)
Changed in nova:
assignee: Dean Troyer (dtroyer) → nobody
Revision history for this message
Brian Waldon (bcwaldon) wrote : Re: python-novaclient should always send a Content-Type when posting data

What's happening here is that nova always gets 'text/plain' if we don't explicitly provide one. So it always logs an 'Unrecognized...' when really it should not be getting a content type at all and log a 'No content-type provided' line.

Changed in nova:
status: In Progress → Triaged
tags: removed: python-novaclient
Brian Waldon (bcwaldon)
summary: - python-novaclient should always send a Content-Type when posting data
+ Nova should not log 'Unrecognized content-type...' when none is provided
Revision history for this message
Mark McLoughlin (markmc) wrote :

I've seen this message act as a time-wasting red herring for people trying to debug an unrelated issue.

Changed in nova:
importance: Low → Medium
Revision history for this message
Mark McLoughlin (markmc) wrote :
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

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

Changed in nova:
assignee: nobody → Mark McLoughlin (markmc)
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/10119
Committed: http://github.com/openstack/nova/commit/9ac962cc82ef55cf211c0dfa5d18bc5bde27563b
Submitter: Jenkins
Branch: master

commit 9ac962cc82ef55cf211c0dfa5d18bc5bde27563b
Author: Mark McLoughlin <email address hidden>
Date: Mon Jul 23 09:32:30 2012 +0100

    Avoid unrecognized content-type message

    Fixes bug #904473

    If the client does not include a Content-type header in its request
    (which is normal for e.g. GET and DELETE) then eventlet will pass us
    'text/plain'.

    Because 'text/plain' isn't one of our supported request content types
    we log:

      Unrecognized Content-Type provided in request

    This can be an annoying red-herring for people debugging issues.

    The reason that eventlet defaults to text/plain is because it uses
    the mimetools.Message.gettype() method:

      Message.gettype()
        Return the message type [..] as specified in the Content-Type
        header. If no such header exists, return 'text/plain'.

    The wsgiref web server has the same behavior, whereas mod_wsgi will
    pass no content-type and twisted will pass an empty string.

    Make our code more robust by treating the empty string or text/plain
    as if no content-type header was supplied.

    Change-Id: Ide117c807db0dc0f5cbe974788b604b5e236800a

Changed in nova:
status: In Progress → Fix Committed
Jay Pipes (jaypipes)
Changed in nova:
milestone: none → folsom-3
Thierry Carrez (ttx)
Changed in nova:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: folsom-3 → 2012.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.