3

I don't know why my code breaks. At first I thought it was because parseURL gives [] for the requestHeaders. Okay, so maybe I just need to tell it what the resquestHeaders should be. Well, I examined the requestHeaders generated from my old, working code. It too, returns a []. So now I am out of ideas. Below is the old working code, followed my things I have been trying in GHCi with with new conduits based library.

captureRawJson :: IO Response
captureRawJson = do
    nManager <- newManager
    jRequest <- parseUrl url :: (IO (Request IO))
    jResponse <- httpLbsRedirect jRequest nManager
    closeManager nManager
    return jResponse

the above works fine, here's what I have been trying to do while migrating, and the error I receive.

Prelude Network.HTTP.Conduit> nManager <- newManager def
Prelude Network.HTTP.Conduit> jRequest <- parseUrl "https://10.69.69.1/cgi-bin/qaLinkEditor.cgi?json=1" :: (IO (Request IO))
Prelude Network.HTTP.Conduit> let response = httpLbs jRequest nManager
Prelude Network.HTTP.Conduit Control.Monad.Trans.Resource> runResourceT response
*** Exception: error unexpected packet: Handshake [ServerHelloDone]

So as you can see, it's almost exactly the same code. So I would like feedback on what has changed, and what I should be looking at more closely. Also, how can I examine the http headers being sent back and forth between my client code and the server?

Uli Köhler
  • 13,012
  • 16
  • 70
  • 120
  • The error message is coming from tls, not from http-conduit, so I'm not sure it's really a change in http-conduit. Can you try recompiling http-enumerator against the newest tls package and see what happens? – Michael Snoyman Feb 06 '12 at 05:28
  • I only have tls 0.8.5 (the latest afaik) installed, so that has to be what http-enumerator built against. –  Feb 06 '12 at 19:51
  • @Michael - Here's the status. I upgraded to 0.7.2.5 of http-enumerator, which removed the impetus to migrate to http-conduits. So there's no real urgency. However, I'd like to play with the cool kids and figure out how to get http-conduits working if possible. –  Feb 06 '12 at 21:26
  • If you can reproduce the problem against a public server, then we can try and debug it. But we can't test against a private server. – Michael Snoyman Feb 07 '12 at 06:02
  • Okay, that will take some time to pull off, but I think I can do it. –  Feb 07 '12 at 20:11

1 Answers1

1

I believe this was solved with some changes in the tls packages. I just released http-conduit 1.2.5, please have a look and see if it solves the problem.

If you still get an error message, it could be that the SSL cert doesn't match the hostname you're connecting to.

Michael Snoyman
  • 31,100
  • 3
  • 48
  • 77