Davinder

Did you open port 8080 on the Ubuntu firewall? 

Ubuntu, and to be honest almost ALL Linux distributions come with all ports blocked by some form of firewall.  The challenge is knowing how to unblock the port since not all Linux versions use the same firewall program/methodology.

What I generally find is the easiest is to run something like the following on the server to make sure the port is open and accessible:

OPEN (1) "[tcp];8080"
WHILE 1
READ RECORD (1,END=*BREAK) R$
PRINT R$
WEND

Then I go to an external workstation and issue:

OPEN (1) "[tcp]serverIP;8080"
WRITE RECORD (1) "Hello World"
WRITE RECORD (1) "Kilroy was here"
CLOSE (1)

On the server you should see the data written.

Should the OPEN fail you can generally assume the port is blocked (or you have the wrong IP address).

This approach will help identify if the port is open and accessible.

Davinder,

Your image indicates the system thinks you are running iNomads and not Webster+.  For Webster+ you need three arguments; the port, the PEM file (if running secure mode else ""), and the root directory for Webster.

So your .sh file should be something like;

 /pxp/pxplus '*ezweb/server' -arg 8080 '' /var/www/sitename/docroot

That likely means the pxp.cgi file is not being found or used. 

Generally the Apache configuration directs the system that any file request ending in .pxp will be handled by the pxp.cgi script.  This is done by the "Action pxplus-srvr /cgi-bin/pxp.cgi" and "AddHandler pxplus-srvr .pxp .pvp" directives.

Its possible your pxp.cgi file is not in the correct directory.  Generally it is in the document root cgi-bin subdirectory based on the site configuration.  For example if your site document root is /var/www/mysite then the pxp.cgi normally would be in /var/www/mysite/cgi-bin.

Did you ever resolve this issue?

If not make sure your PEM file contains your certificate, certificate chain, and private key. 

You can do a quick test of the PEM file with a small PxPlus program that opens a server port using the PEM then trying to connect to it.  For example:

OPEN (1) "[tcp];8888;secure=path-to-pemfile.pem"
WHILE 1
READ RECORD (1,END=*CONTINUE) R$
IF R$="" PRINT "Connection" ELSE PRINT "Recv'd:",R$
WEND

Then you can try to connect to the program using a web browser specifying the port 8888.

You likely will get a error report on the browser complaining the site name doesn't match the certificate but this will at least confirm the PEM file is correct.

The conf-available sites need to be enabled.

Check out: https://geek-university.com/conf-available-directory/

Generally the -available directory contains sites that CAN be enabled with links place in the conf-enabled directory. 

Note: This is generally used in recent Debian/Ubuntu configurations to make enabling/disabling sites easier and does not exist in all Linux installations.

Oh, there is also a Youtube playlist on Webster+ accessible through the following link:

https://www.youtube.com/playlist?list=PLP2OOVHPpLwx3axRiOnnQXW5M5dDli4Bj

Actually there are a number of videos, including some on setup, available on the forum at:

https://forum1.pvxplus.com/index.php?topic=1206.0

You should not need to change the default message text.  I tried the following on PxPlus V19 and it worked just fine:

->?prm('mx') ! Confirm MX is not set
 0

->msgbox "hello","world","?,Btn1=Help,Btn2=Me,Btn3=Please,3",x$

->?x$
BTN2

What version PxPlus are you using?

Generally "forbidden" means you don't have access to the directory or something is wrong with permissions.

Have you tried the targeted URL directly as opposed to going through the AlaisMatch?

For example:  based of Stephane's examples

Instead of:
  https://www.myserver.com/api/customers

Try accessing the resultant URL of:
  https://www.myserver.com/somefolder/restapi.pxp?route=/customers

Make sure this URL works and doesn't give you an error 404. 

If using Apache you can likely use AliasMatch or RedirectMatch to accomplish this.  Something like:

AliasMatch "^/api/(.*)" "/somefolder/restapi.pxp?route=/$1"

RedirectMatch would let you route to another server.

Using a generic match means you only need to setup one redirection/alias.

Cedric

Glad to have been of assistance ... guess my little grey cells are still of some use.  Hercule Poirot would be pleased. 

If you want URL encoded with UTF-8 then use NATIVE:URL as in the following

->x$=$E9$
->utf8$=cvs(x$,"ASCII:UTF8")
->print cvs(utf8$,"NATIVE:URL")
%C3%A9


Have you tried CVS(string$, "ASCII:UTF8") to convert the data to UTF8?

If you need it HTML encoded, once you have the UTF8 string you can convert it to HTML using CVS(utf8data$, "NATIVE:HTML"); however this will yield é    (You can also use "ASCII:HTML")

->x$="This is test "+$e9$
->utf8$=cvs(x$,"ASCII:UTF8")
->print cvs(utf8$,"NATIVE:HTML")
This is test é

Another possibility might be traffic related.  The system only provides a limited time for the SSL/TLS handshake to complete so if the host server is slow to respond you might get a connection failure.  The connection timeout is there in case you accidentally connect to a non-secure server which is not going to respond to the connection request.

Unfortunately I don't remember what the default timeout value is nor if it is able to be changed.

I would suggest if the error is "failure to connect" you simply retry the request,

Regarding precision, internally numbers are saved as 64 Bit (4 x 16 bit) integers with a precision providing 18 digits.  Older versions only had 48 bits (3 x 16) which only supported 14 digits. The current documentation should refer to 18 digits.

When Pxplus/Providex was originally developed hardware didn't directly support 64 bit math operations thus as hardware matured the language was able to support higher precisions.