7 ms·

Amazing how the old is new again. Welcome back, CGI! I hope everyone's aware that this is just a toy and should never be used to do any real work, because most

by xxchan 13y ago

Amazing how the old is new again. Welcome back, CGI! I hope everyone's aware that this is just a toy and should never be used to do any real work, because most command line tools were never written to be exposed to the internet at large.

baq 13y ago
caveat: real work != internet. cgi is still very useful for those super small internal one-shot scripts.
- danieldk 13y ago
  Well, for some folks it works fine on the internet as well: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02065.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or... tl;dr: sqlite.org and fossil-scm.org run using a simple HTTP server via inetd and some parts of the website are CGI scripts. In 2010 they served over a quarter million requests per day on a tiny VPS with only 3% CPU load.
  - weland 13y ago
    Shhh! You're on Hackernews man...
  - girvo 13y ago
    So I've been curious about this; Nimrod has some SCGI libraries and the like built in, but I didn't know whether that would be good enough for real world usage without building a concurrent application server into my App itself. How does it handle multiple requests at once without impacting performance badly? I know that's a noob question, I struggled to find good information on SCGI/CGI for today's use cases, so I sort of wrote it off as too hard basket...
  - mikeash 13y ago
    I run my entire web site on CGI scripts invoked by Apache. I really don't get the hate for it. It's extremely convenient and works great.
    - ajbetteridge 13y ago
      Same here. And to get the flame bait machine started, we even do it in Perl!
- _ak 13y ago
  CGI (when used with suexec) is still the tool of choice for your usual low-coat shared webhosting provider, and it's still good enough if all your customers want to do is deploy Wordpress, phpBB and maybe some custom PHP and Perl CGI scripts.
lhaussknecht 13y ago
Take a look at how the Leap Motion works. You connect the Leap Motion to your usb port, a demon/service interacts with the Leap Motion and opens a websocket server on localhost so that websites can interact with the hardware device without browser plugins.
- X4 13y ago
  Thanks lhaussknecht That's also what I thought! I don't understand the negativity here! "Oh, this is a toy. Oh, this doesn't meet my Enterprise needs. Oh, this isn't EAL7¹ Certified, I can't run my Atombomb defense system with it." Dear Ladies and Gentlemen, you have to admit that this is ueber useful for so many scenarios, that are out of the box, you're thinking in. I can now hack a firebase clone, just for fun and my prototypes don't require the setup of dozens or a hundred npm packages. Besides the coolness of NodeJS, there are still some use-cases for hackers with this. -- 1. http://en.wikipedia.org/wiki/Evaluation_Assurance_Level#EAL7:_Formally_Verified_Design_and_Tested http://en.wikipedia.org/wiki/Evaluation_Assurance_Level#EAL7...
fit2rule 13y ago
Whats so toy-like about this? Its no toy but rather a useful method of tying differing software systems together .. I can think of many productive uses for this.
- nostrademons 13y ago
  Problem is that it requires that the app handle all the security aspects of talking to the Internet, because STDIN/STDOUT is an unrestricted protocol. Normally when you write a webapp you have a well-tested parser to validate the HTTP request for you, and you have safe APIs to access parameters, and your templating language auto-escapes dangerous characters for you, and the response goes through middleware to prevent XSRF attacks, and the whole thing is written in a safe language where there's no possibility of buffer overruns. With this, you have to handle all of that in your application binary. You can certainly do this. However, if you are asking why you need to do this, you are almost certainly not ready to do this. I agree that this is a pretty useful method of tying software systems together. However, one of the the systems you're tying together is the public Internet, where all sorts of danger lurks. Writing secure parsers is hard. I've written an HTML parser [1], one of the most well-tested ones out there (I spent the better part of a year doing nothing but testing & debugging, and ran literally billions of documents through it), and Google's security team still found 2 bugs in it with about a day's work. [1] https://github.com/google/gumbo-parser https://github.com/google/gumbo-parser
  - acqq 13y ago
    nostrademons's comment is for me the most important comment here in this discussion. Thanks nostrademons! Just as an illustration, from the linked page: "Security. Gumbo was initially designed for a product that worked with trusted input files only. We're working to harden this and make sure that it behaves as expected even on malicious input, but for now, Gumbo should only be run on trusted input or within a sandbox."
    - bct 13y ago
      That's an issue with this implementation, not the idea of hooking up stdin/stdout to websockets.
asb 13y ago
The first thing that came to my mind was djb's tcpserver which as far as I can see does much the same thing http://cr.yp.to/ucspi-tcp/tcpserver.html http://cr.yp.to/ucspi-tcp/tcpserver.html
- gwu78 13y ago
  tcpserver does not pipe input. It sets certain environmental variables, closes fd's 0 and 1 and runs another command line program. It has no quivalent to QUERY_STRING. Very different from CGI or this Websocket contraption. Much safer. But the parent says that "most command line tools were never written to be exposed to the internet at large", and tcpserver is a command line tool that runs other command line tools, so is tcpserver OK to use for "real work" by his standards? Maybe we should use a GUI tool "written to be exposed to the internet at large"?
pmelendez 13y ago
CGI won't maintain an open connection though
sciurus 13y ago
27 years since inetd came into being, and now we've made it web-scale. ;-) http://en.wikipedia.org/wiki/Inetd http://en.wikipedia.org/wiki/Inetd I actually don't mean to be snarky, this program acknowledges its heritage and is a cool hack!

by xxchan 13y ago

baq 13y ago

caveat: real work != internet. cgi is still very useful for those super small internal one-shot scripts.

danieldk 13y ago
Well, for some folks it works fine on the internet as well: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02065.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or... tl;dr: sqlite.org and fossil-scm.org run using a simple HTTP server via inetd and some parts of the website are CGI scripts. In 2010 they served over a quarter million requests per day on a tiny VPS with only 3% CPU load.
- weland 13y ago
  Shhh! You're on Hackernews man...
- girvo 13y ago
  So I've been curious about this; Nimrod has some SCGI libraries and the like built in, but I didn't know whether that would be good enough for real world usage without building a concurrent application server into my App itself. How does it handle multiple requests at once without impacting performance badly? I know that's a noob question, I struggled to find good information on SCGI/CGI for today's use cases, so I sort of wrote it off as too hard basket...
- mikeash 13y ago
  I run my entire web site on CGI scripts invoked by Apache. I really don't get the hate for it. It's extremely convenient and works great.
  - ajbetteridge 13y ago
    Same here. And to get the flame bait machine started, we even do it in Perl!
_ak 13y ago
CGI (when used with suexec) is still the tool of choice for your usual low-coat shared webhosting provider, and it's still good enough if all your customers want to do is deploy Wordpress, phpBB and maybe some custom PHP and Perl CGI scripts.

lhaussknecht 13y ago

Take a look at how the Leap Motion works. You connect the Leap Motion to your usb port, a demon/service interacts with the Leap Motion and opens a websocket server on localhost so that websites can interact with the hardware device without browser plugins.

X4 13y ago
Thanks lhaussknecht That's also what I thought! I don't understand the negativity here! "Oh, this is a toy. Oh, this doesn't meet my Enterprise needs. Oh, this isn't EAL7¹ Certified, I can't run my Atombomb defense system with it." Dear Ladies and Gentlemen, you have to admit that this is ueber useful for so many scenarios, that are out of the box, you're thinking in. I can now hack a firebase clone, just for fun and my prototypes don't require the setup of dozens or a hundred npm packages. Besides the coolness of NodeJS, there are still some use-cases for hackers with this. -- 1. http://en.wikipedia.org/wiki/Evaluation_Assurance_Level#EAL7:_Formally_Verified_Design_and_Tested http://en.wikipedia.org/wiki/Evaluation_Assurance_Level#EAL7...

fit2rule 13y ago

Whats so toy-like about this? Its no toy but rather a useful method of tying differing software systems together .. I can think of many productive uses for this.

nostrademons 13y ago
Problem is that it requires that the app handle all the security aspects of talking to the Internet, because STDIN/STDOUT is an unrestricted protocol. Normally when you write a webapp you have a well-tested parser to validate the HTTP request for you, and you have safe APIs to access parameters, and your templating language auto-escapes dangerous characters for you, and the response goes through middleware to prevent XSRF attacks, and the whole thing is written in a safe language where there's no possibility of buffer overruns. With this, you have to handle all of that in your application binary. You can certainly do this. However, if you are asking why you need to do this, you are almost certainly not ready to do this. I agree that this is a pretty useful method of tying software systems together. However, one of the the systems you're tying together is the public Internet, where all sorts of danger lurks. Writing secure parsers is hard. I've written an HTML parser [1], one of the most well-tested ones out there (I spent the better part of a year doing nothing but testing & debugging, and ran literally billions of documents through it), and Google's security team still found 2 bugs in it with about a day's work. [1] https://github.com/google/gumbo-parser https://github.com/google/gumbo-parser
- acqq 13y ago
  nostrademons's comment is for me the most important comment here in this discussion. Thanks nostrademons! Just as an illustration, from the linked page: "Security. Gumbo was initially designed for a product that worked with trusted input files only. We're working to harden this and make sure that it behaves as expected even on malicious input, but for now, Gumbo should only be run on trusted input or within a sandbox."
  - bct 13y ago
    That's an issue with this implementation, not the idea of hooking up stdin/stdout to websockets.

asb 13y ago

The first thing that came to my mind was djb's tcpserver which as far as I can see does much the same thing http://cr.yp.to/ucspi-tcp/tcpserver.html http://cr.yp.to/ucspi-tcp/tcpserver.html

gwu78 13y ago
tcpserver does not pipe input. It sets certain environmental variables, closes fd's 0 and 1 and runs another command line program. It has no quivalent to QUERY_STRING. Very different from CGI or this Websocket contraption. Much safer. But the parent says that "most command line tools were never written to be exposed to the internet at large", and tcpserver is a command line tool that runs other command line tools, so is tcpserver OK to use for "real work" by his standards? Maybe we should use a GUI tool "written to be exposed to the internet at large"?

pmelendez 13y ago

CGI won't maintain an open connection though

sciurus 13y ago

27 years since inetd came into being, and now we've made it web-scale. ;-) http://en.wikipedia.org/wiki/Inetd http://en.wikipedia.org/wiki/Inetd I actually don't mean to be snarky, this program acknowledges its heritage and is a cool hack!