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)
#ifdef HTTP_COMPRESSION
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";
}
}
#endif
@@ -2378,7 +2378,7 @@ void send_result(mapping|void result)
"refresh":predef::time(1) +
5 + 3*misc->cacheable/4,
#ifdef HTTP_COMPRESSION
- "encoding" : file->encoding,
+ "encoding" : encoding,
#endif
]),
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.
--
Sincerely,
Stephen R. van den Berg.
While money can't buy happiness, it certainly lets you choose your own
form of misery.
|