Re: Revisiting: xml2enc, mod_proxy_html and content compression
On 4 Jan 2014, at 13:36, Tim Bannister wrote: > Gzip compressed content sometimes gets served with no declared encoding and a > media type of, e.g., “application/x-gzip”. I reckon that's more common than > serving it as application/octet-stream or with no Content-Type: declared. > > mod_deflate could use this information to avoid compressing the response, and > without sniffing the content. > > This more limited approach is already available through configuration, so > maybe the way to handle this is via a change to documentation / default > configuration, rather than code. > > Any thoughts? Agree in principle. In practice to work it we'd want to enumerate scenarios we can/should support, then figure out whether they can all be accomplished using configuration alone, and if not what code changes we can or should make. IIRC the OP wants to decompress such contents and run them through mod_proxy_html. I don't think that works with any sane setup: running non-HTML content-types through proxy_html will always be an at-your-own-risk hack. -- Nick Kew
[PATCH] fix merging for a couple of OCSP directives
Isn't this change required to handle merging of SSLOCSPEnable and SSLOCSPOverrideResponder? (cfgMergeBool() checks for UNSET to see if a setting hasn't been configured in a scope) http://people.apache.org/~trawick/fix_ocsp_flags.txt untested :) -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
On Fri, Jan 3, 2014 at 6:17 PM, Dr Stephen Henson < shen...@opensslfoundation.com> wrote: > On 03/01/2014 19:31, Jeff Trawick wrote: > > > > Support for "ServerInfoFile" still isn't in > > SSL_CONF_cmd()/SSL_CONF_cmd_value_type() in OpenSSL master or the 1.0.2 > branch, > > right? (IOW, "SSLOpenSSLConfCmd ServerInfoFile info1.pem" is the planned > > interface in mod_ssl but not yet workable?) Or maybe I'm not looking at > the > > right place in OpenSSL. > > > > I just added it to the OpenSSL master branch. Let me know if you have any > problems. I'll backport it to 1.0.2 before release. > Thanks for that. I don't have anything useful to test with the ServerInfoFile right at the moment, but the code seems to be there now: [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1320): AH02407: "SSLOpenSSLConfCmd ServerInfoFile /home/trawick/inst/25-64/info1.pem" failed for www.example.com:8443 [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting: DH PARAMETERS) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile? [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting: EC PARAMETERS) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile? [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile? [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:14151185:SSL routines:SSL_CTX_use_serverinfo_file:no pem extensions > > Steve. > -- > Dr Stephen Henson. OpenSSL Software Foundation, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > +1 877-673-6775 > shen...@opensslfoundation.com > -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Revisiting: xml2enc, mod_proxy_html and content compression
On 4 Jan 2014, at 00:20, Nick Kew wrote: > On 3 Jan 2014, at 13:39, Thomas Eckert wrote: > >> This does not solve the problem regarding .gz files however. They still >> suffer from a double-compression. … > I'd say any such fix must lie in adding a compression-sniffing option > to mod_deflate: > - let the inflate filter sniff for compressed contents > - let the deflate filter sniff for already-compressed contents > even if the headers fail to declare it. > > An option with big "at your own risk" warnings. Gzip compressed content sometimes gets served with no declared encoding and a media type of, e.g., “application/x-gzip”. I reckon that's more common than serving it as application/octet-stream or with no Content-Type: declared. mod_deflate could use this information to avoid compressing the response, and without sniffing the content. This more limited approach is already available through configuration, so maybe the way to handle this is via a change to documentation / default configuration, rather than code. Any thoughts? -- Tim Bannister – is...@jellybaby.net
