Access PHP-website using Labview 8

[rmp]

Thanks Greg,

I'm curious about the LV2011/PC flavor. Have you tried it with this particular website and succesfully retrieved the MapClick.php file? I don't see why the GET.vi would be any different (in result) than the LV8 TCP functions. I'm assuming that it just builds the three required text lines and issues a TCP_write (maybe it also performs the associated TCP_read). But this seems like the same action that the LV8 TCP_open, TCP_write and TCP_write are going to perform.

I'm looking into "Wireshark" which looks like a TCP sniffer. I'm hoping to see exactly what the Chrome browser is sending to retrieve the MapClick.php file. From this I'm hoping to find out how to change my arguments/lines to my TCP_write.

[rmp]

Oooops, I stand corrected. Yes, you're right the LV2011 HTTP Get just works!!! (I just tried your attachment on my PC/LV2011). Hmmmm... is there a way that I can see what Get.vi is doing????

I might have to declare this thread solved though... got a solution with LV... not the version that I wanted... but LV8 is probably no longer supported anyway, so.... I'd like to pursue this LV8/Mac flavor for just a few more days... if no better info then I'll declare this solved... thanks again Greg

[rmp · Accepted solution]

Woohoo!!!... I got it. OK, here's the scoop:

 - LV8/Mac works fine

 - TCP_Open:

- port 80 (which is HTTP port)

- address: forecast.weather.gov

 - TCP_Write:

- line 1: GET /MapClick.php?lat=39.04796&lon=-77.48167&FcstType=digitalDWML HTTP/1.1<CR><LF> (note the " HTTP/1.1"... this is what fixed it)

- line 2: Host: forecast.weather.gov<CR><LF>

- line 3: <CR><LF>

 - TCP_Read (right now I'm just reading 10000 bytes arbitrarily. I think I can read the header first to see the length of the body and then issue another TCP_read to get the rest of the packet)

So, in summary, the fix was to add " HTTP/1.1" to the end of the GET packet. I figured this out from:

- I noticed that my error messages were from "Server: AkamaiGHost". But, Greg's LV2011 function (which worked) gave a header from "Server: Apache/2.2.15 (Red Hat)"

- this led me to believe that somehow I wasn't specifying which server (at the website host) should deal with my GET command

- WireShark is a Network Protocol Analyzer that I downloaded and ran to capture TCP traffic when I went to the desired website with Chrome (my browser). Snooping through the WireShark captured data I found the GET command from Chrome. It had the " HTTP/1.1" at the end of the string (before the <CR><LF>). I noticed that the browser did not show this "HTTP/1.1" at the end of the URL.

 - I added this "HTTP/1.1" to the end of my GET line in the TCP_Write and everything worked fine.

NOTE: My GET command looks much shorter than my GET command from my original post. The reason is that I chose a different output format from the website (XML output) which required this different/shorter URL. I'm sure this will work with the longer URL, and I'm sure that the MapClick.PHP file will have the same info (but in probably different format).

Another NOTE: Based on what I'm seeing: I'm guessing that the way PHP works (in this example) is:

 - my Chrome browser requests the MapClick.PHP file from the website (using HTTP GET command)

 - my Chrome browser then has to basically have a PHP interpreter that deciphers the PHP source code in the MapClick.PHP file

 - the website has built the MapClick.PHP file to:

- include the data that I want

- and, include the PHP commands to allow the browser to render the data the way the website programmed in the PHP file

- I think the PHP file may also provide for UI interaction (like select data fields to display)... I haven't looked for this.

OK, I'm declaring this topic solved... thanks for the help folks...

[Greg-H]

Hi,

Glad to hear you got it to work with LV8 and your MAC.  Thanks for posting your results and the solution you found.

Regards,

Greg

[rolfk · Accepted solution]

---

@rmp wrote:

Another NOTE: Based on what I'm seeing: I'm guessing that the way PHP works (in this example) is:

 - my Chrome browser requests the MapClick.PHP file from the website (using HTTP GET command)

 - my Chrome browser then has to basically have a PHP interpreter that deciphers the PHP source code in the MapClick.PHP file

 - the website has built the MapClick.PHP file to:

- include the data that I want

- and, include the PHP commands to allow the browser to render the data the way the website programmed in the PHP file

- I think the PHP file may also provide for UI interaction (like select data fields to display)... I haven't looked for this.

---

It's an old thread but I was researching the ability to call a PHP server for an upcoming application and came across this here.

The way you describe it is not how PHP is working. Rather the webserver recognizes that this is a PHP request based on the URL (here likely because of the PHP file ending in the URL but it could also be a certain (sub)directory on the server that is configured to not really refer to a page stored on disk but meaning a PHP request instead). It is basically similar to the CGI technology used in the beginnings of the web, and which can still be part of the interface between the web server and the PHP server although with Apache servers this is usually more integrated nowadays. 

The web server then forwards the request to the (either integrated or also external to the web server) PHP server with the entire URL including the parameters.  The PHP server extracts the parameters from the URL line interprets them and then sends back the (usually dynamically generated) response document.

The client (your web browser or also the LabVIEW program) doesn't have to know anything about PHP.  The whole PHP magic is server side, with the server interpreting the request and then generating the answer document based on the request and sending that back to the client. As far as the client is concerned it is simply HTTP(S) and nothing else, except that the URL is not just a simple document path on the server but has additional parameters attached after the URL path.