re: [Haskell-cafe] HTTP package freezes on Windows 7
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"
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 } } } } ] }
On Tue, Mar 16, 2010 at 3:12 PM, Phil
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: simpleHTTP (getRequest " http://maps.google.com/maps/api/geocode/json?address=London&sensor=false") 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: http://hackage.haskell.org/package/HTTP-4000.0.9 I found this: http://hackage.haskell.org/packages/archive/HTTP/4000.0.9/doc/html/src/Netwo... 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
participants (2)
-
Jason Dagit -
Phil