NetTalk Central

The Rest Of NetTalk => The Rest - Ask For Help => Topic started by: Matthew51 on January 14, 2015, 05:20:04 PM

Title: Web Client Content-Encoding: gzip
Post by: Matthew51 on January 14, 2015, 05:20:04 PM
Net Talk 8.34

I understand the web client is supposed to read gzip content automatically.  However self.page still contains the compressed content.  Is their anything I need to do to get the decompressed content?  I have placed zlibwapi.dll in the destination folder already.
Title: Re: Web Client Content-Encoding: gzip
Post by: Bruce on January 19, 2015, 01:43:48 AM
Hi Matthew,

actually I hadn't implemented any automatic decompression on the client side of things up to 8.34.

But I have done so for 8.35 - which should be out soon. I'd also made the default "Accept-encoding" setting 'gzip' rather than blank.

Cheers
Bruce
Title: Re: Web Client Content-Encoding: gzip
Post by: Matthew51 on January 19, 2015, 03:59:22 PM
Good to hear, I suppose I'll have to remove the code I added to decompress the response then.

While we're on the topic some of my requests can get quite big, and I would like to gzip them.  Is their any way to make the web service understand gzip encoding a post?  The test I ran the server just got confused and gave me the documentation page.
Title: Re: Web Client Content-Encoding: gzip
Post by: Bruce on January 19, 2015, 11:08:47 PM
Hi Matthew,

I was doing some research on this last night because it occurred to me as well.

The short answer is "mostly no". It's not something that servers support much.

If you did want to do it then you'd need to set the "content-encoding" header to Gzip.
Some servers might specifically check for the header, and knowing they don't support the feature at least give you back an error code. Other servers may just choke on the POST data completely.

I think it should be reasonably simple to add support to the NetTalk server though, and by extension to the NetTalk WebClient. Then at least if you were using a NetWebClient to talk to a NetWebServer you'd be able to take advantage of this. This might lead, slightly down the road, to compressing ajax requests from the browser as well - but we'll have to wait and see about that.

cheers
Bruce