[colanderman]

Edited for tone.

> STDIN/STDOUT is an unrestricted protocol.

So are WebSockets.

> Normally when you write a webapp you have a well-tested parser to validate the HTTP request for you

The only HTTP in WebSockets is the handshake, which is what this daemon handles for you.

> and you have safe APIs to access parameters,

There are no "parameters"; WebSockets transport a stream of opaque packets.

> and your templating language auto-escapes dangerous characters for you,

There are no "unsafe characters" in a binary protocol. At best you could claim NUL and LF, the former because it has special meaning to C, and the latter because it's used as a message delimiter by this daemon. The worst either of those will cause is reading less of a message instead of more.

> and the response goes through middleware to prevent XSRF attacks

You have to do this in any language you use. This has nothing to do with communicating via Unix pipes.

> With this, you have to handle all of that in your application binary.

Most HTML parsing engines are available as libraries.

[lelandbatey]

I think you're missing the forest of his argument through the trees of the details you quote.

It's oftentimes really dangerous to expose the raw stdin/stdout to the web. The point is that this by default has none of the usual safeties associated with making a program web-accessible. It's dangerous.

This doesn't make it a bad tool. It just means you need to be aware of the downsides.

[colanderman]

If he said, "it's dangerous to connect a non-Web-aware program to the Internet", I'd agree.

Except he didn't, he said, "Problem is that it requires that the app handle all the security aspects of talking to the Internet", which is not unique to applications using this daemon, or even to applications using WebSockets.

[colanderman]

Woot woot, downvote party! Any of you want to step up and tell me why you think I'm wrong and Nostrademons is right?

[fit2rule]

I'm guess you're getting downvoted not because you are right (I think you're right) but because the tone of your reply is a bit harsh ..

[colanderman]

Thanks for the reply, you are probably right. I've cleaned up the snark. Authoritatively stated incorrect information is somewhat of a pet peeve of mine; my day job often requires that I patiently remediate such information, so I have developed a bit of a short fuse for these things off the job.