Keystone v3 header shouldn't be distinguished by case

Bug #1553398 reported by Fernando Ribeiro on 2016-03-04
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

The 'X-Project-Id' (lower case 'd') header of Keystone v3 [1] is distinguished by case in several places in Zaqar, including the WebSocket endpoint, which generate errors if the 'X-Project-ID' (upper case 'D') header is sent instead.

You may refer to section 3.2 of RFC 7230 [1] for details.


summary: - Misspelled Keystone header
+ Misspelled Keystone v3 header
description: updated
Tin Lam (lamt) on 2016-03-05
Changed in zaqar:
assignee: nobody → Tin Lam (tl3438)
Tin Lam (lamt) on 2016-03-05
Changed in zaqar:
status: New → In Progress

Per review comment - - not sure if the fix is needed, since header is in fact case insensitive. Might be just code churn to lower case the D.

summary: - Misspelled Keystone v3 header
+ Keystone v3 Header Shouldn't be Distinguished by Case
Fernando Ribeiro (fribeiro) wrote :

Updated the ticket title and description to address the real issue.

description: updated
summary: - Keystone v3 Header Shouldn't be Distinguished by Case
+ Keystone v3 header shouldn't be distinguished by case
Changed in zaqar:
status: In Progress → New
assignee: Tin Lam (tl3438) → nobody

Change abandoned by Tin Lam (<email address hidden>) on branch: master
Reason: Abandon this. If time permit, I will submit another fix for this. Instead of changing header field spelling, we need to handle the dictionary case insensitively.

Eva Balycheva (ubershy) wrote :

Good catch. Yes, all our headers in websocket API should be case insensitive. But they're not. I can try to fix it too in the near future.

This is a part of a log, when I pass project id header with different case:

2016-03-26 01:19:39.246 13043 DEBUG zaqar.common.api.api [-] Schema validation failed. 'X-Project-ID' is a required property

Failed validating 'required' in schema['properties']['headers']:
    {'properties': {'Accept': {'type': 'string'},
                    'Client-ID': {'type': 'string'},
                    'Date': {'type': 'string'},
                    'User-Agent': {'type': 'string'},
                    'X-Auth-Token': {'type': 'string'},
                    'X-Project-ID': {'type': 'string'}},
     'required': ['Client-ID', 'X-Project-ID'],
     'type': 'object'}

On instance['headers']:
    {u'Client-ID': u'355186cd-d1e8-4108-a3ac-a2183617232a',
     u'X-Auth-Token': u'eb7dfa1c902f4ba49d26bbc4f243961b',
     u'X-Project-Id': u'7530fad032ca431e9dc8ed4a5de5d99c'}. validate /opt/stack/zaqar/zaqar/common/api/

description: updated
Eva Balycheva (ubershy) wrote :

As I said before, I can't reproduce this bug on WSGI. No matter in which case I write 'X-Project-Id' header in my request, my request is processed normally by Zaqar.

Fernando Ribeiro (fribeiro) wrote :

Allright, will double check and get back to you soon.

Fernando Ribeiro (fribeiro) wrote :

The issue really doesn't affect the WSGI transport, will update the description accordingly.

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

Other bug subscribers