Bug 1115513

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.

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.

"dig into diffs" obviously

Created attachment 914515 [details]
suggested rpm

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 *%)$

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.

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

(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.

(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.

Hi David, how did you go with your testing?

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?

(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.