VFP 9.0 API Troubles After Server Upgrade

JasonCannon · Apr 27, 2023

Hello,

A vendor I work with upgraded a few of their servers we use and now a VFP program that connects to it via its APIs has started erroring.

This code use to work.

Code:

**** HyperCaster API Info
sHyperCaster = "[URL unfurl="true"]http://192.168.14.235/"[/URL] 
sADDFolder = "content_api"
sCMbyFN = "content_metadata_by_filename/"
fnMedia = "CHURCH_ADBC_20230122.mov"

oXMLHTTP = CREATEOBJECT("Microsoft.XMLHTTP")

*** Get metadata from HyperCaster
*** Content Metadata by Filename POST
oXMLHTTP.Open("POST", sHyperCaster + sCMbyFN + fnMedia, .f.)
oXMLHTTP.setRequestHeader('Content-Type', 'application/x-[URL unfurl="true"]www-form-urlencoded')[/URL]
oXMLHTTP.Send()
		
lcSendText = sHyperCaster + sCMbyFN + fnMedia
? lcSendText
		
lcResultText = oXMLHTTP.responseText
STRTOFILE(lcResultText,"C:\Temp\VFP\PostResult-"+fnMedia+".txt")

Instead now the PostResult file sending this:

XML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "[URL unfurl="true"]http://www.w3.org/TR/html4/loose.dtd">[/URL]

<html xmlns="[URL unfurl="true"]http://www.w3.org/1999/xhtml"[/URL] xml:lang="en" lang="en">

<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
  <title>Not Found</title>
  <link rel="icon" href="/favicon.ico" type="image/x-icon" />
  <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />
  <style media="screen" type="text/css">
    html { font-family: "Trebuchet", "Trebuchet MS", sans-serif; padding: 85px 10px; font-size: 19px; line-height: 1.4; color: #737373; background: #f0f0f0 url("/images/500_error_background.png") }
    body { max-width: 575px; _width: 575px; padding: 30px 20px 50px; border: 1px solid #b3b3b3; -moz-border-radius: 4px; -webkit-border-radius: 4px; border-radius: 4px; margin: 0 auto; -moz-box-shadow: 0 1px 15px #333, inset 0 1px 0 #fff; -webkit-box-shadow: 0 1px 15px #333, inset 0 1px 0 #fff; box-shadow: 0 1px 15px #333, inset 0 1px 0 #fff; background: #fcfcfc; text-align: center; }
    h1 { margin: 10px; font-size: 34px; text-align: center; }
    p { margin: 1em 0; text-align: center;}
    img { margin: -10px auto 16px auto; }
    ul { margin: 40px auto 0 auto; padding: 0; list-style-type: none; text-align: center; }
    ul li { font-size: .9em; margin:10px 8px; display: inline; text-align: center; }
    li a { text-decoration: none; }
    a img {border: none; }
    div.dialog { max-width: 500px; _width: 500px; margin: 0 auto; }
  </style>
</head>

<body>
  <div class="dialog">
    <a href="[URL unfurl="true"]http://www.telvue.com/"[/URL] target="_blank"><img id="logo" src="/images/telvuelogo.gif" height="68" width="246"  alt="TelVue Corporation" title="TelVue Corporation" /></a>
    <h1>Page Not Found</h1>
    <p>Sorry, you may have mistyped the address or the page may have moved.</p>
    <ul>
      <li><a href="[URL unfurl="true"]http://telvue.com/support/"[/URL] target="_blank">Technical Support</a></li>
      <li><a href="[URL unfurl="true"]http://www.telvue.com/support/product-documentation/"[/URL] target="_blank">Product Documentation</a></li>
      <li>(800)-885-8886</li>
    </ul>
  </div>

</body>
</html>

Any thoughts or recommendations? I have reached out them and waiting to hear back, too

Much thanks,
Jason....

"..if you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."
-- Anne Isabella Thackeray Ritchie.

tomk3 · Apr 27, 2023

Hello,

<title>Not Found</title>
I think that the url (Ip adress) is not correct (anymore), maybe the new servers got new ones.

HTH
regards
tom

JasonCannon · Apr 27, 2023

The new servers did not get new IPs. The IP is correct.

The title not found I believe is referring to the "CHURCH_ADBC_20230122.mov" from the fnMedia = "CHURCH_ADBC_20230122.mov" not being found. But I have confirmed that is on there. And if I take the combination of those variables:
- sHyperCaster + sCMbyFN + fnMedia =

Code:

[URL unfurl="true"]http://192.168.14.235/content_metadata_by_filename/CHURCH_ADBC_20230122.mov[/URL]

And put it in a browser, it works. See image.

But the body of the error returned does say page not found so I am not 100% sure that the <title> is referring to the title of the program.

So that is what is making me think there is something to with how VFP is sending it.

Thoughts?

"..if you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."
-- Anne Isabella Thackeray Ritchie.

JasonCannon · Apr 27, 2023

This line was the problem:

Code:

oXMLHTTP.Open("POST", sHyperCaster + sCMbyFN + fnMedia, .f.)

POST needs to be GET. For some reason, the older servers did not seem to mind.

Code:

oXMLHTTP.Open("GET", sHyperCaster + sCMbyFN + fnMedia, .f.)

Found out that...

Brian w/ Telvue> said:
Where you put

HTTP:

[URL unfurl="true"]http://192.168.14.235/content_metadata_by_filename/CHURCH_ADBC_20230122.mov[/URL]

in the browser it sends the request as a GET request. POST is usually reserved for creating resources.

"..if you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."
-- Anne Isabella Thackeray Ritchie.

Chris Miller · Apr 27, 2023

Just to explain why a POST could have worked previously:

The difference of a POST and GET request is that a POST usually has a body sent with it. But technically also a GET request can send data in a body. And both request types arrive at the HTTP service (listening to requests on port 80 usually), no matter if POST or GET or other types of request. So also a POST request arrives at the same endpoint.

Your code does not send a body, that would e parameter of oXMLHTTP.Send(). But the line previous to that points out that the developer writing that intended to send over something:

Code:

oXMLHTTP.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded')

You only set that header to indicate to the web server, what the body contains.

As you changed to GET, you can now also remove that line, it makes even less sense than in the context of a POST request stating the body content type and then not sending a body, as a GET usually has no body at all.

It's not, by the way, a default that the body sent in a POST request is saved as a file at the given URL so a GET request reads that, that would be a security risk as anybody then could upload any files just by using that request type. And the target of a POST request can also be a script in a script language. That should execute, not be replaced. Then also a GET request should not be able to read code instead of executing the script that is intended to produce the HTML pages. Otherwise, hackers could really simply get at code and find vulnerabilities. You see, even a wrong response to a GET could be a security issue.

A POST is also not risky in that it is a very commonly used request method for an HTML form, for example. And form input also is only saved, if code procesing it does so. The response to a POST used by the submit of an HTML form can be anything a GET request can also serve. As a response of you filling out the HTML form for a login, for example, you could get served your user profile HTML page or when you submit a valid key of a product you get a download from a form submit. This explains, why a POST request can serve the same responses as a GET request can.

It's fine to change to GET as you only intend to get something and don't need the POST mechanism for that, but it's not generally pointing out a misconfiguration of the old server or a security hole fixed with the new server. It's purely the decision of the web server admins to specify how the web server reacts to requests. If you try to get the logo of tek-tips by a POST request, for example, you get a response with error status code 405 and the body then does not contain the logo image but an HTML page pointing out the request method is not allowed. The "Allowed" response header also tells you what request methods are allowed, and GET is among them, but also others.

So what's all the fuzz about request types, if they are interchangeable and all still have the same composition of headers, target URL, and body sent with them? Semantics, purely semantics. For example that a HTML form you configure to use the GET method encodes the user input within the request URL and you then can see the parameters in the address the browser displays and that these parameters are hidden in the post body, if you pick the POST method, is neither making the POST request safer nor better. The input is still only transferred securely if the transfer protocol is HTTPS and not just HTTP. And it's just semantics and standard implementation of a browser to encode the HTML form input values this or the other way, so this is more a topic of compliance to the decided standards, no more, no less.

I guess newer webserver versions are just preconfigured to only allow GET requests to files that clearly are media files, a POST makes no sense semantically, even though it would be harmless and the web server could decide to react to both requests the same way, just serving the file.

Of course, I don't know why there even was the intent to send a request body. Maybe that code was just taken from an example of a POST request and thus "misusued". Maybe there originally was something sent with the POST request. In some sites it would not be unusual that every request has authentication with it. For example, a cryptographic signature could be sent with each request to allow the server to know the client request is genuine, even if not using HTTPS. Such authentication-related things are usually within request headers, though, not a request body.

Chriss

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

VFP 9.0 API Troubles After Server Upgrade

JasonCannon

IS-IT--Management

tomk3

Programmer

JasonCannon

IS-IT--Management

JasonCannon

IS-IT--Management

Chris Miller

Programmer

Similar threads

Part and Inventory Search

Sponsor