I've been reviewing my relatively crude patch from September last year that
provided transparent SSL socket access to PHP via the php functions
fsockopen, fread etc. etc.
It would be very simple to integrate this into the current PHP code base,
but to do so I think we would need to make some modifications to the
php_sockbuf structure and the SOCK_WRITE macros.
The issues/reasoning is:
. To read/write data to/from an SSL socket we need to call SSL_read() or
SSL_write().
. We can't decide if a socket is opened in SSL mode just by looking at its
descriptor.
. implementing a php_sock_send() function to make this decision would solve
the problem if the SOCK_WRITE macros used it instead of send().
We need to add a pointer to the SSL structure to the php_sockbuf structure.
php_sockread_internal() and php_sock_send() could determine if a socket is
in SSL mode by examining the SSL member of the sockbuf and call the SSL
equivalents.
Can anyone more familiar with this part of PHP advise for or against this
approach?
Would it be worthwhile making my changes more future proof by making an
abstraction layer, in the
same vein as fopen cookie (used by the zlib extension) ?
php_sockbuf {
...
void * cookie;
size_t (*reader)(void * cookie, char * buffer, size_t size);
size_t (*writer)(void * cookie, char * buffer, size_t size);
void (*closer)(void * cookie);
}
For normal sockets, cookie would be set to the descriptor and the
reader/writer/closer functions
set to the regular calls. For SSL sockets the cookie would be the SSL
pointer and the reader/writer/closer functions would be the SSL equivalents
etc.
--Wez.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
