ssl_peer_certificate/2 does not work for some streams

[triska]

We run into this problem as part of #102. Please consider the following code:

:- use_module(library(http/http_open)).

uri_location(Uri, Code-Location, In) :-
        http_open(Uri, In, [redirect(false),
                            header(location, Location),
                            status_code(Code)]).

The following works exactly as expected to obtain the certificate of www.aap.nl:

?- uri_location('https://www.aap.nl', Cs, In),
   ssl_peer_certificate(In, Cert).

However, the following slightly modified URL no longer works:

?- uri_location('https://www.aap.nl/nl', Cs, In),
   ssl_peer_certificate(In, Cert).

This yields:

ERROR: Domain error: `ssl_stream' expected, found `(0x7fba82657440)'
ERROR: In:
ERROR:    [9] ssl:ssl_peer_certificate((0x7fba82657440),_13520)
ERROR:    [7] 

Since the host is exactly the same (www.aap.nl), we expect the exact same behaviour for ssl_peer_certificate/2.

[JanWielemaker]

The problem is that the stream returned by http_open/3 is not always the SSL stream(-pair). Notably if Keep-alive is enabled it is a range_stream and if chunked encoding (this case) is used is a chunked stream. In the future we're more likely to see more than less of these filter streams.

Now there are some options. One is to make ssl_peer_certificate/2 follow the chain of upstream streams to find the SSL stream. The other is to add something to the HTTPS options of http_open/3 to get the peer certificate. It seems the latter could be done inside the HTTPS http_protocol_hook/5. I do not have a clear preference.

[triska]

To me, at least from a first look, making ssl4pl.c automatically follow the streams upstream seems preferable. This is because only one stream is typically of interest to users (namely that which they actually use to communicate with the peer), and having to deal with two or even more separate streams for different purposes seems cumbersome and error-prone, especially if they arise implicitly and are naturally chained together, as in this case.

Please note that both ssl_peer_certificate/2 and ssl_peer_certificate_chain/2 are affected.

[JanWielemaker]

Surely it does no harm. Pushed 96c80cd that fixes this example.