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.
Thanks, I applied it. Technically I don't think it would make any difference since the "file" mapping is reinitialized with a new mapping a few lines below, but I agree that it makes things a lot cleaner.
(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.)
Regards, Martin -- Martin Jonsson E-mail: <[email protected]> Developer Cell: +46-709-153931 Roxen Internet Software AB
