[MERGE] Workaround SSLFile wrong readline prototype and fix bogus tests

[Vincent Ladeuil]

>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:

    aaron> Vincent Ladeuil wrote:
    >>>>>>> "martin" == Martin Pool <mbp at sourcefrog.net> writes: 
    >> In addition to the 7 steps explanation above, the easiest way
    >> (and the only *correct* way I can think of) to ensure https
    >> compliance was to inject a (transport, https server) in the
    >> permutations used by the test_transport_implementation tests.

    aaron> Can't you just make your special https the default
    aaron> https handler for those tests?

May be.

But I think it would have been cheating and probably more work
than just fixing the tests.

In fact, while working on that patch, I was tempted to do
something along these lines when the tests began to fail for
chroot and the like, i.e. transport which doesn't care *at all*
about possible_transports because there is no way to reuse them...

The root cause, for me, is that the tests didn't respect the
transport they should have used and that wasn't obvious at all
(from a test writer point of view) because the get-transport()
call was perfectly legit (the API is url based not transport
based).

And that went unnoticed for a loooong time.

These tests are relatively old and have been fine so far because
the test server was adding the http implementation in the url
forcing get_transport to return a "correct" transport, but that's
a bit lucky if you think about it[1].

Yet, those tests should be exercised against all possible
transports so tweaking the transport choice made by get_transport
doesn't sound like the best way to ensure that.

     Vincent

[1]: Or may be the answer to your suggestion... Make the server
publish an https+self_signed+[urllib|pycurl]://localhost url and
register the special purpose https clients... I'm not sure the
result would have been clearer though... I'll keep the suggestion
in mind for future cases though.