| 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) *  |
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) * |
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) * |
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) * |
Date: 2010-12-06 18:39 |
| Kristjan, can you take a look? |
|
|
| msg123509 - (view) |
Author: Senthil Kumaran (orsenthil) * |
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) * |
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) * |
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) * |
Date: 2010-12-07 07:26 |
| This issue is not applicable to release31-maint. |
|
|
| msg123547 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *  |
Date: 2010-12-07 13:19 |
| Please also fix it in py3k branch in Lib/xmlrpc/client.py. |
|
|
| msg123593 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2010-12-08 08:05 |
| py3k fixed in r87128 |
|
|
| msg181506 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2013-02-06 09:35 |
| Should this issue be closed? |
|
|
| msg199749 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2013-10-13 18:23 |
| It would appear so. |
|
|