Re: How to store the value of a Javascript function as a Perl variable

One final comment that I would make, regarding the OP’s proposed design, is that it is probably not a good idea for the GET/POST to refer to, say, “testScript.cgi,” unless this is the name of the entire web-site. Don’t make the client-side knowledgeable about how the host-side is organized, and particularly, don’t let the JavaScript (nor any “script kiddie”) call whatever it wants to. Instead, send all requests to a single, fairly-opaque URL (say, “mysite.com/api), sending a JSON-formatted request (including some kind of “request name” parameter), and receiving a similar response. Success gets a 200 return-code and a JSON packet; Failure gets 500 and a different, but standard, JSON packet.

For ideas on the server-side, look at RPC::Any::Server. (Whether you literally use that code or not, carefully observe the approach.) It is, at its heart-of-hearts, “a remote procedure-call,” and it should be treated as such. The client may ask the host to do something on its behalf, but should not be permitted to tell the host what to do nor exactly how to do it.

Replies are listed 'Best First'.
Re^2: How to store the value of a Javascript function as a Perl variable by Anonymous Monk on Jun 24, 2014 at 20:13 UTC
Failure gets 500 and a different, but standard, JSON packet. 5xx response codes typically indicate an internal failure of the HTML-server, such as not being able to execute the script. A 4xx error code might be more appropriate, as it indicates that the client made an error in its request. Even better might be a `200 OK` (indicating the script was executed successfully, and didn't `die`) with a custom error status in accordance with the custom protocol in the response. Even if you argue you're free to choose any response code you want, consider the situation where someone attempts to debug a seemingly typical 500 error by checking perms, the shebang line, and all the rest of the usual suspects, only to discover that the script is intentionally faking it. Being an expert on turning around legacy software projects (I take that to mean, fixing other people's mistakes), wouldn't you find that incredibly annoying? For ideas on the server-side, look at RPC::Any::Server. Why are you recommending a module whose one and only release was four years ago and which fails most of its tests? In case you didn't notice, that bug you reported two years ago about that matter hasn't been fixed yet. I suggest you take your own advice and "surf the web to get a better understanding of how the HTTP protocol in-general actually works" (it's like when you drive your car to get a better understanding of how combustion engines actually work, right?), because a mere two months ago you were still confusing HTML with HTTP.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: How to store the value of a Javascript function as a Perl variable
by Anonymous Monk on Jun 24, 2014 at 20:13 UTC

Failure gets 500 and a different, but standard, JSON packet.

5xx response codes typically indicate an internal failure of the HTML-server, such as not being able to execute the script. A 4xx error code might be more appropriate, as it indicates that the client made an error in its request. Even better might be a 200 OK (indicating the script was executed successfully, and didn't die) with a custom error status in accordance with the custom protocol in the response.

Even if you argue you're free to choose any response code you want, consider the situation where someone attempts to debug a seemingly typical 500 error by checking perms, the shebang line, and all the rest of the usual suspects, only to discover that the script is intentionally faking it. Being an expert on turning around legacy software projects (I take that to mean, fixing other people's mistakes), wouldn't you find that incredibly annoying?

For ideas on the server-side, look at RPC::Any::Server.

Why are you recommending a module whose one and only release was four years ago and which fails most of its tests? In case you didn't notice, that bug you reported two years ago about that matter hasn't been fixed yet.

I suggest you take your own advice and "surf the web to get a better understanding of how the HTTP protocol in-general actually works" (it's like when you drive your car to get a better understanding of how combustion engines actually work, right?), because a mere two months ago you were still confusing HTML with HTTP.

[reply]
[d/l]
[select]