in reply to Re^5: Threads and HTTPS Segfault
in thread Threads and HTTPS Segfault

It would be interesting to see the results, but I don't have a handy https site that I can hammer in order to test it.

Do all/most/any https servers support persistent connections? I didn't think they did.

I thought I remembered reading that persistent https connections were considered a security risk. And that was why Google's recent release of a patch to short-circuit the handshaking was deemed a prerequisite for the adoption of https on GMail. That without it, AJAX over https was virtually impossible.

But, this is just stuff I've read (and possibly misremembered), not anything I've actually done myself.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^7: Threads and HTTPS Segfault
by juster (Friar) on Aug 25, 2011 at 00:16 UTC

    I'm sorry I could not respond yesterday. HTTP 1.1 connections are persistent by default and HTTP 1.0 has the option of keep-alive to start persistent connections. This should not be a problem as long as the server is fully HTTP 1.1 compatible.

    I never considered persistent AJAX connections! I think AJAX could be problematic if you are sending "XMLHTTPRequests" to a server in response to user events. Even if these connections were persistent they would time out after a lack of events. The techniques of Comet or server push use long lived connections where the server does not respond immediately, which would not be necessary with persistent connections. So maybe it's not implemented at all with persistence in mind?

    I cleaned up my script and I will update my earlier post of source code. Here is some sample output. The min, max, mean, etc, line shows values in milliseconds while the line above is just regular seconds.