New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use HTTPHeaderDict in request #679
Conversation
Fix dict(HTTPHeaderDict(other_dict)) and deal with changes in how we implement the HTTPHeaderDict as a MutableMapping subclass instead of as a dict subclass.
This might not be perfect, but it at least passes the |
Tests are failing because there isn't that tests the |
yield val[0], ', '.join(val[1:]) | ||
|
||
def items(self): | ||
return list(self.iteritems()) | ||
|
||
viewitems = items |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to delete this. We don't need it.
Broadly LGTM. |
Mmmm yea this is a smaller change than I thought we'd need. If you can make the remaining test(s) pass, I'm all for it. :) |
Btw, 🍮. |
Now when we send data with the HTTPHeaderDict we will use the original casing, e.g., if we create an instance with {'COOkie': 'value'} Then dict(HTTPHeaderDict({'COOkie': 'value'})) == {'COOkie': 'value'} So we should expect that the returned headers preserve the capitalization that was provided to the HeaderDict.
So the tests should pass now. The thing that I'm uncertain about is this test. I can definitely see that |
Hm wonder if it's our dummyserver and/or httplib mangling headers on some versions. |
It's more bizarre because this test was passing before we fixed the round-trip behaviour. =/ |
If I debug into the request methods, I get to (Pdb) p kw['headers']
{'Accept': '*/*', 'baz': 'quux', 'Host': 'localhost:52261'} On L276 in |
If I go further, it's still the right case in |
For anyone else looking to follow the same rabbit hole.
|
So this isn't in |
Definitely the dummy server. From tcpdump:
We definitely emitted headers in lowercase, they were definitely reflected to us in upper-case. |
Note also that the dummyserver inserts some headers we didn't send ( |
Ok, so had a quick chat with @shazow and I think that test should just be rethought. We can't effectively test that case is preserved when we round-trip via the dummy server, so let's just not. I can see a case for wanting a test that ensures that case is preserved that includes httplib, but if we're going to do that we should do it as a socket-level test where we can confirm that the bytes-on-the-wire are really what we think they are. |
So b49490d has a socketlevel test for this. |
Yay 🍮! Are we good to go? Shall I merge and ship v1.11? |
That's Cory's call.Sent from my Android device with K-9 Mail. Please excuse my brevity. |
Let's rock-and-roll. |
This causes OpenStack devstack-gate tests to fail on Fedora 21 (but not on Ubuntu). There are interactions between many python packages during the test, so I am not yet certain if it is urlib's fault, but if I use the commit previous to the merge of this pull request, tempest tests pass. |
@mmedvede Can we get more information, e.g. a link to a Launchpad bug? |
@Lukasa it appears they're tracking it in https://bugs.launchpad.net/glance/+bug/1476770. The original bug was because the gate is not operating as it is supposed to (and I suspect the same is happening on Fedora). The gate should always be installing requests from pip instead of using system packages but they're not so when they install urllib3 1.11.0, it installs over the system urllib3 that was installed. I maintain that this is fundamentally a problem with the gate. Note that instead of fixing the gate, they released a new version of oslo.vmware (the only library to use urllib3 in openstack directly) with a cap to exclude 1.11.0. This is not a problem or a bug in urllib3. |
@sigmavirus24 I was not aware of the bug, thanks. It is exactly what was happening to our third-party Fedora 21 gate (IBM PowerKVM CI) before I disabled the urllib3 1.11 install. I assume that Ubuntu installs newer system python-requests, so when urllib3 1.11 is installed on top, the gate doesn't break. The weird thing is that both Ubuntu and Fedora gates show requests 2.7.0 installed. I have confirmed that doing 'pip install --upgrade --force-reinstall requests' fixes Fedora 21 in my scenario, even though requests would still show as being 2.7.0. @Lukasa Thanks for quick response. Not urllib3 problem. |
@mmedvede check where requests 2.7.0 is installed from. You'll see that it's installed from the system packages and that is not what the gate is supposed to do. Anyway, further discussion should happen on LaunchPad, not here. |
This change requires all |
Supersedes #633