On Thu, 3 Nov 2011, Steve Holme wrote:

>> Therefore, the handler->flags's PROTOPT_SSL bit is not enough to use for
>> this check!
>
> Upon further investigation I also believe that SMTP and IMAP suffer the same
> fate as well.

Yes, and most likely FTP too.

> I have tried commenting out the contents of pop3_to_pop3s() which only gets
> called during the upgrade process (and thus not changing the handler). This
> appears to work, although I am not too sure if this will cause any other
> problems.

That will just cause the reversed problem: if you have a POP3 connection
without SSL and one _with_ SSL you don't want them to match.

> I was wondering whether we could introduce another handler. For example:
> Curl_handler_pop3tls (and subsequently: Curl_handler_smtptls and
> Curl_handler_imaptls) which then has flags to say that the connection has
> been upgraded but then the scheme would be the same and could be used during
> the reuse test.

Yes, I figure that should be possible. The only question is another handler
struct is better than a handicrafted extra check in the ConnectionExists()
function. After all, we're talking about 4 new handler structs.

> The only problem I foresee with this is: I don't know if or how curl uses
> the handlers to calculate the default port information and whether having
> two "pop3" (and "smtp", "imap") handlers would cause additional problems.

The 'protocols' array in lib/url.c is what is used to lookup protocols and
their associated ports etc, so it doesn't matter if we create more "internal"
handler structs as long as they're not added to that array.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html