On 7/15/2017 11:37 AM, Frederick Chin wrote:
> Currently, my HTML, JS and PHP files are in the content folder served by EWB's web server. The PHP file is referencing data from my local MYSQL. As advised and confirmed, the TServerRequest returns 'application/octet-stream' for the Request.ResponseContentType and the entire PHP file for the Request.ResponseContent.Text properties because EWB's web server does not handle PHP files..

It behaves exactly as it should - you're not using it right.

Any other web server in the world does the exact same thing - they would
return content of the PHP (or any script file).

The only way web server can execute PHP script is to install PHP and
integrate it with the web server (if supported) so it "knows" to execute
the Script. EWB web server does not do that today since if you're using
PHP and other web server you likely would not be using EWB web server
anyways.


> If I move the PHP file to a remote web site with the URL of 'tsw.carat.my/getgstaw.php' with an expected parameter of 'domain=tsw.carat.my', what should I enter in TServerRequest.URL?

You can enter "http://tsw.carat.my/getgstaw.php"

> I tried 'tsw.carat.my/getgstaw.php' and the response error is 'not found'. If I enter 'http://www.tsw.carat.my/getgstaw.php' or 'http://tsw.carat.my/getgstaw.php', the response error is a blank.

That is correct since you provided a relative URL (meaning this assumes
you're using same server you load EWB app from).

So for example if you run this in IDE and app is loaded from
"http://localhost/myapp.html then this will result in
"http://localhost/tsw.carat.my/getgstaw.php" which obviously would be
404 error.

So use proper fully qualified URLs like

   ServerRequest1.URL := 'tsw.carat.my/getgstaw.php';

However once you do and run this (and use server debug tools) you will
notice that your web server is not configured properly for CORS.

Error reported by Chrome is as follows:

"XMLHttpRequest cannot load http://tsw.carat.my/getgstaw.php. No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost' is therefore not allowed access."

So your host is not configured for CORS and cannot access data,

This has been discussed in this thread already multiple times so you
need to fix this by either

1. Enable CORS on your web server that serves PHP

2. Serve your EWB app from the same web server.

If you were to load your EWB app from say

http://tsw.carat.my/myapp.html

then everything should work just one.

And in that case you could actually just use

ServerRequest1.URL := '/getgstaw.php';

or even

ServerRequest1.URL := 'getgstaw.php';

assuming your EWB app and getgstaw.php are in the same folder.


> Note: I test entered 'tsw.carat.my/getgstaw.php?domain=tsw.carat.my' in Chrome and I received a JSON string, as expected.

Yes - web browsers always allow direct response - this does not help you
to detect CORS issues with your web server though.

Raul

On 7/15/2017 12:06 PM, Raul wrote:
> So use proper fully qualified URLs like
>     ServerRequest1.URL := 'tsw.carat.my/getgstaw.php';

This of course should say "http://tsw.carat.my/getgstaw.php"

Raul

Raul wrote:

/*
This of course should say "http://tsw.carat.my/getgstaw.php"
*/

Using Chrome's developer tools, I see the following message.

Mixed Content: The page at 'https://predator2.dynu.com/testcomp.html' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://tsw.carat.my/getgstaw.php?domain=tsw.carat.my&domain=tsw.carat.my'. This request has been blocked; the content must be served over HTTPS.

What are my options now since I am using EWB's web server to serve DBISAM data? Can I use Apache to serve DBISAM data?

--
Frederick

On 7/15/2017 7:59 PM, Frederick Chin wrote:
> Using Chrome's developer tools, I see the following message.
>
> Mixed Content: The page at 'https://predator2.dynu.com/testcomp.html' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://tsw.carat.my/getgstaw.php?domain=tsw.carat.my&domain=tsw.carat.my'. This request has been blocked; the content must be served over HTTPS.
>
> What are my options now since I am using EWB's web server to serve DBISAM data? Can I use Apache to serve DBISAM data?
>

Why not just use HTTPS !? It would be good practice anyways. EWB Web
server does not do TLS natively yet but it's quite simple to so using
stunnel for example.

Apache and dbisam - if it's on windows then it can be done in number of
ways but all would require for you to do some delphi programming to
accomplish this (i.e. there is nothing out of the box AFAIK).

Raul

Raul wrote:

/*
Why not just use HTTPS !? It would be good practice anyways. EWB Web
server does not do TLS natively yet but it's quite simple to so using
stunnel for example.
*/

I do already use STunnel for HTTPS for the EWB application. It looks like I have to also get an SSL certificate for the remote site as well.

/*
Apache and dbisam - if it's on windows then it can be done in number of
ways but all would require for you to do some delphi programming to
accomplish this (i.e. there is nothing out of the box AFAIK).
*/

Regardless of the operating system, it is a bit of a problem because the EWB server does not handle PHP and I now have to use two web servers; one for DBISAM and the other for PHP.

--
Frederick

>>Frederick Chin wrote:


>>There is no need to perform StrReplace() calls on the returned JSON data.

--
>>Frederick

Frederick,
If I don't execute the StrReplace calls, then then extra brace and the beginning and end of the JSON string caused the loaddata to fail.

I will reconfirm but that is what it was doing.

I don't see where you changed my code, correct?

Big Al

Big Al wrote:

/*
If I don't execute the StrReplace calls, then then extra brace and the beginning and end of the JSON string caused the loaddata to fail.
*/

If you need to use StrReplace(), it means that your JSON returned data is not correct.

My PHP code snippet for the return of the JSON data is:-

$rows = array();
while($r = $result->fetch_assoc()) {
  $rows[] = $r;
}
header('Content-type: application/json');
echo json_encode(array('rows'=>$rows));

--
Frederick

Frederick,

<< I have searched for the reason and it seems that this is normal and does not affect the JSON data. You can make Chrome not show the message by using "text/html" for the content type. >>

I can assure you that Chrome does *not* display this message for normal JSON exchanges for the EWB database API.  This type of warning isn't just there for no reason.  It indicates that what you *thought* you were receiving (what you told the browser to request) isn't what came back from the web server.  When you request JSON using the correct Content-Type header and Chrome indicates that what came back wasn't JSON, then it means that the web server that handled the request was most likely sending back an error page or something similar that is plain text or HTML.

<< The thing is I thought the EWB web server is calling the PHP script because it does not display an error and it is simply returning unexpected Response content. Another reason why I think this way is when I am running the application using the internal server, Apache is not running at all. >>

That is completely incorrect.  The EWB Web Server cannot, and won't ever be able to, handle or execute, PHP scripts.  If you try to access a PHP script via the EWB Web Server you'll just end up with the PHP script being returned as text (which may explain the above).

The internal EWB Web Server is used to *load* the application loader (HTML) and script (JS) files.  That's it.  After that the only time it will handle any requests is:

a) If you execute a server request (TServerRequest) and the target URL used is a relative URL (does not contain a domain or port, such as \home.html) or is an absolute URL for the localhost domain or the machine's IP address (or 127.0.0.1).

b) You try to load an image or some other type of external content and the target URL follows the same rules as a)

Any request to any other type of URL will *not* be handled by the EWB Web Server.  It will be handled by whatever web server is listening and responding to HTTP requests for the ultimate target IP address pointed to by the DNS records for the domain being referenced.

Tim Young
Elevate Software
www.elevatesoft.com

Frederick,

<< Regardless of the operating system, it is a bit of a problem because the EWB server does not handle PHP and I now have to use two web servers; one for DBISAM and the other for PHP. >>

Please point me to the literature on our web site, or anywhere else for that matter, that indicates or gives the impression that EWB supports executing PHP scripts in the EWB Web Server that we provide with the product.

I'm sorry if this is coming off as harsh, but you're taking a fundamental misunderstanding of the product (on your part) and pushing it on us as if we somehow gave you the impression that EWB has anything to do with PHP.  If anything, I'm *extremely* hostile to using PHP because I think it's one of the worst languages to come along in quite a while and only "succeeded" because it was free and included with every low-cost hosting provided on the planet.  Developers created a lot of successful sites with PHP *despite* its glaring issues, not because of its strengths.

At any rate, all of this will soon become a moot point and you'll be able to just execute EWB Object Pascal code on the EWB Web Server.  2.07 will be the start of this new back-end support.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

/*
Please point me to the literature on our web site, or anywhere else for that matter, that indicates or gives the impression that EWB supports executing PHP scripts in the EWB Web Server that we provide with the product.
*/

I really have no idea if EWB supports PHP or not because as I have said in my first message of this thread, I had read the manual a number of times but could not figure out how to do it. My message posting was based on the following situations:-

A TServerRequest to a PHP script for:-

1.   EWB app --> EWB Web Server
Server response code: HTTP_OK
Returned content Type: application/octet-stream
Returned content: Entire PHP script

2.   EWB app --> Apache Server
Server response code: HTTP_OK
Returned content Type: application/json
Returned content: JSON data

There was no malice at all and my question was why EWB web server was returning incorrect data or correct in the way you have designed it. If this is expected behaviour and, you have confirmed so, then, how do I respond to it, or better yet, how should EWB web server respond to a server request for a script that it does not support.

/*
I'm sorry if this is coming off as harsh, but you're taking a fundamental misunderstanding of the product (on your part) and pushing it on us as if we somehow gave you the impression that EWB has anything to do with PHP.  If anything, I'm *extremely* hostile to using PHP because I think it's one of the worst languages to come along in quite a while and only "succeeded" because it was free and included with every low-cost hosting provided on the planet.  Developers created a lot of successful sites with PHP *despite* its glaring issues, not because of its strengths.
*/

I have no preference on the type of scripting language to use to access MYSQL. As long as it gets the job done, I really don't care. I just happen to know PHP better, that's all. If Object Pascal could be used, that would be so much better since I do not have to learn another language.

But you can't really fault the availability of PHP and other free scripting languages because if everyone had to pay or wait for the "perfect" language to create web applications, the Internet would not be what it is today.

--
Frederick