I am having trouble with certain combinations of SSL and mod_proxy.
If I have apache 2.0 acting as an SSL enabled server, I can get it
to proxy to a remote SSL server but NOT to a remote clear text server.

So, while this configuration works:

  ProxyPass /foo/ https://otherhost/bar
  SSLProxyEngin On
  .. etc ...

This does not:

  ProxyPass /foo/ http://otherhost/bar

I seem to recall this working several releases ago.

I'm not sure where to look on this, but here are some more details:

1) Apache clearly makes the TCP connection to the downstream server
   but doesn't actualy send any data.

2) After the connection to the downstream server is made, it seems to just
   freeze waiting for input.  Here is a stacktrace taken when it has reached
   this state (this is not a segfault or anything):

0x402b00ee in __select () from /lib/i686/libc.so.6
(gdb) bt
#0  0x402b00ee in __select () from /lib/i686/libc.so.6
#1  0x40043e14 in __DTOR_END__ () at eval.c:41
#2  0x40038325 in apr_recv () at eval.c:41
#3  0x4001d256 in socket_read () at eval.c:41
#4  0x080c6f76 in core_input_filter (f=0x827ba00, b=0x827b9c0, mode=AP_MODE_READBYTES, 
block=APR_BLOCK_READ, readbytes=11) at core.c:3430
#5  0x080be000 in ap_get_brigade (next=0x827ba00, bb=0x827b9c0, 
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=11) at util_filter.c:508
#6  0x0808adca in bio_bucket_in_read (bio=0x8227388, in=0x8281ec8 "", inl=11) at 
ssl_engine_io.c:395
#7  0x080fa95d in BIO_read () at eval.c:41
Cannot access memory at address 0xb
(gdb) up 4
#4  0x080c6f76 in core_input_filter (f=0x827ba00, b=0x827b9c0, mode=AP_MODE_READBYTES, 
block=APR_BLOCK_READ, readbytes=11) at core.c:3430
3430            rv = apr_bucket_read(e, &str, &len, block);
(gdb) print *f
$1 = {frec = 0x8195b90, ctx = 0x827b9f0, next = 0x0, r = 0x0, c = 0x823e280}


There's a little bit of wierdness here.  This is a single process httpd, not threaded.

The connection the filter is attached to is that of mod_proxy to the downstream server
which is not SUPPOSED to be SSL.  The filter stack on this connection is "ssl/tls 
filter",
then "core_in".  Since the downstream is not an SSL server, this seems incorrect.
Also, at this stage, no data has been sent to the downstream server, so waiting on 
input
from the connection doesn't make sense.

Any pointers here would be helpfull as I am not sure where to look.

-adam

Reply via email to