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.