<br><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 3:12 PM, Phil <span dir="ltr"><<a href="mailto:phil.beadling@googlemail.com">phil.beadling@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im">
On 16/03/2010 01:05, Phil wrote:
<blockquote type="cite">Scrap
my original query - the problem isn't as black & white as I
thought.
<br>
<br>
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.
<br>
<br>
I'm guessing this is more likely to be a Windows issue rather than a
Haskell issue - any ideas?
<br>
</blockquote>
<br></div>
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.<br>
<br>
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.....<br>
<br>
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?<br></div></blockquote><div><br></div><div>If you check the type of:</div><div>simpleHTTP (getRequest "<a href="http://maps.google.com/maps/api/geocode/json?address=London&sensor=false">http://maps.google.com/maps/api/geocode/json?address=London&sensor=false</a>")</div>
<div><br></div><div>You'll see that it is, :: IO (Network.Stream.Result (Response String))</div><div><br></div><div>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.</div>
<div><br></div><div>I started looking through the source to see if this is true. You can get to it from the haddocks:</div><div><a href="http://hackage.haskell.org/package/HTTP-4000.0.9">http://hackage.haskell.org/package/HTTP-4000.0.9</a></div>
<div><br></div><div>I found this:</div><div><a href="http://hackage.haskell.org/packages/archive/HTTP/4000.0.9/doc/html/src/Network-HTTP-HandleStream.html#sendMain">http://hackage.haskell.org/packages/archive/HTTP/4000.0.9/doc/html/src/Network-HTTP-HandleStream.html#sendMain</a></div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
<br>
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.....<br></div></blockquote><div><br></div><div>I tried it on OSX 10.5.8 and it behaved correctly here.</div><div><br></div><div>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?</div>
<div><br></div><div>Good luck!</div><div>Jason</div></div>