libcurl remembers old SSL session ID after server rejects it

Hi,

With libcurl 7.19.4, SSL session resume works as long as the server always accepts the session ID. If the server switches to a new session ID (e.g. session expired, or Apache was reloaded), the client will continue to try to reuse the old, invalid ID.

I ran into the problem when libcurl is using OpenSSL (ssluse.c), and I have a patch for that. It looks like gtls.c would have the same issue, but I haven't tested it.

The patch just checks if the server session ID matches the one in the cache, and if not, removes the old one from the cache and adds the new one. It's kind of ugly; it almost seems like it might be better if Curl_ssl_getsessionid() always removed the session from the cache when returning it, and then ssluse.c/gtls.c could re-add every time without having to check whether it's already in the cache.

In normal use people don't run into this bug -- CPU and network are fast, and few clients are talking to the same server for long enough to notice. (One person did notice in 2003: http://curl.haxx.se/mail/lib-2003-05/0161.html and http://curl.haxx.se/mail/lib-2003-06/0010.html\)

We're using libcurl on a mobile POS terminal with a super slow CPU (70 MHz) and lossy GPRS modem, so it actually makes a huge difference: Transactions take 3 seconds when session reuse works, and 25 seconds when it doesn't.

Mike