snoyberg
Provide way to determine if a Manager supports TLS
I have a library that needs the consumer to give me a Manager (since that's out of scope for the library). However, I can either make requests over HTTP or over HTTPS but I have no way of knowing from the Manager which one to use. I can't think of an easy way to specify that information in the current design of Manager but I think it would be valuable.
Well, it's a terribly ugly hack, but:
#!/usr/bin/env stack
-- stack --resolver lts-8.5 script
import Network.HTTP.Client
import Network.HTTP.Client.Internal
import Network.HTTP.Client.TLS
import System.IO.Unsafe (unsafePerformIO)
import Control.Exception
main :: IO ()
main = do
newManager defaultManagerSettings >>= print . hasTLS
newManager tlsManagerSettings >>= print . hasTLS
hasTLS :: Manager -> Bool
hasTLS m = unsafePerformIO $
(mTlsConnection m Nothing "" (-1) >> error "Connection must fail")
`catch` \e ->
case fmap unHttpExceptionContentWrapper (fromException e) of
Just TlsNotSupported -> return False
_ -> return True
(You may need to stack upgrade first.)
Haha...I had thought of that. :/ This will work for now in my use case (I don't need unsafePerformIO since I'm already in IO) but obviously it'd be nice to have a better option. Thanks for writing it out though. Your hack is better than my hack was going to be.
I'm not opposed to extending Manager with such information, though of course ManagerSettings would need to be tweaked a bit too. Want to send a PR?
On Wed, Mar 15, 2017 at 5:08 PM, Elliot Cameron [email protected] wrote:
Haha...I had thought of that. :( This will work for now in my use case (I don't need unsafePerformIO since I'm already in IO) but obviously it'd be nice to have a better option.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/snoyberg/http-client/issues/266#issuecomment-286771675, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBBwLxXNtHTJ1wnZhbBdqiaK1azi5Vks5rl_8EgaJpZM4MeBNK .
I would happily but the design seems a bit non-obvious. Right now Manager's fields are mostly callbacks. There's no easy way to inspect a callback for TLS support other than the way you just defined. Adding a new Bool field or something would obviously work but it's awkward since the two fields have a functional dependency but it's not being captured anywhere. If that doesn't bother you, I could just add a flag. But if you have a better idea I'm all ears.
I'm honestly not thrilled about a flag, but it's not that much of a problem. I've never had anyone ask for this functionality though, so perhaps just adding the hacky approach I described and calling it a day is sufficient.
On Wed, Mar 15, 2017, 5:18 PM Elliot Cameron [email protected] wrote:
I would happily but the design seems a bit non-obvious. Right now Manager's fields are mostly callbacks. There's no easy way to inspect a callback for TLS support other than the way you just defined. Adding a new Bool field or something would obviously work but it's awkward since the two fields have a functional dependency but it's not being captured anywhere. If that doesn't bother you, I could just add a flag.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/snoyberg/http-client/issues/266#issuecomment-286774991, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBB7KmCNKbl-Mn3lSX6JrJi4vnzGAyks5rmAFbgaJpZM4MeBNK .
How would you feel about adding a function like my tryTlsOrDegrade into http-client itself? It's not quite as hacky since it will use the TLS connection if it can. It's not as reusable has hasTLS but my guess is that this is probably the main reason anyone would want to know.
https://github.com/Ziptastic/ziptastic-haskell/blob/6c36627487b2c1e1285f252c1598218af97d9f98/ziptastic-client/src/Ziptastic/Client.hs#L122-L133
Looks like a very specialized use case going on there, I don't think it warrants being in the main library.
It probably is, but I can imagine there are other consumers of http-client that are currently relying haphazardly on the user to construct the correct kind of Manager in order for the library code to work. From a library perspective, the only other way to avoid that is to depend on http-client and http-client-tls and create safer creation functions with different types. I doubt anyone goes that route. I do struggle to imagine another use case for hasTLS other than "Use TLS if possible without crashing" which is what I wanted.