Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Unclear XMLHttp behavior
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Contrôles ActiveX en VFP
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01600581
Message ID:
01600732
Vues:
57
>redirection - bingo! The xmlhttp call is not being redirected but the browser call is thru a convoluted set of steps. I will not even pretend to understand why they are doing that, since the call includes an API key for verification, but they are.

Glad wwHttp helped.

Yeah XmlHttp is very bare bones. It doesn't follow auto-redirects and if you need to do authentication or other custom settings like proxies or HTTP overrides it's a real bear to find the right settings (because they're string attributes). Plus - unlike wwHTTP - it doesn't help you format data you might have to post to the server (like form variables etc.). XmlHttp usage should be used only for very simple scenarios, but not as a generic solution to HTTP requests in general.

Aloha,

+++ Rick ---

>
>I am using your whhtp and it is working great. thanks. I should have done that to begin with.
>
>>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
+++ Rick ---

West Wind Technologies
Maui, Hawaii

west-wind.com/
West Wind Message Board
Rick's Web Log
Markdown Monster
---
Making waves on the Web

Where do you want to surf today?
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform