Morning Daniel,

> >> 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.
> >
> > Surely a POP3 connection upgraded to TLS is not the same as a POP3S
> > connection, so I don't believe you would want these to match.
>
> They are indeed virtually the same - the only difference is how it got to
the SSL
> state. But they mostly won't match anyway primarily since you would use
> different port numbers for them.

True... In my previous example I forgot to mention that I was forcing the
POP3S request to port 110.

> > However, the existing implementation will match a new POP3S connection
> > with an existing POP3 connection that has been upgraded to TLS.
>
> I can't think of any downsides with that.

Indeed... I wasn't sure which way it was supposed to work. I was simply
reading the comment in the code "/* don't do mixed SSL and non-SSL
connections */" at face value ;-)

> > Also, do we want to work on fixing this for v7.23?
>
> If we can come up with a fix we believe in, sure!

I have two fixes depending on what functionality you want to provide:

1) Remove the pop_to_pop3s(), smtp_to_smtps() and imap_to_imaps() functions
thus leaving the original handlers in place for pop3 / smtp / imap TLS
upgraded connections. This would allow the following scenarios:

Scenario A (POP3 to POP3S via TLS):

        curl_easy_perform(curl, "pop3://mail.domain.com"); // Initiates
connection #0 on port 110
        curl_easy_perform(curl, "pop3://mail.domain.com/1"); // Reuses
connection #0 as port is 110
        curl_easy_perform(curl, "pop3s://mail.domain.com:110/2"); //
Initiates connection #1 as POP3S is not the same as POP3 even though port is
forced to 110
        curl_easy_perform(curl, "pop3s://mail.domain.com/3"); //
Initiates connection #2 on port 995

Scenario B (POP3 no upgrade):

        The same results as scenario A

Scenario C (POP3S):

        curl_easy_perform(curl, "pop3s://mail.domain.com"); // Initiates
connection #0 on port 995
        curl_easy_perform(curl, "pop3s://mail.domain.com/1"); // Reuses
connection #0
        curl_easy_perform(curl, "pop3://mail.domain.com:995/2"); //
Initiates connection #1 as POP3 is not the same as POP3S even though port is
forced to 995
        curl_easy_perform(curl, "pop3://mail.domain.com/3"); //
Initiates connection #2 on port 110

2) Modify the check in url.c to compare the two connection's protocol in
addition to the SSL flags. The would mean the following results in these
scenarios:

Scenario A (POP3 to POP3S via TLS):

        curl_easy_perform(curl, "pop3://mail.domain.com"); // Initiates
connection #0 on port 110 and upgrades to SSL via TLS
        curl_easy_perform(curl, "pop3://mail.domain.com/1"); // Reuses
connection #0 on port 110
        curl_easy_perform(curl, "pop3s://mail.domain.com:110/2"); //
Reuses connection #0 as port is forced to 110
        curl_easy_perform(curl, "pop3s://mail.domain.com/3"); //
Initiates connection #1 on port 995

Scenario B (POP3 no upgrade):

        The same results as scenario A and B in modification 1 so different
to results of Scenario A in this modification.

Scenario C (POP3S):

        The same results as scenario C in modification 1.

Summary:

I guess it comes down to whether you want to allow a SSL request to reuse a
TLS upgraded connection (when it has been forced to the same port). To me
this is an invalid use case from the application programmer's perspective
and as such should be treated as a new connection. However, both these
fixes, fix the original problem that I was having so am happy to implement
either.

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-11-04