Subject Author Date
Re: HTTP compression Stephen R. van den Berg <srb[at]cuci[dot]nl> 06-05-2009
Martin Jonsson wrote:
>Stephen R. van den Berg wrote:
>>No, I fixed another critical one.
>>The current patch(set) still in use for my version is (the one in http.pike
>>is the critical one (obviously)):

>Hmm, what is the patch supposed to fix?

Sorry, apparently I got confused when synching with upstream.  This is
the correct excerpt:

diff --git a/server/protocols/http.pike b/server/protocols/http.pike
index a53c3fa..2f30c52 100644
--- a/server/protocols/http.pike
+++ b/server/protocols/http.pike
@@ -2348,12 +2348,12 @@ void send_result(mapping|void result)
           string uncompressed = data;
           string compressed;
-	  string encoding;
-          if(!file->encoding) {
+	  string encoding = file->encoding;
+          if(!encoding) {
             if(compressed = 
 	       try_gzip_data(data, variant_heads["Content-Type"])) {
               data = compressed;
-              file->encoding = encoding = "gzip";
+              encoding = "gzip";
@@ -2378,7 +2378,7 @@ void send_result(mapping|void result)
 				 "refresh":predef::time(1) +
 				 5 + 3*misc->cacheable/4,
-                                 "encoding" : file->encoding,
+                                 "encoding" : encoding,
 			       misc->cacheable, this_object());

>Not setting file->encoding means that "encoding" will end up as 
>undefined in the cache entry metadata mapping, which in turn makes the 
>test around line 2969 to always fail when reusing a protcache entry. I 
>guess that means that we will send gzipped responses to all clients, 
>even those not announcing gzip capabilities..?

The correct patch as shown above ensures that in case we decide (later)
not to send compressed (e.g. because of a range request), the file encoding
is still at its original (nil) value.  It was previously overwritten.
           Stephen R. van den Berg.
While money can't buy happiness, it certainly lets you choose your own
form of misery.