Re: replacing Date header
On 17 Feb 2015, at 22:21, André Malo n...@perlig.de wrote: * Eric Covener wrote: Java application servers like WebSphere and WebLogic provide Apache modules like this. I don't know how to address the why, I just want to remove the special treatment for mod_proxy / r-proxyreq and only set a Date if one wasn't provided by the handler. The user I was working with didn't fully understand how how his software re-used the value in the Date header as sent in the handler. Uhm, I have no real idea about those, but are they not integrated with the proxy framework? ajp? However, I always saw this Date header handling as a way to enforce RFC compliance (e.g. to overwrite Date-headers in mod_asis handlers and crappy backends). Wrong Date headers may have a huge impact, as I see it. But then, maybe I'm overrating that. So maybe the logic should be to preserve a Date: header iff it is compliant with the relevant RFC? With this, modules that want a Date: header automatically added need only to ensure they don't assert an apparently valid Date header. -- Tim Bannister – +44 7980408788 – is...@c8h10n4o2.org.uk
Re: replacing Date header
* Tim Bannister wrote: On 17 Feb 2015, at 22:21, André Malo n...@perlig.de wrote: However, I always saw this Date header handling as a way to enforce RFC compliance (e.g. to overwrite Date-headers in mod_asis handlers and crappy backends). Wrong Date headers may have a huge impact, as I see it. But then, maybe I'm overrating that. So maybe the logic should be to preserve a Date: header iff it is compliant with the relevant RFC? With this, modules that want a Date: header automatically added need only to ensure they don't assert an apparently valid Date header. Hmm, which would be the current (!) server time in the correct format. We might need to define some epsilon time which is still acceptable or so. ... it's probably cheaper to keep it as it is right now ;-) nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: Unexpected Warnings from Macro Use in 2.4
On 2/18/2015 6:12 AM, Tom Browder wrote:
I have been using mod_macro for some time and always get the following
types of messages on startup (using 2.4.12 now, but this behavior has
been noticed since 2.4.7):
[Wed Feb 18 13:54:55.019032 2015] [core:warn] [pid 970:tid
140069833443200] AH00111: Config variable ${PROJECT} is not defined
[Wed Feb 18 13:54:55.019041 2015] [core:warn] [pid 970:tid
140069833443200] AH00111: Config variable ${TLD} is not defined
For the example httpd instance only one macro is defined, used, and
undefined like this:
Macro VHOST_NONTLS ${PROJECT} ${TLD}
VirtualHost *:80
ServerName ${PROJECT}.${TLD}
ServerAlias www.${PROJECT}.${TLD}
DocumentRoot /home/web-sites/${PROJECT}.${TLD}/public
/VirtualHost
/Macro
Use VHOST_NONTLS mysite org
UndefMacro VHOST_NONTLS
The warnings I believe are spurious and should not be there. The
virtual hosts work fine after startup. Apparently, the first time
though the macro definitions are read and, since they are not defined,
the warnings are produced. It seems to me that is a bug.
Am I doing something wrong?
Probably because ${VAR} is used when defining variables in the config,
like ServerRoot is.
http://httpd.apache.org/docs/2.4/mod/core.html#define
mod_macro uses just $var so just remove the braces in your above example.
http://httpd.apache.org/docs/2.4/mod/mod_macro.html
Re: mod_macro New in 2.4
On Feb 17, 2015 7:12 PM, Graham Leggett minf...@sharp.fm wrote: On 17 Feb 2015, at 23:07, Stefan Fritsch s...@sfritsch.de wrote: It has been introduced later, in 2.4.5 (see CHANGES file). Therefore it is not listed on the new in 2.4 web page. It is still new though, I think it should probably be listed. One could always add a note like [added in 2.4.5]. Best, -Tom
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
I've now been able to use the latest OpenSSL for mod_ssl while keeping
the system OpenSSL thanks to Ivan Ristic's examples in his books and
tutorials. His method is to compile mod_ssl statically linked with the
latest openssl while compiling all other modules dynamically.
My slightly-modified configure in a bash script looks like this:
SSLDIR=/opt/openssl
export LDFLAGS=-L${SSLDIR}/lib
.
./configure \
--prefix=/usr/local/apache2\
--with-included-apr\
--enable-ssl \
--enable-ssl-staticlib-deps\
--enable-mods-static=ssl \
--with-ssl=${SSLDIR} \
--enable-mods-shared=reallyall \
--with-perl\
--with-python \
--enable-layout=Apache \
--with-pcre=/usr/local/bin/pcre-config \
--without-ldap \
--enable-session-crypto\
--with-crypto
Note the definition of LDFLAGS. During the build, apache uses the
local openssl with no unknown symbol problems. Then, after
installation, apache uses the system openssl, but the important part,
mod_ssl, is still using the local openssl since it was statically
compiled--again, no unknown symbol problems.
.
I have been successfully running Apache 2.4 for some time now with
several virtual https-only sites with no apparent problems.
.
Best regards,
-Tom
Unexpected Warnings from Macro Use in 2.4
I have been using mod_macro for some time and always get the following
types of messages on startup (using 2.4.12 now, but this behavior has
been noticed since 2.4.7):
[Wed Feb 18 13:54:55.019032 2015] [core:warn] [pid 970:tid
140069833443200] AH00111: Config variable ${PROJECT} is not defined
[Wed Feb 18 13:54:55.019041 2015] [core:warn] [pid 970:tid
140069833443200] AH00111: Config variable ${TLD} is not defined
For the example httpd instance only one macro is defined, used, and
undefined like this:
Macro VHOST_NONTLS ${PROJECT} ${TLD}
VirtualHost *:80
ServerName ${PROJECT}.${TLD}
ServerAlias www.${PROJECT}.${TLD}
DocumentRoot /home/web-sites/${PROJECT}.${TLD}/public
/VirtualHost
/Macro
Use VHOST_NONTLS mysite org
UndefMacro VHOST_NONTLS
The warnings I believe are spurious and should not be there. The
virtual hosts work fine after startup. Apparently, the first time
though the macro definitions are read and, since they are not defined,
the warnings are produced. It seems to me that is a bug.
Am I doing something wrong?
Thanks.
Best,
-Tom
