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: <<marty[at]roxen.com>>
Developer Cell: +46-709-153931
Roxen Internet Software AB
|