Disable Gzip compressioin in 3.0 content server?

coleman · 06-19-2017, 01:54 PM

Is it possible to disable gzip compression in the new content server? I didn't see it in the options anywhere, but I'm pretty sure it's causing problems for my reverse proxy server (I can't reverse proxy an already gzip'd response).

Thanks!

kovidgoyal · 06-19-2017, 02:11 PM

THere isn't any such option, but it should not be hard to add. May I ask why you cannot reverse proxy a gziped response?

coleman · 06-19-2017, 02:43 PM

Quote:

Originally Posted by kovidgoyal

THere isn't any such option, but it should not be hard to add. May I ask why you cannot reverse proxy a gziped response?

Seems to be a limitation in the IIS software that does reverse proxying. Specifically, as far as I can tell, URL Rewrite can't handle re-writing the outbound header that's already been gzipped by the proxy'd server, apparently it can't decompress the header.

Although, now that I asked for it, I am finding some hits that suggest I might be able to change some settings to pre-decompress the header before handing off to the proxy operation. I'll see if I can implement those and get it working again.

Thanks!

kovidgoyal · 06-19-2017, 02:46 PM

gzip compression does not compress headers, only body. So I dont think that is the source of your problem. UNfortunately I am not familiar with IIS so I cant offer any hints.

coleman · 06-19-2017, 02:58 PM

Ah...sorry, I don't think I was fully understanding the issue at first.
Let me ask this, the new content server, does it support gzip where the old one did not? (I never paid attention if responses where gzip'd before).

The issue is that the IIS rewrite module can't rewrite if the http content is compressed. The suggested fix appears to be to filter the "Accept-Encoding" portion of the http request so that either the content is not sent to the proxy in a gzip'd form. So, I think if I could disable it in the server, it'd fix my issue, but it seems like as long as I can tweak the incoming request from the proxy so that the backend server(Calibre) doesn't send the content response back gzip'd, I'll be ok.

Thanks!

kovidgoyal · 06-19-2017, 03:04 PM

The new server definitely supports and extensively uses gzip. I dont know if the old server did or not (it was a third party module calibre used, not something I had written myself).

But yes, filtering Accept-Encoding will prevent it from using gzip.

coleman · 06-19-2017, 03:48 PM

Thank you for the help, I was able to get it working.
Solution, for anyone else looking:
store the original HTTP_ACCEPT_ENCODING value into a server variable on the inbound request, and then clear it (set it to nulll, you have to do this in web.config, gui doesn't like you not setting a value). On the outbound re-write, restore the value back (so that if you have compression modules enabled, they can kick in).

And on the plus side I just realized I might be able to use this same mechanism to pass through the client IP properly.

06-19-2017, 01:54 PM	#1
coleman Connoisseur Posts: 95 Karma: 38 Join Date: Jul 2007 Device: Android tablets and phones, Windows tablet, Kobo Aura One	Disable Gzip compressioin in 3.0 content server? Is it possible to disable gzip compression in the new content server? I didn't see it in the options anywhere, but I'm pretty sure it's causing problems for my reverse proxy server (I can't reverse proxy an already gzip'd response). Thanks!

06-19-2017, 02:58 PM	#5
coleman Connoisseur Posts: 95 Karma: 38 Join Date: Jul 2007 Device: Android tablets and phones, Windows tablet, Kobo Aura One	Ah...sorry, I don't think I was fully understanding the issue at first. Let me ask this, the new content server, does it support gzip where the old one did not? (I never paid attention if responses where gzip'd before). The issue is that the IIS rewrite module can't rewrite if the http content is compressed. The suggested fix appears to be to filter the "Accept-Encoding" portion of the http request so that either the content is not sent to the proxy in a gzip'd form. So, I think if I could disable it in the server, it'd fix my issue, but it seems like as long as I can tweak the incoming request from the proxy so that the backend server(Calibre) doesn't send the content response back gzip'd, I'll be ok. Thanks! Last edited by coleman; 06-19-2017 at 02:59 PM. Reason: clarified a statment

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Content server on ubuntu 12.04 headless server ImageMagick: libltdl.so.7	Cool Javelin	Calibre	5	04-08-2015 02:20 AM
Calibre Content Server and Windows Home Server 2011	HughMcC	Calibre	8	10-01-2014 07:26 AM
Disable download in Calibre Server	mpucyk	Calibre	2	09-05-2014 03:34 PM
500 Internal Server Error accessing content server Calibre 0.8.8	DaddyO57	Calibre	1	07-20-2012 06:08 PM
Content server, IIS proxy, and gzip compression	abrinton	Calibre	9	04-08-2011 01:26 PM

06-19-2017, 02:11 PM	#2
kovidgoyal creator of calibre Posts: 43,860 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	THere isn't any such option, but it should not be hard to add. May I ask why you cannot reverse proxy a gziped response?

06-19-2017, 02:46 PM	#4
kovidgoyal creator of calibre Posts: 43,860 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	gzip compression does not compress headers, only body. So I dont think that is the source of your problem. UNfortunately I am not familiar with IIS so I cant offer any hints.

06-19-2017, 03:04 PM	#6
kovidgoyal creator of calibre Posts: 43,860 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	The new server definitely supports and extensively uses gzip. I dont know if the old server did or not (it was a third party module calibre used, not something I had written myself). But yes, filtering Accept-Encoding will prevent it from using gzip.

06-19-2017, 03:48 PM	#7
coleman Connoisseur Posts: 95 Karma: 38 Join Date: Jul 2007 Device: Android tablets and phones, Windows tablet, Kobo Aura One	Thank you for the help, I was able to get it working. Solution, for anyone else looking: store the original HTTP_ACCEPT_ENCODING value into a server variable on the inbound request, and then clear it (set it to nulll, you have to do this in web.config, gui doesn't like you not setting a value). On the outbound re-write, restore the value back (so that if you have compression modules enabled, they can kick in). And on the plus side I just realized I might be able to use this same mechanism to pass through the client IP properly.

Advert

Advert