diff options
| -rw-r--r-- | content/development/comressed_response.rst | 141 | ||||
| -rw-r--r-- | content/images/no-response-css.png | bin | 0 -> 51333 bytes | |||
| -rw-r--r-- | content/images/response-content-uwsgi-proxy.png | bin | 0 -> 62319 bytes | |||
| -rw-r--r-- | content/images/response-content.png | bin | 0 -> 60453 bytes |
4 files changed, 141 insertions, 0 deletions
diff --git a/content/development/comressed_response.rst b/content/development/comressed_response.rst new file mode 100644 index 0000000..2bbe259 --- /dev/null +++ b/content/development/comressed_response.rst @@ -0,0 +1,141 @@ +Gzipped response for CSS/JS with Apache and mod_uwsgi +##################################################### + +:date: 2014-03-01 9:00 +:slug: comressed-response +:tags: python, apache2, mod_uwsgi, mod_deflate +:author: copyninja +:summary: Apache started sending completely gziped response when using + with mod_uwsgi plugin. Post tries to find the problem cause. + +So it may sound normal to receive compressed response for CSS/JS file +from Apache2 but what I faced is completely different behavior, here I +saw not just body of response but also header are getting compressed +and send to browser and browser was unable to interpret the response +there by leading page rendered without CSS and JS. + +That was long story short, so let me explain in detail the case and +what I found out. + +I have `hosted <http://silpa.org.in>`_ `SILPA +<https://github.com/Project-SILPA/Silpa-Flask>`_ on my VPS using +uWSGI. I had used till date using *libapache2-mod-proxy-uwsgi* plugin +for which uWSGI should be using network socket and in Apache2 config I +need *ProxyPass* directive pointing to *uwsgi://host:port* and +everything used to work out of box. There is a drawback for using +network socket in uWSGI that is limited amount of ports (65535) and +possible clash with other services if we use wrong port number, +additionally network sockets will be slower compared to the file +socket so yesterday I thought of changing it to file socket and +removed *socket* directive in the ini file for uWSGI application +container for SILPA and here is where all problems started. My updated +configuration can be seen in our `documentation page +<http://silpa.readthedocs.org/en/latest/installation.html#hosting-the-silpa-on-webserver>`_ +that is if you are interested to look my configuration file :-). + +Problem Reporting +----------------- + +We got selected to Gsoc again this year and we have lot of students +jumping in our channel *#silpa* on *irc.freenode.net* and yesterday +night some students reported they are facing *500 internal server +error* and subsequently others mentioned there is no theme being +rendered. I checked and found everything was fine for me only to +notice that my browser was using cached content, and when I clear +cache there I go everything vanished, no theme no css no javascript +just plain html!!!. + +Investigation +------------- + +So I thought I should investigate this and fired up *firebug* on my +iceweasel to observe the network traffic. And below is what I observed +in firebug network console!. + + +.. image:: images/no-response-css.png + :alt: No response headers + :align: center + +So you can see no response header in the above image but there is a +response and below how is response content visible on firebug. + +.. image:: images/response-content.png + :alt: gzipped response + :align: center + +Still weird part was when using wget/curl directly to get the CSS I +was getting correct reply and the file, which is puzzling. + +So I went ahead opened the CSS url directly using browser and saved +the resulting file. When I used ``file`` command on it, output +suggested the saved file in gzip compressed!. I went ahead +uncompressed it and opened the file and inside it I found response +header and the response body! So what just happened? Did apache some +how manage to compress entire respone not just response body? + +The more puzzling question was why did it work when I was using +*mod_proxy_uwsgi* and failed when I switched to *mod_uwsgi*. I had no +clue at this point why this behavior is coming up. + +Possible Solution +----------------- + +I was still not sure how to resolve this, and started searching in the +network but nothing was coming up in search result which can explain +me this. And finally I stumbled on a link which is `totally unrelated +<http://bit.ly/1eJdQe8>`_ but I saw the word *mod_deflate* in the +content and wandered on my system to see if its enabled. Yes +mod_deflate was enabled I just opened the conf file and saw +following. + +.. code-block:: apacheconf + + <IfModule mod_deflate.c> + # these are known to be safe with MSIE 6 + AddOutputFilterByType DEFLATE text/html text/plain text/xml + + # everything else may cause problems with MSIE 6 + AddOutputFilterByType DEFLATE text/css + AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript + AddOutputFilterByType DEFLATE application/rss+xml + </IfModule> + +Interesting so it suggests to compress css, javascript files etc. So I +thought possibly its compressing the result of *mod_uwsgi*, yeah possibly so +why not try disabling *mod_deflate* and check if it works well and +good if not I'm not gonna loose anything. So I disabled *mod_deflate* +and voila! Everything is working fine! + +What might be the reason for this behavior? +------------------------------------------- + +Well I'm not exactly sure but here is my assumption. The whole +behavior depends on internal implementation of **mod_uwsgi** and +**mod_proxy_uwsgi** module. To confirm this I switched back to use +**mod_proxy_uwsgi** module and enabled **mod_deflate** and observed +request response in **Firebug** network console and below is what I +observed. + +.. image:: images/response-content-uwsgi-proxy.png + :alt: Response with mod_proxy_uwsgi + :align: center + +So response is still gziped but this time only response body was +gziped and Content-Encoding field was set properly which makes browser +to properly uncompress the response body and use it. + +So it seems like there is a difference between mod_uwsgi and +mod_proxy_uwsgi implementation. mod_uwsgi was sending the response +along with response headers which was compressed by mod_deflate there +by rendering browser helpless to interpret the response. But +mod_proxy_uwsgi seems to be only sending the response content without +response body and this content was later compressed by mod_deflate and +proper response headers were set by apache before sending it to +browser. + +So now whose fault is this? Is it the bug in mod_uwsgi or, mod_deflate +not being able to exclude response headers from compression? I've no +clue! If you have a clue and you want to share it with me, please +consider writing to me over email. My details are available in +`Contacts <http://copyninja.info/contact>`_ diff --git a/content/images/no-response-css.png b/content/images/no-response-css.png Binary files differnew file mode 100644 index 0000000..d05af53 --- /dev/null +++ b/content/images/no-response-css.png diff --git a/content/images/response-content-uwsgi-proxy.png b/content/images/response-content-uwsgi-proxy.png Binary files differnew file mode 100644 index 0000000..13774c1 --- /dev/null +++ b/content/images/response-content-uwsgi-proxy.png diff --git a/content/images/response-content.png b/content/images/response-content.png Binary files differnew file mode 100644 index 0000000..92acde3 --- /dev/null +++ b/content/images/response-content.png |
