Bug 1115513 - urllib2_kerberos: HTTPResponse instance has no attribute 'getcode'
Summary: urllib2_kerberos: HTTPResponse instance has no attribute 'getcode'
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: python-urllib2_kerberos
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomas Dabašinskas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-02 13:52 UTC by David North
Modified: 2018-04-11 14:13 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-08-06 20:51:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Patch to fix the problem (416 bytes, patch)
2014-07-02 13:52 UTC, David North
no flags Details | Diff
suggested rpm (9.39 KB, application/x-rpm)
2014-07-03 15:18 UTC, Matěj Cepl
no flags Details
testing script (409 bytes, text/x-python)
2014-07-03 15:38 UTC, Matěj Cepl
no flags Details

Description David North 2014-07-02 13:52:41 UTC
Created attachment 914189 [details]
Patch to fix the problem

Description of problem:

When using urllib2-kerberos via the kerberos extension for Mercurial, I get a stack trace ending with:

File "/usr/lib/python2.7/site-packages/urllib2_kerberos.py", line 129, in retry_http_kerberos_auth
    if resp.getcode() != 200:
AttributeError: HTTPResponse instance has no attribute 'getcode'

Version-Release number of selected component (if applicable): 0.1.6 11.fc20

How reproducible: Always.

Steps to Reproduce:
1. Install the package
2. Enable the Kerberos extension in Mercurial
3. Attempt to 'hg push' over HTTP to a kerberos-enabled repository

Actual results: Exception trace, as above

Expected results: The operation completes successfully with Kerberos auth.

Additional info: It's a one-line fix. Patch attached.

Comment 1 Tomas Dabašinskas 2014-07-03 00:01:43 UTC
Hi David, 
There were some patches puched to urllib2-kerberos last week, please dowgrade the package to https://kojipkgs.fedoraproject.org//packages/python-urllib2_kerberos/0.1.6/10.fc21/noarch/python-urllib2_kerberos-0.1.6-10.fc21.noarch.rpm and let me know if that fixes the problem for now.

I'll have a look at the proper solution meanwhile.

Comment 2 Matěj Cepl 2014-07-03 13:52:02 UTC
Tomas, just notice bug 1065576 comment 12. I have fix for that, and I'll take a look at this one as well. It is weird, because my resp isn't type HTTPResponse but addinfourl which has getcode() method. I'll need to diff into diffs a little bit more.

Comment 3 Matěj Cepl 2014-07-03 13:52:47 UTC
"dig into diffs" obviously

Comment 4 Matěj Cepl 2014-07-03 15:18:43 UTC
Created attachment 914515 [details]
suggested rpm

Comment 5 Matěj Cepl 2014-07-03 15:38:48 UTC
Created attachment 914520 [details]
testing script

Hi, could I ask you to fill to this script an URL of the service which is accessible only with the Kerberos authentication, and run it with the python-urllib2_kerberos from the previous attachment, please? You should get something like (with the Kerberos credentials removed):

reply: 'HTTP/1.1 401 Authorization Required\r\n'
header: Date: Thu, 03 Jul 2014 15:35:18 GMT
header: Server: Apache
header: WWW-Authenticate: Negotiate
header: WWW-Authenticate: Basic realm="Kerberos Login"
header: Content-Length: 483
header: Connection: close
header: Content-Type: text/html; charset=iso-8859-1
2014-07-03 17:35:18,781 DEBUG inside http_error_401
2014-07-03 17:35:18,781 DEBUG authreqs = ['Negotiate', 'Basic realm="Kerberos Login"']
2014-07-03 17:35:18,781 DEBUG retry count: 1
2014-07-03 17:35:18,781 DEBUG req.get_host() returned trac.dqe.lab.eng.bos.redhat.com
2014-07-03 17:35:18,781 DEBUG authGSSClientInit() succeeded
2014-07-03 17:35:18,888 DEBUG authGSSClientStep() succeeded
2014-07-03 17:35:18,888 DEBUG authGSSClientResponse() succeeded
send: 'GET /desktopqe-backlog/login HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: trac.dqe.lab.eng.bos.redhat.com\r\nConnection: close\r\nAuthorization: Negotiate YII... a lot of base64 encoded junk ...C09\r\nUser-Agent: Python-urllib/2.7\r\n\r\n'
reply: 'HTTP/1.1 302 Found\r\n'
header: Date: Thu, 03 Jul 2014 15:35:19 GMT
header: Server: Apache
header: WWW-Authenticate: Negotiate YI... another stream of junk ...Ss
header: Location: https://trac.dqe.lab.eng.bos.redhat.com/desktopqe-backlog
header: Content-Length: 0
header: Pragma: no-cache
header: Cache-Control: no-cache
header: Expires: Fri, 01 Jan 1999 00:00:00 GMT
header: Set-Cookie: trac_auth=ebeed24c1e888d1bffa75b6fdf9c6264; Path=/desktopqe-backlog; secure
header: Connection: close
header: Content-Type: text/plain; charset=UTF-8
send: 'GET /desktopqe-backlog HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: trac.dqe.lab.eng.bos.redhat.com\r\nCookie: trac_auth=ebeed24c1e888d1bffa75b6fdf9c6264\r\nConnection: close\r\nUser-Agent: Python-urllib/2.7\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Thu, 03 Jul 2014 15:35:20 GMT
header: Server: Apache
header: Cache-Control: must-revalidate
header: Expires: Fri, 01 Jan 1999 00:00:00 GMT
header: Content-Length: 9878
header: Set-Cookie: trac_form_token=4a253757ddc73bfc8424ccde; Path=/desktopqe-backlog; secure
header: Connection: close
header: Content-Type: text/html;charset=utf-8
2014-07-03 17:35:21,118 DEBUG resp = <addinfourl at 28378320 whose fp = <socket._fileobject object at 0x1abaa50>>
2014-07-03 17:35:21,118 DEBUG resp = type <type 'instance'>
2014-07-03 17:35:21,118 DEBUG cleaning context
matej@wycliff: python-urllib2_kerberos (master *%)$

Comment 6 Matěj Cepl 2014-07-03 15:40:09 UTC
Could you please post this output (with removing Kerberos credentials) here, please? The problem I have is that whatever I do, my script gives me resp as addinfourl object, which has getcode() method.

Comment 7 David North 2014-07-04 17:46:24 UTC
send: 'GET /xxx/ HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: xxx\r\nConnection: close\r\nUser-Agent: Python-urllib/2.7\r\n\r\n'
reply: 'HTTP/1.1 401 Authorization Required\r\n'
header: Date: Fri, 04 Jul 2014 17:41:07 GMT
header: Server: Apache/2.2.22 (Debian)
header: WWW-Authenticate: Negotiate
header: WWW-Authenticate: Basic realm="kerberos"
header: Vary: Accept-Encoding
header: Content-Length: 494
header: Connection: close
header: Content-Type: text/html; charset=iso-8859-1
send: 'GET /svn/ HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: xxx\r\nConnection: close\r\nAuthorization: Negotiate <ticket removed>\r\nUser-Agent: Python-urllib/2.7\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Fri, 04 Jul 2014 17:41:07 GMT
header: Server: Apache/2.2.22 (Debian)
header: WWW-Authenticate: Negotiate <ticket removed>
header: WWW-Authenticate: Basic realm="kerberos"
header: Last-Modified: Fri, 04 Jul 2014 15:18:20 GMT
header: ETag: W/"13311//"
header: Accept-Ranges: bytes
header: Vary: Accept-Encoding
header: Content-Length: 579
header: Connection: close
header: Content-Type: text/html; charset=UTF-8

Comment 8 Matěj Cepl 2014-07-05 07:59:11 UTC
(In reply to David North from comment #7)
> header: Connection: close
> header: Content-Type: text/html; charset=UTF-8

Sorry, that is not what I've meant. I was mostly after the last lines of the log, which in mine case looked like:

2014-07-03 17:35:21,118 DEBUG resp = <addinfourl at 28378320 whose fp = <socket._fileobject object at 0x1abaa50>>
2014-07-03 17:35:21,118 DEBUG resp = type <type 'instance'>
2014-07-03 17:35:21,118 DEBUG cleaning context

or it may in the end with the crash (traceback would be helpful as well). If this test succeeds, could you try it with the Mercurial as well?

Thank you, and I am sorry for not describing my request for information more clearly.

Comment 9 David North 2014-07-09 16:52:02 UTC
(In reply to Matěj Cepl from comment #8)
> (In reply to David North from comment #7)
> Sorry, that is not what I've meant. I was mostly after the last lines of the
> log, which in mine case looked like:

There was no such output on my system.

or it may in the end with the crash (traceback would be helpful as well).

It did not seem to.

> If this test succeeds, could you try it with the Mercurial as well?

I'll see what I can do. It's possible that Mercurial is doing something differently which triggers the bug.

Comment 10 Tomas Dabašinskas 2014-07-23 03:57:50 UTC
Hi David, how did you go with your testing?

Comment 11 David North 2014-08-06 17:14:14 UTC
Sorry, I don't have time at the moment to do further testing here. We've deployed my patch locally and it works fine - does it cause problems if you just apply the patch?

Comment 12 Matěj Cepl 2014-08-06 20:51:29 UTC
(In reply to David North from comment #11)
> Sorry, I don't have time at the moment to do further testing here. We've
> deployed my patch locally and it works fine - does it cause problems if you
> just apply the patch?

OK, reread please comment 2, I cannot reproduce your problem here. Reopen the bug when you have time, please.


Note You need to log in before you can comment on or make changes to this bug.