[ic] SSL errors mod-interchange/mod_ssl

[interch]

SSL works fine until you go to the checkout page.  secure server is the
exact same hostname as non secure, etc...   I
saw a post about this
on the list but no answer I could find for it.  I also found a post on
openssl-users about it.  Here is the post from openssl-users about the
problem, I am getting the exact error they are describing.  This is the
latest Redhat linux, IC 4.8.3 (from cvs), apache 1.3.19(rpm),
mod_interchange, and mod_ssl(rpm).


On Sun, Apr 30, 2000 at 08:01:30PM -0700, Jeff Magnusson wrote:

> I'm using Net::SSLeay for a non-blocking server and it sets up new
client
> connections fine, but when I write to the client (SSL_write) I get the
> following error:
> 
> SSL_write 17655: 1 - error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad
> write retry
> 
> Any help would be appreciated, I've looked at the source and I'm not
sure
> why I would be getting this.

When SSL_write is called again after SSL_ERROR_WANT_..., it
must get exactly the same buffer because parts of the buffer
contents may already have been encrypted and wait in interal
buffers while others may not yet have been looked at.
What's really important is that buffer *contents* stay the same,
but as a sanity check to avoid application bugs the OpenSSL
library checks whether the buffer *address* is not changed.
This check can be disabled by setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
for that SSL object, using SSL_set_mode (or SSL_CTX_set_mode
on the SSL_CTX before SSL_new is called).

I don't know about Net::SSLeay, but it would not surprise
me if the same string can be at a different memory location
when SSL_write is called again.  If so, look if SSL_set_mode is
available; and you might want to  ask the Net::SSLeay maintainers
to consider always setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
if the library default doesn't work for it.