When http-request is called with :want-stream t (or even when nil), it would be nice to have a public API to retrieve the local and remove address and port of the TCP connection.
Currently, we have wrapped streams over the native connection stream, which should be considered drakma implementation details, (and I assume could vary depending on the options, chunked/not chunked, ssl, proxy?), and the connection stream is CL implementation specific (assuming usocket is not used, I've not looked, drakma implementaiton detail). So it would be quite inconvenient to access those elements.
I would suggest to add two opaque objects in the result values of http-request one for the socket information, and one (optional) for the security information, with the reader API to query them.
An alternative could be to provide the API directly on the stream returned, but this may be inconvenient in case the socket is closed (we'd still want to remember the addresses and port used), or because of the various implementations and wrapper streams on those sockets.
So instead, I'm suggesting an opaque object that could be filled by http-request before losing forgetting the reference to the usocket:socket, with readers similar to the usocket API on it:
When
http-requestis called with:want-stream t(or even whennil), it would be nice to have a public API to retrieve the local and remove address and port of the TCP connection.Currently, we have wrapped streams over the native connection stream, which should be considered drakma implementation details, (and I assume could vary depending on the options, chunked/not chunked, ssl, proxy?), and the connection stream is CL implementation specific (assuming
usocketis not used, I've not looked, drakma implementaiton detail). So it would be quite inconvenient to access those elements.This issue is linked to https://github.com/edicl/drakma/issues/116
I would suggest to add two opaque objects in the result values of http-request one for the socket information, and one (optional) for the security information, with the reader API to query them.
An alternative could be to provide the API directly on the stream returned, but this may be inconvenient in case the socket is closed (we'd still want to remember the addresses and port used), or because of the various implementations and wrapper streams on those sockets.
So instead, I'm suggesting an opaque object that could be filled by
http-requestbefore losing forgetting the reference to theusocket:socket, with readers similar to theusocketAPI on it:optionally, drakma could also provide (which return the list of address and port):