Title: Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
Type: behavior Stage: test needed
Components: Library (Lib) Versions: Python 3.2, Python 2.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: orsenthil Nosy List: Arfrever, antlong, djc, eric.araujo, georg.brandl, joshual, kristjan.jonsson, lids, loewis, orsenthil, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2010-03-21 19:24 by lids, last changed 2013-10-13 18:23 by georg.brandl. This issue is now closed.

File name Uploaded Description Edit
xmlrpclib.patch lids, 2010-03-21 19:24 Patch xmlrpclib.Transport.parse_response API for backward compatibilty review
Messages (14)
msg101446 - (view) Author: Defert (lids) Date: 2010-03-21 19:24
In the Transport class of the xmlrpclib module, the parse_response method expects a File object but handles HTTPResponse's.
The regression was introduced in r73638.
A fix is attached.
msg101747 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-03-26 11:31
In Python 2.6/3.1, xmlrpclib.Transport.parse_response() accepts a file like object. But Python 2.7/3.2 requires a HTTPResponse object because parse_response() calls response.getheader() method.

The patch moves the call to .getheader() in single_request() to accept a file-like object in parse_response(). But I don't understand why the gzip support is implemented in xmlrpclib instead of httplib.

The problem is related to M2Crypto which pass a BIO object (file-like object, without .getresponse() method).
msg119838 - (view) Author: Anthony Long (antlong) Date: 2010-10-29 02:00
Patched my installation of python27 (via macports, snow leopard) and the patch was successful. Verified patch works in a limited capacity, using yolk.
msg123465 - (view) Author: Dirkjan Ochtman (djc) * (Python committer) Date: 2010-12-06 13:28
Can we get a decision on this? It's kind of sad that this regression wasn't fixed in 2.7.1.
msg123471 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-06 15:27
Even if the change may be straightforward, it requires a test.
msg123486 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-06 18:39
Kristjan, can you take a look?
msg123509 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-07 00:09
I think, the file-like object behavior can be brought back. No need to handling gzipped file object in the patch, if the earlier behavior was not handling it. There is a separate issue to keep track of handling gzip encoded content in httplib.  I shall try to get this moving.
msg123511 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2010-12-07 01:13
The patch looks fine to me.  If it runs and everyone is happy, by all means lets put it in.

(I agree that the zlib stuff _should_ be handled elsewhere, but for reasons of expediency it was put into this module)
msg123528 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-07 07:22
Instead of tossing around the GzipDecoding code from one method to another (which would in turn change the return value from those methods), I thought is appropriate to do a change in parse_response itself, so that it verifies that it is a http response (new kind) before attempting header retrieval. If it an old kind of response (a file object), it does not do a getheader call.

This is committed in r87111 for release27-maint. I shall merge this into other branches.

This does not change any return value from the methods.

- Tests look bit more involved than I expected. The correct way to test this would be to create a FakeTransport object which exhibited the previous older behavior of getting the response via http.getfile method. 

The Fakesocket and Transport tests are not actually testing the response. So I could not exercise the "response part".(Perhaps this is reason it was not caught in the first place). The request part are exercised properly.

If someone has a patch for the tests to exercise response of Fakesocket object and Transport class tests, welcome. Otherwise I shall try to come up with one and add this case too.
msg123529 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-07 07:26
This issue is not applicable to release31-maint.
msg123547 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2010-12-07 13:19
Please also fix it in py3k branch in Lib/xmlrpc/
msg123593 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-12-08 08:05
py3k fixed in r87128
msg181506 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-02-06 09:35
Should this issue be closed?
msg199749 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-10-13 18:23
It would appear so.
Date User Action Args
2013-10-13 18:23:48georg.brandlsetstatus: pending -> closed
nosy: + georg.brandl
messages: + msg199749

2013-02-06 09:35:17serhiy.storchakasetstatus: open -> pending
nosy: + serhiy.storchaka
messages: + msg181506

2010-12-08 08:05:10orsenthilsetmessages: + msg123593
2010-12-07 13:19:37Arfreversetmessages: + msg123547
2010-12-07 07:26:55orsenthilsetresolution: fixed
messages: + msg123529
versions: - Python 3.1
2010-12-07 07:22:23orsenthilsetassignee: orsenthil
messages: + msg123528
2010-12-07 01:13:23kristjan.jonssonsetmessages: + msg123511
2010-12-07 00:09:00orsenthilsetmessages: + msg123509
2010-12-06 18:39:40loewissetnosy: + kristjan.jonsson
messages: + msg123486
2010-12-06 15:27:02eric.araujosetstage: test needed
messages: + msg123471
versions: + Python 3.1
2010-12-06 13:28:35djcsetnosy: + djc
messages: + msg123465
2010-12-05 18:21:26Arfreversetnosy: + Arfrever
2010-12-02 10:04:15joshualsetnosy: + joshual
2010-10-29 02:00:56antlongsetnosy: + antlong
messages: + msg119838
2010-10-29 01:04:28eric.araujosetnosy: + loewis, orsenthil, eric.araujo
2010-03-26 11:31:37vstinnersetnosy: + vstinner
title: broken API in xmlrpclib.Transport -> Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
messages: + msg101747

versions: + Python 2.7, Python 3.2, - Python 3.3
2010-03-21 19:24:21lidscreate