Hey there,
On Thu, 30 Nov 2000, Bodo Moeller wrote:
> On Thu, Nov 30, 2000 at 09:37:29AM -0800, Geoff Thorpe wrote:
>
> > The more tricky issue is one of the SSL state itself ... in theory doing
> > an SSL_peek() should allow some data to be generated but with a guarantee
> > that the internal state is completely unchanged.
>
> Should it? I'd have thought that what counts is that any application
> data stays in the buffer for future SSL_read/peek() calls, whereas if
Well you're the expert here on this stuff Bodo so I'll defer to your
better judgement. My belief in "peek" operations is that code should work
exactly the same way whether you switch a bunch of peek operations in or
out. Eg. a peek might be used optionally in an application to examine
header bytes to determine where the data (which can then be read again
*after* the peek) should be forwarded to. The risk is that if the peek()
operation actually advances the SSL state machine and the code is working
because of that side-effect, then switching that peek out (perhaps as an
application option) might cause the state machine logic to dead lock
somewhere, much to the bemusement of the application programmer (who
should instead have it dead-locking every time because his code is wrong
and just barely working because of an accidental side-effect).
Perhaps that is entirely inappropriate here, but from the periphery of the
ssl/ code (a place of fear and loathing) it seems on the surface of it at
least to make sense. Is this impossible with the current state of the
code?
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
