This is an enhancement request for the new ssl socket support in APR. It would be desirable to have the ability to create ssl sockets that are wrapped around pre-existing tcp sockets. I am attaching a patch that I believe has everything that is required.
Created attachment 20599 [details] Adds ability to wrap ssl around pre-existing sockets
Just some cosmetics: why doesn't the declaration of the apr_ssl_socket_create_wrapper function have names for it's parameters? The Doxygen comments have the names, but I don't think all IDEs parse Doxygen. Having the names in the declaration may help programmers with IDEs which can autocomplete and show tooltips with the function signature. return APR_ENOMEM instead of ENOMEM (even though currently they are defined to be the same, it's safer/clearer). don't return "-1", apr_strerror doesn't understand it and it's ugly, just return the error you got in "if (apu_ssl_socket_create(sslSock, asf) != APR_SUCCESS)". the coding standard mandates using '_' to separate words in variable and function names. "ownSocket => own_socket"?
(In reply to comment #2) > Just some cosmetics: > > why doesn't the declaration of the apr_ssl_socket_create_wrapper function have > names for it's parameters? The Doxygen comments have the names, but I don't > think all IDEs parse Doxygen. Having the names in the declaration may help > programmers with IDEs which can autocomplete and show tooltips with the function > signature. > > return APR_ENOMEM instead of ENOMEM (even though currently they are defined to > be the same, it's safer/clearer). > > don't return "-1", apr_strerror doesn't understand it and it's ugly, just return > the error you got in "if (apu_ssl_socket_create(sslSock, asf) != APR_SUCCESS)". > > the coding standard mandates using '_' to separate words in variable and > function names. "ownSocket => own_socket"? I was following the conventions used in the files that I was editing. I can update my patch, but the changes should probably be made across the board. Perhaps there are other files outside of the ssl package that have these issues as well?
Just checking on this issue - haven't seen any activity. Are there any plans for implementing this in a future release? A patch is attached, so it should be pretty easy to roll in. Thanks, Nate
We are still certainly accepting proposed changes to 1.3.0, thanks for the patch!