4 ms·

Thank you for the link. It contains this tiny gem: a glimpse into a path that CGI applications have not taken: > CGI programs should accept these as command-li

by gioele 11y ago

Thank you for the link. It contains this tiny gem: a glimpse into a path that CGI applications have not taken: > CGI programs should accept these as command-line options, and also if given as the PATH_INFO; for instance, visiting ‘http://example.org/p.cgi/--help’ http://example.org/p.cgi/--help’ in a browser should output the same information as invoking ‘p.cgi --help’ from the command line.

xrstf 11y ago
Wasn't there a massive security issue in PHP a few years back because in some CGI environments, it did in fact accept command line arguments, allowing arbitrary code execution via `php -r "<?php ...` and allowing to view sources via `php -s`?
jzwinck 11y ago
Regardless of CGI, I do advocate writing web services that respond to "GET /help" with a developer-facing synopsis of available routes. Pretty much the same thing.
- LukeShu 11y ago
  I advocate using "OPTIONS /path" for that.
  - deleted 11y ago
    [deleted]
  - jzwinck 11y ago
    That prevents people from loading it with a plain-vanilla web browser. "GET /help" is more accessible, therefore more likely to be used. By humans, I mean.