Re: [naviserver-devel] compression

2012-10-27 Thread Gustaf Neumann
On 26.10.12 15:47, Stephen Deasey wrote: I think the spec says that for HTTP/1.1, if the client doesn't explicitly say to NOT send the body gzipped, say by using a q value of 0 (which we don't actually check for, woops...), then the server can choose the encoding, although it should prefer the

Re: [naviserver-devel] compression

2012-10-27 Thread Stephen Deasey
On Sat, Oct 27, 2012 at 1:13 PM, Gustaf Neumann neum...@wu.ac.at wrote: On 26.10.12 15:47, Stephen Deasey wrote: I think the spec says that for HTTP/1.1, if the client doesn't explicitly say to NOT send the body gzipped, say by using a q value of 0 (which we don't actually check for,

Re: [naviserver-devel] compression

2012-10-27 Thread Gustaf Neumann
the version on the tip handles now identity and q-values. The logic sketched below does not handle cases, where e.g. identiy or * is higher than gzip qvalue, or explicit forbidding of gzip. The values are doubles, so one has to be careful with comparisons. I am not sure about the logic for

Re: [naviserver-devel] compression

2012-10-26 Thread Stephen Deasey
On Thu, Oct 25, 2012 at 9:20 PM, Jeff Rogers dv...@diphi.com wrote: It looks like we're enabling compression for all http/1.1 requests regardless of whether it was specified in the request header, or even specifically disallowed. This seems incorrect, but the code has been in place for

[naviserver-devel] compression

2012-10-25 Thread Jeff Rogers
It looks like we're enabling compression for all http/1.1 requests regardless of whether it was specified in the request header, or even specifically disallowed. This seems incorrect, but the code has been in place for several years (connio.c:CheckCompress) ; is there a reason not to change