Martin Jonsson wrote:
>Stephen R. van den Berg wrote:
>>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.
>(Did you observe file->encoding being overwritten when sending
>uncompressed with the previous code? If that was the case, I guess a
>"Content-Encoding: gzip" header would be sent (even though the content
>was uncompressed) to non-gzip-compliant clients each time a request
>resulted in a protstore, right? I personally haven't observed any
>effects like that lately.)
Yes. The last patch was a direct result of observed misbehaviour which
was definitely fixed after applying the patch.
Stephen R. van den Berg.
Safe sex is in your hands.