So now I have a successful call thanks to wwhttp, but the foxpro .deserialize crashes on the multi line/record jSon string. But I lied it seems about the error message I get in deserialzing, sorry about that. Actual message can be seenhere: http://69.33.220.165/screen1.jpg



>>It seems I have to have .Net installed to use the deserializer, correct? That is a deal killer.
>
>DeserializeJson() requires .NET yes. It's the most reliable way though as it uses a full JSON parser to parse the JSON. There's also Deserialize() which uses FoxPro code but is not as reliable - especially with arrays, but you can give it a try. It looks like the issue though isn't with the JSON parser (so json.prg probably works) but with the actual HTTP call.
>
>> deal killer
>
>Why? Post XP all machines have .NET 2.0 installed and I bet even XP machines today have .NET 2.0 installed as so many apps use it.
>
>+++ Rick ---
>
>>
>>I have other deserializing code, but the issue is when the jSon is really a set of records rather than just a long string.
>>
>>>Almost certainly the issue is either a cookie or authentication that is happening when you go to the site with the browser but not with your foxpro HTTP client code. XmlHttp uses the WinInet stack so it shares cookies between sessions that's why ti works once you log in with a browser.
>>>
>>>Uhm you say you get a 200 response but you get Internal Server Error (which is a 500.x error)? How are you getting both?
>>>
>>>The best thing to do is trace the browser session. Use fiddler (http://telerik.com/fiddler) and then clear all your cookies first. Then go to the site and see what you capture with Fiddler. But try to hit the page with the browser directly rather than through other links first. Many sites use internal redirection with cookie assignments in those redirects to enforce 'live' users.
>>>
>>>Finally - XMLHTTP is a pain to work with and it doesn't do very well for more advanced HTTP concepts. If you have security or extra redirects, or binary data etc. it doesn't work very well.
>>>
>>>Since I know you use West Wind stuff already it might be much easier to:
>>>
>>>

>>>DO wwHttp
>>>do wwJsonSerializer
>>>loHttp = CREATEOBJECT("wwHttp")
>>>lcJson = loHttp.HttpGet(lcUrl)
>>>IF (loHttp.nError # 0)
>>>   ? loHttp.cErrorMsg
>>>   RETURN
>>>ENDIF
>>>
>>>loSer = CREATEOBJECT("wwJsonSerializer")
>>>loResult = loSer.DeserializeJson(lcJson)
>>>
>>>? loResult.Value
>>>...
>>>

>>>
>>>+++ Rick ---
>>>
>>>
>>>>I have an application that verifies data by calling an HTML page from a third party, and that HTML page returns a JSON string which I parse.
>>>>
>>>>I have had the IT folks open the firewall to access the site, let's call it THESITE.HTML.
>>>>
>>>>Then I do this:
>>>>

>>>>local oxml ,   oAuto, oJson, lcJson
>>>>lcKey =   ...(whole bunch of code I cannot show that creates the string to be passed)
>>>>lcOpen = ...(URL I cannot show you)
>>>>oXml = CREATEOBJECT("Microsoft.XMLHTTP")
>>>>oXml.OPEN( "POST", lcOpen, .F.)			&& false sets to synchronous, returns only after call completes
>>>>oXml.SEND()
>>>>
>>>>IF oXML.statustext <> "OK" 
>>>>	=MESSAGEBOX("Cannot process "+CHR(13)+"Error: "+oxml.statustext,16,"VIN")
>>>>	RETURN
>>>>ENDIF
>>>>IF "SERVER_ERROR" $ oxml.responsetext
>>>> . . .some error code
>>>>ENDIF
>>>>
>>>>oJson=NEWOBJECT("json","json.prg")
>>>>* have to fix a couple things the parses does not like, although perfectly valid
>>>>* json
>>>>* #1, using [] for empty values
>>>>lcJson = oxml.responsetext
>>>>lcJson = STRTRAN(lcJson, "[]", '""')
>>>>* #2 our parses does not like the [ or ] characters, also valid but not needed
>>>>lcJson = STRTRAN(lcJson, "[", "")
>>>>lcJson = STRTRAN(lcJson, "]", "")
>>>>
>>>>oAuto=oJson.parse(lcJson)
>>>>
>>>>&& . . . update some values
>>>>
>>>>thisform.Refresh
>>>>
>>>>

>>>>
>>>>Now the problem: I always receive an OK 200 connect but get an internal server error message from the web site, UNLESS I have opened a browser and previously gone to the SAME exact URL with the SAME exact string. Once I have done that, I could close the browser and my code works fine. But since there are about 1000 lookups a day, that is not a great plan <s>.
>>>>
>>>>XMLHttp is supposed to work with the machines WINET stack and use the same HTTP call as a browser, but something is off here.
>>>>
>>>>What am I missing?
>>>>
>>>>TIA