ErrorClosed exception from Network.HTTP.simpleHTTP - attempt to upload images via XML-RPC using haxr

Question

I am trying to use haxr 3000.8.5 to upload images to a WordPress blog using the metaWeblog API --- specifically, newMediaObject .

I got it for working with small images by successfully loading 20x20 icons in PNG and JPG formats. However, when I try to use medium-sized images (say 300x300), I get an ErrorClosed exception, presumably from HTTP (I used the diving source a bit, and found that haxr ended up calling Network.HTTP.simpleHTTP ).

Can anyone shed some light on the reasons why a simpleHTTP call might fail using ErrorClosed ? Suggestions for attempts and possible workarounds are also welcome.

Below are links to the full output of tcpdump from a successful download and from a failed download .

The code (sanitized) is also shown below, if used.

 import Network.XmlRpc.Client (remote) import Network.XmlRpc.Internals (Value(..), toValue) import Data.Char (toLower) import System.FilePath (takeFileName, takeExtension) import qualified Data.ByteString.Char8 as B import Data.Functor ((<$>)) uploadMediaObject :: FilePath -> IO Value uploadMediaObject file = do media <- mkMediaObject file remote "http://someblog.wordpress.com/xmlrpc.php" "metaWeblog.newMediaObject" "default" "username" "password" media -- Create the required struct representing the image. mkMediaObject :: FilePath -> IO Value mkMediaObject filePath = do bits <- B.unpack <$> B.readFile filePath return $ ValueStruct [ ("name", toValue fileName) , ("type", toValue fileType) , ("bits", ValueBase64 bits) ] where fileName = takeFileName filePath fileType = case (map toLower . drop 1 . takeExtension) fileName of "png" -> "image/png" "jpg" -> "image/jpeg" "jpeg" -> "image/jpeg" "gif" -> "image/gif" main = do v <- uploadMediaObject "images/puppy.png" print v 

Answer 1

 21:59:56.813021 IP 192.168.1.148.39571 > ..http: Flags [.] 22:00:01.922598 IP ..http > 192.168.1.148.39571: Flags [F.] 

The connection is closed by the server after 3-4 seconds, since the client did not send any data to prevent slow attacks and similar ddos ​​attacks. (F is the FIN flag to close one direction of a bidirectional connection).

The server does not wait for the client to close the connection (wait for eof / 0 == recv (fd)), but uses syscall; the kernel on the server will respond with [R] eset packets if it receives additional data, as you can see at the end of your dump.

I assume that the client first opens an http connection and then prepares data that takes too much time.