Subject Author Date
Re: HTTP compression Martin Jonsson <marty[at]roxen[dot]com> 07-05-2009
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.)


Martin Jonsson	E-mail: <<marty[at]>>
Developer       Cell:   +46-709-153931
Roxen Internet Software AB