Subject: Re: Possible mod_ssl bug (ssl_io_input_read) (fwd)

From: Cliff Woolley <[email-masked]>
Date: Sat, 7 Jun 2003 00:39:01 -0400 (EDT)

---------- Forwarded message ----------
Date: Fri, 06 Jun 2003 17:59:50 -0700
From: Justin Erenkrantz <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Possible mod_ssl bug (ssl_io_input_read) (fwd)

The suggested API change to char_buffer_read is incorrect.  The filter_ctx
should not be passed to char_buffer_read.  The possibility I'd propose is just
to set buffer->length to 0 when it is exhausted and keep buffer->value
unchanged in this case (it's overwritten on char_buffer_write, so it will not
append to the old buffer - its value is inconsequential once its length is 0).
The AP_MODE_SPECULATIVE case in ssl_io_input_read could easily be modified to
handle this by not adjusting buffer->value.  That seems like it should solve
the problem and do it in a cleaner fashion (and save cycles!).

Yet, I wonder why AP_MODE_SPECULATIVE is being used.  Its purpose is very
narrow - it should only be used to support HTTP pipelining and only asking for
one byte.  Only connection-level filters will implement this mode - so any
request-level filter transformations won't be applied (i.e. mod_deflate if the
request body is inflated).  If you want to intercept the read data, then it
needs to be an input filter not an AP_MODE_SPECULATIVE call.  -- justin

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]