[Haskell-cafe] HTTP package freezes on Windows 7

0 views
Skip to first unread message

Phil

unread,
Mar 15, 2010, 7:45:37 PM3/15/10
to Haskell Cafe
Hi,

I'm using GHC 6.12.1 on Windows 7. I've built the latest Network
package using Haskell's MinGW and installed HTTP package on top of this.

The code below builds fine, but on execution it just sits there grabbing
ever increasing amounts of memory.

It's a simplified call that I've got working fine in Linux.

Is this a known issue? Anyone else had success using HTTP from Windows?


Thanks,

Phil.


import qualified Network.HTTP as HTTP

main :: IO ()
main
= do
x <- HTTP.simpleHTTP(HTTP.getRequest
"http://maps.google.com/maps/api/geocode/json?address=London&sensor=false")
print x
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Phil

unread,
Mar 15, 2010, 9:05:05 PM3/15/10
to Haskell Cafe, ph...@beadling.co.uk
Scrap my original query - the problem isn't as black & white as I thought.

The below works fine - I've changed the response type from json to
xml.... strange, but for some reason downloading json doesn't work....
it's fine on Linux.

I'm guessing this is more likely to be a Windows issue rather than a
Haskell issue - any ideas?


import qualified Network.HTTP as HTTP

main :: IO ()
main
= do

x <- getLocation
print x

getLocation = (HTTP.simpleHTTP $ HTTP.getRequest url) >>=
HTTP.getResponseBody
where
url =
"http://maps.google.com/maps/api/geocode/xml?address=London&sensor=false"

Phil

unread,
Mar 16, 2010, 6:12:29 PM3/16/10
to Haskell Cafe, ph...@beadling.co.uk
On 16/03/2010 01:05, Phil wrote:
Scrap my original query - the problem isn't as black & white as I thought.

The below works fine - I've changed the response type from json to xml.... strange, but for some reason downloading json doesn't work.... it's fine on Linux.

I'm guessing this is more likely to be a Windows issue rather than a Haskell issue - any ideas?

A bit more testing - this is not a Windows issue per se.  It seems to be a limitation of the HTTP library running on Windows.

I've ran what I consider to be identical commands (in terms of functional use, both perform a HTTP GET on the location given) in Haskell and Python from each of their consoles on the same computer.  The Python one correctly returns exactly what the Haskell one does on Linux.  The Haskell on Windows just hangs.....

However as mentioned earlier SOME http requests do work from Haskell so I don't think it's a problem with my build of HTTP or Network libs.  The simplest example is to replace 'json' with 'xml' in the below query.  The best guess I can make is that XML is deemed renderable, but for some reason JSON is considered to be binary/file data?

Can anyone confirm this behaviour.... I only have one 1 Windows PC, so I can't test on another machine.  If it is a wide problem, I reckon it warrants a bug ticket on the library.....

Logs from console below,

Phil

Haskell / GHCI:
Prelude Network.HTTP> do x <- (simpleHTTP $ getRequest "http://maps.google.com/maps/api/geocode/json?address=London&sensor=false") >>= getResponseBody; print x
Loading package bytestring-0.9.1.5 ... linking ... done.
Loading package Win32-2.2.0.1 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package syb-0.1.0.2 ... linking ... done.
Loading package base-3.0.3.2 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package network-2.2.1.7 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.3 ... linking ... done.
Loading package HTTP-4000.0.9 ... linking ... done.

--- Just sits here chewing up processor time and memory.....

Python:
>>> print urllib.urlopen("http://maps.google.com/maps/api/geocode/json?address=London&sensor=false").read()
{
  "status": "OK",
  "results": [ {
    "types": [ "locality", "political" ],
    "formatted_address": "Westminster, London, UK",
    "address_components": [ {
      "long_name": "London",
      "short_name": "London",
      "types": [ "locality", "political" ]
    }, {
      "long_name": "Westminster",
      "short_name": "Westminster",
      "types": [ "administrative_area_level_3", "political" ]
    }, {
      "long_name": "Greater London",
      "short_name": "Gt Lon",
      "types": [ "administrative_area_level_2", "political" ]
    }, {
      "long_name": "England",
      "short_name": "England",
      "types": [ "administrative_area_level_1", "political" ]
    }, {
      "long_name": "United Kingdom",
      "short_name": "GB",
      "types": [ "country", "political" ]
    } ],
    "geometry": {
      "location": {
        "lat": 51.5001524,
        "lng": -0.1262362
      },
      "location_type": "APPROXIMATE",
      "viewport": {
        "southwest": {
          "lat": 51.4862583,
          "lng": -0.1582510
        },
        "northeast": {
          "lat": 51.5140423,
          "lng": -0.0942214
        }
      },
      "bounds": {
        "southwest": {
          "lat": 51.4837180,
          "lng": -0.1878940
        },
        "northeast": {
          "lat": 51.5164655,
          "lng": -0.1099780
        }
      }
    }
  } ]
}

>>>








Jason Dagit

unread,
Mar 20, 2010, 1:24:30 AM3/20/10
to Phil, ph...@beadling.co.uk, Haskell Cafe
On Tue, Mar 16, 2010 at 3:12 PM, Phil <phil.b...@googlemail.com> wrote:
On 16/03/2010 01:05, Phil wrote:
Scrap my original query - the problem isn't as black & white as I thought.

The below works fine - I've changed the response type from json to xml.... strange, but for some reason downloading json doesn't work.... it's fine on Linux.

I'm guessing this is more likely to be a Windows issue rather than a Haskell issue - any ideas?

A bit more testing - this is not a Windows issue per se.  It seems to be a limitation of the HTTP library running on Windows.

I've ran what I consider to be identical commands (in terms of functional use, both perform a HTTP GET on the location given) in Haskell and Python from each of their consoles on the same computer.  The Python one correctly returns exactly what the Haskell one does on Linux.  The Haskell on Windows just hangs.....

However as mentioned earlier SOME http requests do work from Haskell so I don't think it's a problem with my build of HTTP or Network libs.  The simplest example is to replace 'json' with 'xml' in the below query.  The best guess I can make is that XML is deemed renderable, but for some reason JSON is considered to be binary/file data?

If you check the type of:

You'll see that it is, :: IO (Network.Stream.Result (Response String))

In other words, I think the HTTP request is going to return the literal text of the request.  I think this means you're just getting an arbitrary chunk of text back as far as it's concerned.

I started looking through the source to see if this is true. You can get to it from the haddocks:

I found this:

Looks like some versions of HTTP could wait forever with bad servers.  I think it's a red herring though.  That code looks to be disabled.

What I would suggest next for you, is to sniff the network traffic.  Find out if it's spinning but not doing any IO or maybe it's making many requests that come back with 100 Continue and it's doing just that.
 

Can anyone confirm this behaviour.... I only have one 1 Windows PC, so I can't test on another machine.  If it is a wide problem, I reckon it warrants a bug ticket on the library.....

I tried it on OSX 10.5.8 and it behaved correctly here.

Do you have any sort of interesting proxies or otherwise non-vanilla setup?  Is it possible that Windows access controls are blocking it?  Firewall software?

Good luck!
Jason
Reply all
Reply to author
Forward
0 new messages