Hi,

Well, I initially wanted to add the gzip support for the standard transport created by Jeff. The reason being that it is pretty well integrated with the overall architecture and most people (including myself) wouldn't probably care about using any other transport for quick hacks and short scripts.

In theory with the asynchronous usage patch I have provided, using the library with any other transport should be trivial, given that now suds may act as a request generator and response processor, with no intervening network support.

I have started playing with urllib3 (mentioned on the list) to create a transport based around that library and that has uncovered a bug and in my opinion a possible need to do some rework of the http and network error handling.

urlllib3 has also needed some extra work to add proxy support and I am still doing some work on the error/exception handling and preliminary support for authentication (server/proxy and basic/digest)

What I was thinking is to ask Jeff to open a contrib directory in the sources, so that if people contribute things like my urllib3 transport, any user of the library may choose to import it and use it (but Jeff is probably busy with many other things as we all are)

Anyhow, thank you becaue I will have a look at Httplib2

Best regards

Daniel

On Wed, May 5, 2010 at 03:27, David Robinson <zxvdr.au@gmail.com> wrote:
Hi Daniel,

FWIW, you could use httplib2 for the transport - that would give you
compression, redirects and keep-alive support for free.

--Dave

On Thu, Apr 29, 2010 at 10:53 PM, Daniel Rodriguez <danjrod@gmail.com> wrote:
> Hello,
> I have added ticket 311 requesting this enhancement with attached patches
> for transport/http.py and transport/options.py
> Requesting compression can be turned off and on with the "gzip" option (a
> bool)
> The gzip decompression code works always. The reasoning behind this is:
>
> Some network providers may compress the data in HTTP responses in order to
> decrease network traffic, expecting all clients to be ready to decompress
> data
>
> Best regards
> Daniel
> On Sat, Apr 3, 2010 at 21:07, Daniel Rodriguez <danjrod@gmail.com> wrote:
>>
>> A "break" at the end of the "if" statement will not hurt and avoid
>> checking unnecessary headers.
>> Best regards
>>
>> On Sat, Apr 3, 2010 at 02:14, Daniel Rodriguez <danjrod@gmail.com> wrote:
>>>
>>> Hi Jeff et al,
>>> If I am not wrong (I may have missed a configuration option), suds is not
>>> using or requesting gzip compression.
>>> I have added a few lines and tested at least requesting and accepting
>>> gzip compression. My changes have been trivial and this could be possibly
>>> added as an option to suds.
>>> The changes I have made (against 3.9):
>>> File: suds/transport/http.py:
>>> Extra imports:
>>> import gzip
>>> import StringIO
>>> Class: HttpTransport
>>> Method: send
>>> Added:
>>> After:
>>>
>>> headers = request.headers
>>>
>>> added the following line
>>>
>>> headers.update([('Accept-Encoding', 'gzip')])
>>>
>>> Changed:
>>>
>>> result = Reply(200, fp.headers.dict, fp.read())
>>>
>>> to
>>>
>>> replydata = fp.read()
>>> for header in fp.headers.dict.keys():
>>>      if header.lower() == 'content-encoding' and fp.headers.dict[header]
>>> == 'gzip':
>>>          replydatacompressedstream = StringIO.StringIO(replydata)
>>>          gzipper = gzip.GzipFile(fileobj=replydatacompressedstream)
>>>          replydata = gzipper.read()
>>> result = Reply(200, fp.headers.dict, replydata)
>>>
>>> Best regards
>>> Daniel
>
>
> _______________________________________________
> suds mailing list
> suds@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/suds
>