Connection filter for forward proxy
I am trying to write what I assume will be a connection filter for use with mod_proxy in forward proxy mode. I would like the filter to be able to selectively chain proxy requests, kind of like ProxyRemote except with far more granular control. Can someone give me an idea of where I should start ? Thanks in Advance
Re: Connection filter for forward proxy
On Thu, Jun 12, 2008 at 10:47 PM, Peter Belau [EMAIL PROTECTED] wrote: I am trying to write what I assume will be a connection filter for use with mod_proxy in forward proxy mode. I would like the filter to be able to selectively chain proxy requests, kind of like ProxyRemote except with far more granular control. Can someone give me an idea of where I should start ? If the implementation of ProxyRemote does everything you need, but it doesn't allow for dynamic configuration, you should develop a patch that allows it to call out to another module to determine the next proxy. Or, add hooks to let mod_rewrite do it via setting some note. I don't think you want to be in the business of duplicating this stuff or trying to subvert the request during an input filter -- Eric Covener [EMAIL PROTECTED]
Re: Connection filter for forward proxy
This may be a silly question but how would I go about giving mod_proxy some knowledge about another module which it should call if the module is installed ? Obviously, I understand how I could hack mod_proxy itself in order to tweak the selection but I do not understand how mod_proxy could: 1. Check for the presence of a module 2. Given that the module is present, somehow ask the module to return the correct proxy. Again, this all makes sense when I think of it in terms of a shared libraries but not so much as Apache Modules. Am I missing something basic ? Eric Covener wrote: On Thu, Jun 12, 2008 at 10:47 PM, Peter Belau [EMAIL PROTECTED] wrote: I am trying to write what I assume will be a connection filter for use with mod_proxy in forward proxy mode. I would like the filter to be able to selectively chain proxy requests, kind of like ProxyRemote except with far more granular control. Can someone give me an idea of where I should start ? If the implementation of ProxyRemote does everything you need, but it doesn't allow for dynamic configuration, you should develop a patch that allows it to call out to another module to determine the next proxy. Or, add hooks to let mod_rewrite do it via setting some note. I don't think you want to be in the business of duplicating this stuff or trying to subvert the request during an input filter
Re: [VOTE] Release Apache HTTP Server 2.2.9
Jim Jagielski wrote:
Test tarballs for Apache httpd 2.2.9 are available at:
http://httpd.apache.org/dev/dist/
Your votes please;
+/-1
[+1] Release httpd-2.2.9 as GA
+1 from me.
Upgraded {eos,aurora}.apache.org to 2.2.9 w/ the bundled APR:
http://eos.apache.org/server-status
http://aurora.apache.org/server-status
Both are Solaris 10/sparc.
These machines host www.apache.org and $tlp.apache.org.
Please let infrastructure know if you see any problems.
During the upgrade, it appears we hit one regression in APR 1.3.0.
On aurora.apache.org, shortly after installing the new version, we hit a
problem with apr_pollset_poll:
[Thu Jun 12 05:36:51 2008] [error] (70007)The timeout specified has
expired: apr_pollset_poll: (listen)
[Thu Jun 12 05:36:52 2008] [notice] caught SIGTERM, shutting down
If you look in worker.c, around line 687, you can see that if do a
graceful shutdown if we get an unexpected error from apr_pollset_poll.
This appears to be a regression caused by r641661:
https://svn.apache.org/viewvc?view=revrevision=641661
Which was a fix for PR 42580:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42580
This appears to be an relative edge case on Solaris 10 -- it hasn't
happened again, and it is a regression in APR, but relatively small, so
I am still +1 for httpd-2.2.9 shipping.
-Paul
Re: [patch] Add IPV6 'specials' flag to mod_rewrite - try 2
* Ryan Phillips wrote: Ryan Phillips [EMAIL PROTECTED] said: Jeff Trawick [EMAIL PROTECTED] said: On Mon, Jun 9, 2008 at 9:19 PM, Ryan Phillips [EMAIL PROTECTED] wrote: Ryan Phillips [EMAIL PROTECTED] said: So I needed to create some mod_rewrite rules only for IPv6 when httpd is configured for both ipv4 and ipv6 modes. This patch adds 'RewriteCond IPV6 on' support to the ruleset. I initially tried to see if the incoming socket was APR_INET6, but couldn't find the right structure within the request to query. Should r-connection-local_addr or remote_addr have the correct socket family? If I try either of these over an IPv4 connection, I always get a socket family of IPv6. On most platforms, httpd will handle IPv4 connections on an IPv6 socket; the address family will be APR_INET6 and the socket address will have a special format which indicates that the client is IPv4 (http://en.wikipedia.org/wiki/IPv4_mapped_address). Replace Listen ## with the combination Listen 0.0.0.0:## + Listen [::]:## and you should be able to distinguish between client connection type by checking the address family (not a real solution). The system macro IN6_IS_ADDR_V4MAPPED() can check if an IPv6 socket address represents an IPv4 client connection. Apparently APR doesn't provide an equivalent. Jeff, Thanks for the detailed explanation. I wasn't aware of this. Attached is a patch which uses IN6_IS_ADDR_V4MAPPED to see if the client is from an IPv4 socket. You should probably add conditionals for both macros (AF_INET6 and IN6_IS_ADDR_V4MAPPED) and deal with non-existance properly. If INET6 is missing, you can safely return off, I think. If IN6_IS_ADDR_V4MAPPED is missing - well, then on might be right. Next point - which header files are the macros and structs in? Should we include them explicitly? Or are they provided by APR already (and officially)? And finally, return apr_strdup should be replaced by result = . I know, it's probably pasted from the HTTPS variable stuff, but that's not good there too ;) Ah, another last point - is your patch against trunk? It doesn't look like it. nd -- If God intended people to be naked, they would be born that way. -- Oscar Wilde
Re: Virtualhost _default_:nnnn in test framework
Hi Nick, Nick Kew wrote: Line 367 in t/conf/httpd.conf reads: VirtualHost _default_:8530 This causes a failure on Solaris, with Could not resolve address '255.255.255.255' -- check resolver configuration. The same thing happens in various other places in the test suite's config. The non-resolution of 255.255.255.255 on Solaris 10 is a known Solaris bug. It's fixed in Patch 125553-03, which itself was obsoleted by 127127-11. For older Solaris releases the common workaround was to ensure DNS for hosts in /etc/nsswitch.conf, for Solaris 10 I think the patch is mandatory to resolve the problem. There were several BZ issues, e.g. https://issues.apache.org/bugzilla/show_bug.cgi?id=20063 and others. Regards, Rainer
Re: Virtualhost _default_:nnnn in test framework
On Jun 11, 2008, at 5:33 PM, Nick Kew wrote: Line 367 in t/conf/httpd.conf reads: VirtualHost _default_:8530 This causes a failure on Solaris, with Could not resolve address '255.255.255.255' -- check resolver configuration. The same thing happens in various other places in the test suite's config. Is _default_ supposed to do anything meaningful? Default is *old*... Some useful info: http://httpd.apache.org/docs/1.3/vhosts/examples.html#default (also http://httpd.apache.org/docs/2.0/... and http://httpd.apache.org/docs/2.2/...)
Re: [VOTE] Release Apache HTTP Server 2.2.9
On Tue, 10 Jun 2008 20:50:50 -0400 Jim Jagielski [EMAIL PROTECTED] wrote: Test tarballs for Apache httpd 2.2.9 are available at: http://httpd.apache.org/dev/dist/ Your votes please; Successfully installed and tested on Solaris, Linux, and OSX. The coadvisor suite shows three new failures (note - failures mean tests that don't complete successfully; protocol violations are a different classification altogether). These are tests involving sending 17 interim responses, which we now reject, so I'm satisfied it's not a regression. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [VOTE] Release Apache HTTP Server 2.2.9
APR 1.3 will require a code change in Windows modules which launch FastCGI programs using apr_proc_create. They will need to use the new APR_NO_FILE attribute. This doesn't affect any other platforms AFAIK. e.g. apr_procattr_io_set(attr, NULL, APR_NO_FILE, APR_NO_FILE); This was pretty well discussed last September per bug 43329, so hopefully most module authors (mod_fastcgi, mod_fcgid, etc.) have prepared for it. There's always the option of falling back to APR 1.2 for anyone who cannot get an updated Windows FastCGI module, so this shouldn't be too big a problem. Back in September we didn't expect APR 1.3 until Apache 2.4, so we may want to call some attention to this when the Windows 2.2.9 binaries get released. Maybe even offer an optional APR 1.2 download to let users fall back easily, since most Windows users don't build Apache from source. -tom- Jim Jagielski wrote: Test tarballs for Apache httpd 2.2.9 are available at: http://httpd.apache.org/dev/dist/
Re: [patch] Add IPV6 'specials' flag to mod_rewrite - try 2
Andr? Malo [EMAIL PROTECTED] said:
* Ryan Phillips wrote:
Ryan Phillips [EMAIL PROTECTED] said:
Jeff Trawick [EMAIL PROTECTED] said:
On Mon, Jun 9, 2008 at 9:19 PM, Ryan Phillips
[EMAIL PROTECTED] wrote:
Ryan Phillips [EMAIL PROTECTED] said:
So I needed to create some mod_rewrite rules only for IPv6 when
httpd is configured for both ipv4 and ipv6 modes. This patch adds
'RewriteCond IPV6 on' support to the ruleset.
I initially tried to see if the incoming socket was APR_INET6, but
couldn't find the right structure within the request to query.
Should r-connection-local_addr or remote_addr have the correct
socket family? If I try either of these over an IPv4 connection, I
always get a socket family of IPv6.
On most platforms, httpd will handle IPv4 connections on an IPv6
socket; the address family will be APR_INET6 and the socket address
will have a special format which indicates that the client is IPv4
(http://en.wikipedia.org/wiki/IPv4_mapped_address).
Replace Listen ## with the combination Listen 0.0.0.0:## +
Listen [::]:## and you should be able to distinguish between client
connection type by checking the address family (not a real solution).
The system macro IN6_IS_ADDR_V4MAPPED() can check if an IPv6 socket
address represents an IPv4 client connection. Apparently APR doesn't
provide an equivalent.
Jeff,
Thanks for the detailed explanation. I wasn't aware of this.
Attached is a patch which uses IN6_IS_ADDR_V4MAPPED to see if the client
is from an IPv4 socket.
You should probably add conditionals for both macros (AF_INET6 and
IN6_IS_ADDR_V4MAPPED) and deal with non-existance properly. If INET6 is
missing, you can safely return off, I think. If IN6_IS_ADDR_V4MAPPED is
missing - well, then on might be right.
Next point - which header files are the macros and structs in? Should we
include them explicitly? Or are they provided by APR already (and
officially)?
And finally, return apr_strdup should be replaced by result = . I know,
it's probably pasted from the HTTPS variable stuff, but that's not good
there too ;)
Ah, another last point - is your patch against trunk? It doesn't look like
it.
Thanks for the tips. IN6_IS_ADDR_V4MAPPED is defined in netinet/in.h on
unices and APR defines it on windows. I've modified the patch to check for
APR_HAVE_IPV6 support and check for APR_HAVE_NETINET_IN_H. Also, this patch will
apply to trunk/.
Thanks,
Ryan
Index: modules/mappers/mod_rewrite.c
===
--- modules/mappers/mod_rewrite.c (revision 667098)
+++ modules/mappers/mod_rewrite.c (working copy)
@@ -82,6 +82,9 @@
#if APR_HAVE_CTYPE_H
#include ctype.h
#endif
+#if APR_HAVE_NETINET_IN_H
+#include netinet/in.h
+#endif
#include ap_config.h
#include httpd.h
@@ -1887,6 +1890,18 @@
rewritelog((r, 1, ctx-perdir, RESULT='%s', result));
return (char *)result;
}
+else if (!strcmp(var, IPV6)) {
+int flag = FALSE;
+#if APR_HAVE_IPV6
+apr_sockaddr_t *addr = r-connection-remote_addr;
+flag = (addr-family == AF_INET6
+!IN6_IS_ADDR_V4MAPPED((struct in6_addr *)addr-ipaddr_ptr));
+rewritelog((r, 1, ctx-perdir, IPV6='%s', flag ? on : off));
+#else
+rewritelog((r, 1, ctx-perdir, IPV6='off' (IPv6 is not enabled)));
+#endif
+result = (flag ? on : off);
+}
break;
case 5:
Re: [VOTE] Release Apache HTTP Server 2.2.9
Tom Donovan wrote: APR 1.3 will require a code change in Windows modules which launch FastCGI programs using apr_proc_create. They will need to use the new APR_NO_FILE attribute. This doesn't affect any other platforms AFAIK. The trouble is that there are other side effects of using apr-1.2, but if needed it does exist at http://www.apache.org/dist/apr/binaries/win32/. Here's my proposed solution to Makefile.win changes that Tom and I have both observed (not affecting sln/dsp builds, but affecting mak file builds), plus the problem with apr.hw's invalid default of IPV6 true, and additional commentary about the binary connectors. The two files below are part of the httpd-2.2.9-win32-src.zip file package, which has been uploaded to httpd.apache.org/dev/dist/ (and should show up sometime shortly when the server syncs). The README-win32.txt will also be added to the binary distribution (msi) for dbd driver instructions. We would also place this .patch in patches/apply-to-2.2.9/ for clarity. Objections or other feedback? Bill New version of APR -- Note that the included APR is now version 1.3.0, which adds several subtle changes in the behavior of file handling, pipes and process creation. Most importantly, there is finer control over the handles inherited by processes, so the mod_fastcgi or mod_fcgid modules must be updated for httpd-2.2.9 to run correctly on Windows. Most other third party modules are unaffected by this change. Source corrections applied -- The -win32-src.zip package includes corrections to the Makefile.win build file so that .mak based builds work. The package also corrects the default to disable IPV6 support. These patches are summarized in the httpd-2.2.9-win32-src.applied.patch file. Connecting to databases --- With APR-util 1.3.0, the MySQL and FreeTDS drivers do not compile on Windows. There is no Microsoft SQL Server client or ODBC client at the present time. Three driver connectors are provided in the binary distribution, for SQLite3, PostgreSQL and Oracle. They require you to install the actual corresponding client drivers. The sqlitedll.zip binary file can be obtained from; http://www.sqlite.org/download.html note that this binary was built with version 3.5.9 (earlier and later version 3.5 driver .dll's may work.) The Oracle Instant Client - Basic driver can be obtained from http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/winsoft.html and note that this binary was built against version 11.1.0.6.0, other version 11.1 drivers may work. The PostgreSQL binaries may be obtained from http://www.postgresql.org/ftp/binary/v8.3.1/win32/ and note that this binary was built against version 8.3.1-1, and again it may work with other 8.1 version .dll's. For whichever database backend you configure, the corresponding driver .dll's must be in your PATH (and in the systemwide path if used for a service such as Apache httpd). Index: Makefile.win === --- Makefile.win (revision 666274) +++ Makefile.win (working copy) @@ -134,11 +134,10 @@ _trydbd: !IF $(USEMAK) == 1 -cd srclib\apr-util\dbd \ - for %d in ($(DBD_LIST)) do \ - $(MAKE) $(MAKEOPT) -f apr_dbd_%d.mak CFG=apr_dbd_%d - $(LONG) RECURSE=0 $(CTARGET) -cd .. - + cd srclib\apr-util\dbd + for %d in ($(DBD_LIST)) do \ + $(MAKE) $(MAKEOPT) -f apr_dbd_%d.mak CFG=apr_dbd_%d - Win32 $(LONG) RECURSE=0 $(CTARGET) + cd ..\..\.. !ELSEIF $(USESLN) == 1 for %d in ($(DBD_LIST)) do \ devenv Apache.sln /useenv $(CTARGET) $(LONG) /project apr_dbd_%d @@ -265,9 +264,16 @@ cd ..\..\.. $(MAKE) $(MAKEOPT) -f aprutil.mak CFG=aprutil - Win32 $(LONG) RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f libaprutil.mak CFG=libaprutil - Win32 $(LONG) RECURSE=0 $(CTARGET) -cd ldap - $(MAKE) $(MAKEOPT) -f apr_ldap.makCFG=apr_ldap - $(ARCH) RECURSE=0 $(CTARGET) -cd ..\..\.. + cd ldap + $(MAKE) $(MAKEOPT) -f apr_ldap.makCFG=apr_ldap - Win32 $(LONG) RECURSE=0 $(CTARGET) + cd .. +!IFDEF DBD_LIST + cd dbd + for %d in ($(DBD_LIST)) do \ + $(MAKE) $(MAKEOPT) -f apr_dbd_%d.mak CFG=apr_dbd_%d - Win32 $(LONG) RECURSE=0 $(CTARGET) + cd .. +!ENDIF + cd ..\.. cd srclib\pcre $(MAKE) $(MAKEOPT) -f dftables.makCFG=dftables - Win32 $(LONG) RECURSE=0 $(CTARGET) $(MAKE) $(MAKEOPT) -f pcre.makCFG=pcre - Win32 $(LONG) RECURSE=0 $(CTARGET) @@ -484,7 +491,7 @@ copy srclib\apr-util\ldap\$(LONG)\apr_ldap-1.$(src_dll) $(inst_dll) .y !IFDEF DBD_LIST for %d in ($(DBD_LIST)) do ( \ - copy srclib\apr-util\dbd\$(LONG)\apr_dbd_%d-1.$(src_dll) $(inst_dll) .y \ + copy srclib\apr-util\dbd\$(LONG)\apr_dbd_%d-1.$(src_dll) $(inst_dll) .y \ ) !ENDIF !IF EXIST(srclib\zlib\zlib1.$(src_dll)) Index: srclib/apr/include/apr.hw === ---
Re: [VOTE] Release Apache HTTP Server 2.2.9
On Jun 12, 2008, at 12:41 PM, William A. Rowe, Jr. wrote: We would also place this .patch in patches/apply-to-2.2.9/ for clarity. +1
Re: [VOTE] Release Apache HTTP Server 2.2.9
Builds fine on Windows and successfully installed and tested. Runs with all popular modules, except mod_fcgid needed a patch (see post from Tom). After ASF releases 2.2.9 we make a mod-fcgid for 2.2.9 available. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Cc: [EMAIL PROTECTED] Sent: Wednesday, 11 June, 2008 02:50 Subject: [VOTE] Release Apache HTTP Server 2.2.9 Test tarballs for Apache httpd 2.2.9 are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/-1 [ ] Release httpd-2.2.9 as GA DO NOT begin distributing these in any manner whatsoever, please note that you can seriously mess up any user who installs these packages if they are ultimately rejected.
Re: [VOTE] Release Apache HTTP Server 2.2.9
On Tue, 10 Jun 2008, Jim Jagielski wrote:
[+1] Release httpd-2.2.9 as GA
Works OK on Ubuntu 8.04 'Hardy' x86 32bit (Linux 2.6.24-18-server on
dual socket Pentium4), it's one of the ftp.acc.umu.se offloaders so
it's getting production load without falling on its head or corrupting
files.
Also seems to work on AIX 5.3 TL7 SP3 (built with vac.C 9.0.0.4 using
cc) on a quad-core POWER4 machine, lightly tested.
Both builds are with the worker MPM.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---
KPLA Klingon Radio : All glory, all the time!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
To folks rolling httpd 2.2.9 tests
you have a chance to get any corrective patches into APR by tomorrow morning, by midday I'll be tagging and rolling a new apr 1.3.1 candidate. Obviously this won't be in the released 2.2.9, but is a way for us to get platform fixes out there in the wild. So please get any patches to apr trunk and backported to 1.3.x branch! Bill
