>>> Here is an experimental patch I wrote that implements the 1/n-1 >>> record splitting technique for OpenSSL. I am sending it here for >>> consideration by OpenSSL upstream developers. >>> >>> By default the 0/n split is used but in case the >>> SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first >>> record with 1/n-1. >> What would you [and others] say about this alternative? Non-committed, >> relative to HEAD... > .... > > The patch seems OK however it is not clear whether this change really > brings much. > > The original experimental patch is not really usable as there are > already known applications which are even broken by the 1/n-1 split. So > for SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS the split cannot be done at all > anyway. Your patch will improve the compatibility of the case where > SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not used however I have not seen > any reports, at least in our Bugzilla, that would ask for that. So it's > just a matter of preference whether you want to change the 0/n split to > 1/n-1 one.
Have you heard of *clients* that suffer from 1/n-1 split? I mean if clients are tolerant to it, it might make sense to favor 1/n-1 on server side. Major obstacle for 0/n used to be Microsoft TLS or in more practical terms IE, and with 1/n-1 IE would work... As for client side, arguably it would make things worth. I mean if client plays smart and implements 1/n-1 split itself depending on situation, e.g. not when using POST, then such split in libssl would be counterproductive. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
