When I try to make any http request from ghci using http-conduit (both 1.9.6 and 2.0.0.7), I get a FailedConnectionException:

Prelude Network.HTTP.Conduit> simpleHttp "http://google.com"
*** Exception: FailedConnectionException "google.com" 80
Prelude Network.HTTP.Conduit> simpleHttp "http://127.0.0.1/"
*** Exception: FailedConnectionException "127.0.0.1" 80

When compiled, there is no problem. Using the HTTP package also works:

Prelude Network.HTTP> simpleHTTP (getRequest "http://google.com")
Right HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Fri, 28 Feb 2014 11:37:31 GMT
Expires: Sun, 30 Mar 2014 11:37:31 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alternate-Protocol: 80:quic
Connection: close


Prelude Network.HTTP> simpleHTTP (getRequest "http://127.0.0.1/")
Right HTTP/1.1 200 OK
Date: Fri, 28 Feb 2014 11:37:41 GMT
Server: Apache/2.2.24 (Unix) DAV/2 mod_ssl/2.2.24 OpenSSL/0.9.8y
Content-Length: 1945
Connection: close
Content-Type: text/html;charset=UTF-8

It seems related to my machine, as other machines don't seem to have this problem. Any ideas?

I found in an old issue from the now disused http-conduit repo that some people were being affect by a default 5 second timeout when using simpleHttp. What alternative is there when ResponseTimeout is being thrown for most uses? That is, how would the request process be done more manually?

As I mentioned in #40 (comment), I'm writing a wrapper library for http-client.

One of the tests ensures that if an HTTP request results in a cascade of redirects that exceeds the configured limit, a TooManyRedirects exception is thrown.

This test is named redirectOverflow. It fails sporadically on Linux and OS X, while all other tests are rock solid. Here are two failures I just saw:

InternalIOException <socket: 7>: hGetBuf: illegal operation (handle is closed)
InternalIOException recv: invalid argument (Bad file descriptor)

Empirically, the test seems to fail 20-30% of the time. I'm reasonably sure the bug (which I assume is due to a race condition) lies somewhere in the stack below my wreq library, because my use of http-client is so simple.

This should be easy to reproduce, if not necessarily to isolate. Here's a repro that eventually works for me, provided you have the patience to sit for a few minutes to wait for the build and enough runs to demonstrate the problem.

git clone https://github.com/bos/wreq.git
cd wreq
cabal sandbox init
cabal install -j --enable-tests
for ((i=0; i<20; i++)); do
  dist/dist-sandbox-*/build/tests/tests -t redirectOverflow
  echo $? >> runs
done

Hi,

it is probably not http-conduits fault, but this is where the problem surfaces and I need help debugging it further. The testsuite fails with

1) httpLbs TLS
uncaught exception: HttpException (TlsException (HandshakeFailed (Error_Packet_unexpected "Alert [(AlertLevel_Fatal,InternalError)]" " expected: change cipher")))

https://buildd.debian.org/status/fetch.php?pkg=haskell-http-conduit&arch=armel&ver=2.0.0.7-3&stamp=1394800380
and I don’t know what might have caused this.

Quite a few types have unnecessary strict fields that offer no value.

BodyReader
Connection
StatusHeaders
Proxy
RequestBody
Response
ManagerSettings
Manager
NonEmptyList
ConnHost
ConnKey

None of the strict fields on any of these types makes any sense to me, and they actively get in the way of creating fake values for testing.

It's particularly annoying to have strict IO actions. For instance, I can't create a fake Response that has responseClose' set to undefined, because creating the value will immediately throw an error.

I also notice that Request has no strict fields, but most other types have all strict fields. I think it would be best if either all of the strict fields were done away with, or (distant second best) there was a bit of documentation about why the current weird and inconsistent looking setup actually makes sense.

I've been looking at http://hackage.haskell.org/package/url for a convenient way of building my url's with percentage encoding (but perhaps I'm confused here - does percentage encoding already happen automatically in the http* functions?)

Would it make sense to add a constructor for Request from Network.URI?

Currently Request is exported only by the Types module, not the Request module, while Response is exported by both Types and Response. This throws me off constantly when using this package.

known issue — https://github.com/snoyberg/http-client/blob/master/http-client/Network/HTTP/Client/Manager.hs#L330

Also, we don't have any tests for proxies at all.

I'm running a snap-server over TLS. I receive this error when attemping to HTTPS-POST from a backend server to the snap-server. The certs I'm using are not self-signed but rather legit RapidSSL certs.

*** Exception: TlsException (HandshakeFailed (Error_Protocol ("certificate has unknown CA",True,UnknownCa)))

After googling around it seems this is a common problem but none of the solutions I read worked for me, except for this https://haskell.g.hatena.ne.jp/suztomo/20120311/1331478324, which suggests accepting all certs, which is fine, but the API has changed in http-client and I don't think that option is available anymore. It seems according to the tls package docs there are some utilities for testing SSL. After installing tlsI couldn't seem to find them in my cabal in directory. Here's the code I'm using below.

sendPost :: Command -> IO ()
sendPost UnknownCommand = return ()
sendPost cmd = do
  runResourceT $ do
        manager <- io $ newManager conduitManagerSettings
        r <- io $ parseUrl "https://myurl.com:443"
        let req = r
                 { method = "POST"
                 , secure = True
                 , port = 443
                 , path = "updates"
                 , redirectCount = 0 -- don't follow redirects
                 , requestBody = RequestBodyLBS (encode cmd)
                 , checkStatus = \_ _ _ -> Nothing -- accept any status code
                 }
        res <- http req manager
        io $ print "done"

I'm getting this error with http-client-tls-0.2.0.3:

Network/HTTP/Client/TLS.hs:60:40:
    No instance for (Default NC.TLSSettings)
      arising from a use of `def'
    Possible fix:
      add an instance declaration for (Default NC.TLSSettings)
    In the first argument of `mkManagerSettings', namely `def'
    In the expression: mkManagerSettings def Nothing
    In an equation for `tlsManagerSettings':
        tlsManagerSettings = mkManagerSettings def Nothing

I believe it is 30 seconds now, but the documentation says 5 seconds.

Reading through the HTTPbis docs it's clear that in the event of 400 responses from the server there's still a good chance that the server is going to respond with a body of some kind. Right now, this is possible to recover but only through a rather undocumented and, in my opinion, somewhat strange method via the X-Response-Body-Start response header.

What's the reasoning behind this instead of providing a more natural body parameter in the exception? From where I stand it seems like a strange decision.

Above that, right now it's very easy to have managers get closed due to 404 errors—you need to be sure to sneak a try or catch inside of whatever bracket is controlling the manager. Given that a 404 response doesn't necessarily indicate a failure of any kind, what's the reasoning for throwing those as exceptions?

Currently the documentation for ManagerSettings suggests the use of def which does not work. The defaultManagerSettings value is available which works just great for me, but I feel like for consistency purposes either the documentation should change or the instance should be provided.

hi,

i am using http-client with extensible-effects. thus i need a Typeable instance to use Manager with a Reader. can you please provide one? i guess that does need a pvp version bump though.

The library does not expose an abstract interface, so higher level libraries cannot mock this library easily.

This is very common, but I'll refer to this rant to explain why this is bad:
https://pay.reddit.com/r/haskell/comments/28n2kx/the_top_three_things_missing_from_enterprise/cidlgec

The library invites users to create untestable software by using functions in the IO monad directly.

The library should provide a way to mock the response to a request. Thus there should be two backends, one mock backend and one real backend. Both of these backends should be usable through one abstract interface. It could be based on a typeclass or some other technique, but it's important that the user should be able to run tests.

The tests for the http-conduit library itself shows the problematic design. A proper test should not rely on picking a random port and running a server, but should rather test based on fake data through an abstract interface. I think just rewriting the tests to not use any real IO will force a redesign where the library becomes testable.

1. chunked request body works
   expected: "foo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\r"
   but got: "foo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\rfoo\ETX\n\r"

Randomized with seed 4611685481183716993

I have HTTP requests that I'd like to keep the connection open for indefinitely, which I currently do by setting managerResponseTimeout = Nothing, but in the event that the machine streaming the requests goes to sleep, the program currently can't recover well. I'd like the option to set KeepAlive on the socket for the connection for these to allow the connections to be closed out and throw a useful exception.

Asynchronous exceptions are clearly an important component of using an HTTP client library, but it'd be nice to know which functions will throw HTTP exceptions. Right now, I assume that it's everything in the Performing requests section and possible some of the functions in Connection manager.

was the omission of withManager :: ManagerSettings -> (Manager -> IO a) -> IO a on purpose or do i miss some interesting problem with it.

When trying to install yesod-bin from source I see the following:

Preprocessing library http-client-tls-0.2.1.2...
[1 of 1] Compiling Network.HTTP.Client.TLS ( Network/HTTP/Client/TLS.hs, dist/dist-sandbox-f2f83279/build/Network/HTTP/Client/TLS.o )

Network/HTTP/Client/TLS.hs:24:35:
    Couldn't match type `Maybe HostAddress' with `[Char]'
    Expected type: IO
                     (S.ByteString
                      -> (Connection -> IO ())
                      -> String
                      -> Maybe HostAddress
                      -> String
                      -> Int
                      -> IO Connection)
      Actual type: IO
                     (S.ByteString
                      -> (Connection -> IO ())
                      -> Maybe HostAddress
                      -> String
                      -> Int
                      -> IO Connection)
    In the return type of a call of `getTlsProxyConnection'
    In the `managerTlsProxyConnection' field of a record
    In the expression:
      defaultManagerSettings
        {managerTlsConnection = getTlsConnection (Just tls) sock,
         managerTlsProxyConnection = getTlsProxyConnection tls sock,
         managerRawConnection = case sock of {
                                  Nothing -> managerRawConnection defaultManagerSettings
                                  Just _ -> getTlsConnection Nothing sock },
         managerRetryableException = \ e
                                       -> case () of {
                                            ()
                                              | ((fromException e) :: Maybe TLS.TLSError)
                                                == Just TLS.Error_EOF
                                              -> True
                                              | otherwise -> ... },
         managerWrapIOException = let wrapper se = ...
                                  in handle $ throwIO . wrapper}
Building yesod-core-1.2.19...

We are using this in a lot of places and it is pretty handy to use with withManager
Thought it might be a good thing to include, I started to fork and pull-req but you have a lot going on in the tests. I can go ahead and go that route if you think it would be useful.
-- | Use like
-- > withManager (httpLbsMReq someMonadicReqBuilder)
-- to allow all your exceptions to be handled by the Manager in both Request building and http

httpLbsMReq :: MonadIO m => m Request -> Manager -> m (Response L.ByteString)
httpLbsMReq mReq mgr = mReq >>= (\req -> httpLbs mReq mgr)

newManager of http-client uses loop using threadDelay. It seems to me that this is the reason why Mighty uses a little CPU power always. Is it possible to introduce reaper to newManager?

This behaviour makes no sense to me.

The issue seems to be that parseUrl returns a Request with an empty host field, and this gets interpreted as localhost when it should be rejected, as e.g. curl does:

$ curl http://
curl: (6) Could not resolve host: http; nodename nor servname provided, or not known

I have a server that is using square brackets in its queries but attempts to test that server with http-conduit are throwing up:

InvalidUrlException "http://localhost:3010/v0/reflections?id=\"[2,3,4,1000\"]" "Invalid URL"
Bookings

I have got around the problem by translating the brackets into %5B and %5D.

Why no square brackets?

that is, when only connecting to each place once and moving on. This is apparently the worst case workload for the connection manager stuff, but its currently not documented

From a fresh cabal sandbox I get the following build error:

[1 of 1] Compiling Network.HTTP.Client.TLS ( Network/HTTP/Client/TLS.hs, dist/dist-sandbox-25412105/build/Network/HTTP/Client/TLS.o )

Network/HTTP/Client/TLS.hs:60:40:
    No instance for (Default NC.TLSSettings)
      arising from a use of `def'
    Possible fix:
      add an instance declaration for (Default NC.TLSSettings)
    In the first argument of `mkManagerSettings', namely `def'
    In the expression: mkManagerSettings def Nothing
    In an equation for `tlsManagerSettings':
        tlsManagerSettings = mkManagerSettings def Nothing

I was able to get it to build cleanly by using data-default-class and Data.Default.Class instead of data-default and Data.Default, but I don't really understand what's going on here.

http-conduit used to have a socksProxy option for Requests, but it was removed after the separate http-client library was created. Could it be added back?

http-client-conduit is missing the Internal module in the source distribution. It seems like it should just be exposed, since http-client-tls uses it.

This was snoyberg/http-conduit#150, but it seems to be gone now. I find it's still a relevant improvement.

The following program crashes (windows saying "myprog.exe has stopped working"):

module Main where

import qualified Network.HTTP.Conduit as NHC
import Data.ByteString.Lazy.Char8 (unpack)

main :: IO ()
main = do
    body <- NHC.simpleHttp "http://hackage.haskell.org/"
    putStrLn $ unpack body

ghc: 7.6.3

Some package versions:
http-client-0.2.2.3
http-client-conduit-0.2.0.1
http-client-tls-0.2.1.1
http-conduit-2.0.0.8
network-2.4.2.2
bytestring-0.10.0.2

I imagine it's a pretty stable function and it's useful for serializing and communicating Requests to a user.

By parallelism, it might be useful to stabilize and extract the setUri function, but I've never used it in practice—parseUrl is the superior workflow.

For client certificates this restricts manager usage to a single site, unless you like sending out your client certificates to irrelevant hosts. This regression also breaks http-conduit-browser. (https://github.com/exbb2/http-conduit-browser/issues/11)

@snoyberg
You should probably add a connection settings parameter to Request and Manager's mTls/RawConnection.

If you import Network.HTTP.Client, for the Request, def is reported "not in scope". instance Default Request is actually in Network.HTTP.Client.Request, but you cannot import it: it is a hidden module in the package 'http-client-0.2.0.1'

Apparently the only constructor that you have at hand is parseUrl, which is OK, I guess, but not ideal.

Or, I may be missing something.

I am using the applyCheckStatus to manually perform redirections, but this method is not exported anymore, starting from http-client-0.3.6.1. The culprit seems to be the commit 4a9b66b. Note that this method is still mentioned in the example provided for getRedirectedRequest in the same module.

According to section 3.1 of RFC 3986, this behaviour is incorrect:

Although schemes are case-insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters.

h> parseUrl "HTTP://localhost"
*** Exception: InvalidUrlException "HTTP://localhost" "Invalid scheme"

Looking at the code of http-client-openssl and writing a small test harness shows that when using opensslManagerSettings the defaults are extremely insecure.

Using client code such as

import Network.HTTP.Client
import Network.HTTP.Client.Manager
import Network.HTTP.Client.OpenSSL
import Network.HTTP.Client.Request
import Control.Monad.Trans.Resource

main = withOpenSSL $ do
    mgr <- newManager opensslManagerSettings
    req <- parseUrl "https://localhost:8080"
    httpRaw req mgr

and looking at the output of "openssl s_server -accept 8080 -cert rsa1024cert.pem -key rsa1024key.pem" with rsa1024 being a self-signed certificate and corresponding private key we get:

Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MFUCAQECAgMCBALAFAQABDB6hwTqMsao1nDA/tVX60cMt0rz7i6Qm8s+WoujJdoo
kl5MDYclI0YBd0u55uGCAKmhBgIEUoTBHqIEAgIBLKQGBAQBAAAA
-----END SSL SESSION PARAMETERS-----
Shared ciphers:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
CIPHER is ECDHE-RSA-AES256-SHA
Secure Renegotiation IS supported
GET / HTTP/1.1
Host: localhost:8080
Accept-Encoding: gzip

That is, the client accepts the connection even though the certificate is self-signed, and also that the client supports a lot of completely insecure ciphersuites.

I believe your approach with abstracting away the different underlying TLS-implementations is a good one, but I also believe that the abstraction at the moment is leaky and unfortunately dangerous. I think there needs to be a default way for users to specify ciphersuites, specify their CA-chains, specify what kind of certificate verification that should take place, if they use client certificates, et. al.

Kind regards,
dnaq

Hi,

connectionReadLineWith throws OverlongHeaders when header length is more than 1k.

In general, total headers length is usually limited by 4-8-16k.

So I think it worth to increase 1k limit to at least 4k (or even make it customizable).

For example in this feed
http://www.forbes.com/opinions/feed/
there is Accept-Charset header that is about 2k in length so I can't download it with http-conduit.

Hi! After upgrading http-conduit from 1.9.6 to 2.0.0.8 I always get an exception when reading the response body from our API: *** Exception: Error_EOF
This doesn't happen for all https services, so there must be something in the response from our API that triggers it. This did not happen with 1.9.6.

The following code (from the docs) should reproduce it:

module Main where

import Data.Conduit.Binary (sinkFile)
import Network.HTTP.Conduit
import qualified Data.Conduit as C

main :: IO ()
main = do
    request <- parseUrl "https://www.digipost.no/post/api"
    withManager $ \manager -> do
        response <- http request manager
        responseBody response C.$$+- sinkFile "temp.json"

Even though an exception is thrown the entire response is written to temp.json
I tried to trace the execution in GHCI with -fbreak-on-exception but I couldn't locate the exact origin of the exception:

Prelude Main> :set -fbreak-on-exception
Prelude Main> :trace main
Stopped at <exception thrown>
_exception :: e = GHC.Exception.SomeException
                    GHC.IO.Exception.ThreadKilled
[<exception thrown>] Prelude Main> :trace
*** Exception: Error_EOF

Dependencies: conduit -any, http-conduit ==2.0.0.8, base ==4.6.*
(I tried to run cabal install --upgrade-dependencies but it didn't help)

Looking at the code, rawBody is passed to makeChunkdReader in Response.hs:122. But makeChunkedReader seems to ignore it (confusingly, it's called sendHeaders here).

library usage

When writing a library, for efficiency one must write each API request to accept a Manager (or operate in a ReaderT m Manager). This allows one to modify the manager settings, but not the request settings. That requires passing in a separate function Request -> Request.

current solution

I am changing a library to use type ManageRequest = (Manager, Request -> Request) instead of Manager so that the request can be modified.

possible solutions

It seems like something is wrong with the API and that Manager should support default request modification on a per-host basis. An API breaking way to do this would be something like this:

connectionForHost :: Host -> (Request -> Request) -> Manager -> Connection

Where Connection is just a wrapper around Manager and is what would be passed into a library rather than the Manager.

Some details on my use case

My goal is to be able to operate a test suite, similar to #60. I looked into the suggestion of constructing a connection via ManagerSettings, and it does seem possible to construct a mock connection. However, one still needs to mock the final behavior somehow, so I am not sure what the point of this is.

The approach I am taking instead is to mock the server that would be connected to, possibly using a Proxy, but either way I need to modify the Request for every request a Manager is used for.

httpRaw calls httpRaw via responseOpen again in the case where a reused connection is closed (by its peer due to timeout or something). It seems to me that the first httpRaw consumes the request body, so the second httpRaw cannot send the necessary body.

This is a real problem in the reverse proxy feature of Mighty. Relaying POST fails sometime.

Full description available at: https://github.com/blitzcode/http-conduit-bug-reproducer

Originally reported on Reddit: http://www.reddit.com/r/haskell/comments/1s58dh/ann_wai_20_and_httpclient/cdu4ahl

This used to work fine in earlier versions, but apparently a recent update introduced the following problem:

Ambiguous occurrence `catch'
It could refer to either `Prelude.catch',
                         imported from `Prelude' at Network/HTTP/Client/TLS.hs:4:8-30
                         (and originally defined in `System.IO.Error')
                      or `Control.Exception.catch',
                         imported from `Control.Exception' at Network/HTTP/Client/TLS.hs:13:1-24
                         (and originally defined in `Control.Exception.Base')

A complete build log is at http://hydra.cryp.to/build/29943/nixlog/277/raw.

Example to make issue more clear:

> ex <- parseUrl "http://www.example.com/path"
> getUri $ setQueryString [("foo", Just "bar")] ex
http://www.example.com:80/pathfoo=bar

Should it be manually prepended?

StatusCodeException is the exception seen the most. But when it is seen, the request url is nowhere to be found. In an application with different http requests this makes for extra work to track down where in the application the request was sent.

The following would maintain all of the request information, although as stated I would be happy with just the url.

type HttpRspError = HttpException
data HttpError = HttpError Request HttpRspError

What tasks are slated prior to a Hackage release? I may begin using this next week and while I'm more than happy to use a vendor directory for internal builds, I'd like an understanding of when things will be simply cabal buildable.

I'd also love to help out if anything I'm doing can move the project along.

The example is

\_ _ -> Nothing

but should be

\_ _ _ -> Nothing

NixOS runs all builds in a chroot container that doesn't have network access to guarantee that build results are reproducible. The latest version of http-client fails its test suite in that environment: see http://hydra.cryp.to/build/27500/nixlog/1/raw for a complete build log.

To remedy the situation, the entire test suite has been disabled, which is unsatisfactory. Would it be possible to split the test suite into two parts: one that accesses the network and one that doesn't (like the dns package does)? Then we could still run the pure tests.

Trying to send a POST request with a multipart form, I am getting an exception ExpectedBlankAfter100Continue. Unfortunately, I cannot provide the URL as it is internal only. Let me know if there is anything else I can provide to assist.

If the issue is server side, maybe there can be an option to try and continue without expecting the new line?

{-# LANGUAGE OverloadedStrings #-}

import Network
import Network.HTTP.Conduit
import Network.HTTP.Client.MultipartFormData
import qualified Data.ByteString.Lazy.Char8 as BL
import Data.Maybe (fromJust)
import System.Environment (getArgs)
import Control.Monad.IO.Class

main = do
    [x] <- getArgs
    let url = "https://url.net/api.asp"
    --let url = "https://httpbin.org/post"
    withSocketsDo $ withManager $ \m -> do
        r <- flip httpLbs m =<< (formDataBody (request $ BL.pack x) $ fromJust $ parseUrl url)
        liftIO $ BL.putStrLn $ responseBody r

request :: BL.ByteString -> [Part]
request x = [partLBS "data" x]

Not sure exactly what is prompting this. I'm using http-client-conduit-0.2.0.1
I'm trying to determine wether or not this has to due with that fact I'm at starbucks and the connection is horrible. I'm going to retry it from home and see if I get the same thing.

I get the following error message when I attempt to upload files to S3.

uploadToCompletedBucket :: Worker ()
uploadToCompletedBucket = do
  prnt "uploading"
  (acid, cfg, QMsg{..}, conn) <- ask
  let s3cfg = Aws.defServiceConfig :: S3.S3Configuration Aws.NormalQuery
  io $ withManager $ \mgr ->
      do S3.PutObjectResponse { porVersionId = result } <-
             Aws.pureAws cfg s3cfg mgr $ S3.putObject stcompleted (T.concat [qId,".zip"]) $
             RequestBodyLBS "bllaaaahhh"
         io $ print result
  prnt "Put object onto completed bucket!"

Not 100% sure about these line numbers but I believe the code in violation is here:

mkManagerSettings :: NC.TLSSettings
                  -> Maybe NC.SockSettings
                  -> ManagerSettings
mkManagerSettings tls sock = defaultManagerSettings
    { managerTlsConnection = getTlsConnection (Just tls) sock
    , managerTlsProxyConnection = getTlsProxyConnection tls sock
    , managerRawConnection =
        case sock of
            Nothing -> managerRawConnection defaultManagerSettings
            Just _ -> getTlsConnection Nothing sock
    , managerRetryableException = \e ->
        case () of
            ()
                | ((fromException e)::(Maybe TLS.TLSError))==Just TLS.Error_EOF -> True
                | otherwise -> case fromException e of
                    Just (_ :: IOException) -> True
                    _ ->
                        case fromException e of
                            -- Note: Some servers will timeout
                            -- connections by accepting
                            -- the incoming packets for the new
                            -- request, but closing
                            -- the connection as soon as we try to
                            -- read. To make sure
                            -- we open a new connection under these
                            -- circumstances, we
                            -- check for the NoResponseDataReceived
                            -- exception.
                            Just NoResponseDataReceived -> True
                            _ -> False
    , managerWrapIOException =
        let wrapper se =
                case fromException se of
                    Just e -> toException $ InternalIOException e
                    Nothing ->
                        case fromException se of
                            Just TLS.Terminated{} -> toException $ TlsException se
                            _ ->
                                case fromException se of
                                    Just TLS.HandshakeFailed{} -> toException $ TlsException se
                                    _ ->
                                        case fromException se of
                                            Just TLS.ConnectionNotEstablished -> toException $ TlsException se
                                            _ -> se
         in handle $ throwIO . wrapper
    }