4 ms·

I think, generally speaking, it’s a PHP standard practice and more broadly a scripting language practice, though it doesn’t really apply to Node. No pre-compil

I think, generally speaking, it’s a PHP standard practice and more broadly a scripting language practice, though it doesn’t really apply to Node. No pre-compiling is required, so you just ship the files. Especially true for anything that offers an Apache module (like mod_php).

remram 4y ago
Ship the files sure, ship the top-level folder not really. Most sites will have a "public" subfolder or equivalent, so the READMEs, scripts, sources etc don't get served. Either way, a professional would remove those files or block them at the HTTP server level.
- chrismeller 4y ago
  Ehhh, I don’t know if I agree that most will have anything.
rbanffy 4y ago
> more broadly a scripting language practice, I can tell you it's not the case with Python.
- chrismeller 4y ago
  Interesting, because that and mod_python were what I was thinking of aside from PHP. What’s the workflow there like?
  - rsynnott 4y ago
    Well, I mean, that might have been somewhat standard practice with mod_python the last time anyone used mod_python, which I would assume was about 15 years ago. Looks like it's been dead since 2010: https://en.wikipedia.org/wiki/Mod_python https://en.wikipedia.org/wiki/Mod_python In practice, I think modern Python webapps usually use WSGI or similar, where you wouldn't be just dumping a bunch of files somewhere.
    - chrismeller 4y ago
      Modern PHP apps also would be using Nginx and phpfpm, but it ends up being the same - copying files over.
      - rsynnott 4y ago
        So the unusual thing about PHP (and, historically, mod_python, and CGI for that matter) is that it's normal to have the code actually under the web server's content directory tree. That is, if your content root is /var/www, then you put your code at /var/www/thing.php, so a deployment involves copying stuff into /var/www, and if the server is misconfigured, going to "https://example.com/thing.php https://example.com/thing.php" will actually show you the code. For, say, Java or Ruby web apps, your code is more likely to live elsewhere (people love to fight over exactly _where_...), and run its own web server; nginx or apache or whatever will then proxy requests to that webserver. No matter how it's configured, you're never going to show the end-user the code, or extraneous files like .gitignore. Python's a bit of a corner-case (or at least it used to be last time I worked with Python webapps about a decade ago); it's customary to use WSGI or similar rather than a proper web server, but the effect is much the same.
        9dev 4y ago
        That is very much not standard practice for PHP since about 10 years by now. Applications have a designated web root directory and an entry point that boots the application - as php is serverless by design - which is sometimes placed inside the web root by convention, but that is neither a requirement nor a security risk. By now, stateful application servers are also powering modern php deployments: They also listen to a socket, and keep parts of the application in memory, next to an event loop.
  - antod 4y ago
    Generally very much like Rails with a running process that could be standalone or with a web server interface module depending traffic or other requirements.
Aeolun 4y ago
I don’t know, my servers are generally configured to serve nothing more than the index.php file and anything in the /public directory. I don’t serve up the entire content repository.

remram 4y ago

Ship the files sure, ship the top-level folder not really. Most sites will have a "public" subfolder or equivalent, so the READMEs, scripts, sources etc don't get served. Either way, a professional would remove those files or block them at the HTTP server level.

chrismeller 4y ago
Ehhh, I don’t know if I agree that most will have anything.

rbanffy 4y ago

> more broadly a scripting language practice, I can tell you it's not the case with Python.

chrismeller 4y ago
Interesting, because that and mod_python were what I was thinking of aside from PHP. What’s the workflow there like?
- rsynnott 4y ago
  Well, I mean, that might have been somewhat standard practice with mod_python the last time anyone used mod_python, which I would assume was about 15 years ago. Looks like it's been dead since 2010: https://en.wikipedia.org/wiki/Mod_python https://en.wikipedia.org/wiki/Mod_python In practice, I think modern Python webapps usually use WSGI or similar, where you wouldn't be just dumping a bunch of files somewhere.
  - chrismeller 4y ago
    Modern PHP apps also would be using Nginx and phpfpm, but it ends up being the same - copying files over.
    - rsynnott 4y ago
      So the unusual thing about PHP (and, historically, mod_python, and CGI for that matter) is that it's normal to have the code actually under the web server's content directory tree. That is, if your content root is /var/www, then you put your code at /var/www/thing.php, so a deployment involves copying stuff into /var/www, and if the server is misconfigured, going to "https://example.com/thing.php https://example.com/thing.php" will actually show you the code. For, say, Java or Ruby web apps, your code is more likely to live elsewhere (people love to fight over exactly _where_...), and run its own web server; nginx or apache or whatever will then proxy requests to that webserver. No matter how it's configured, you're never going to show the end-user the code, or extraneous files like .gitignore. Python's a bit of a corner-case (or at least it used to be last time I worked with Python webapps about a decade ago); it's customary to use WSGI or similar rather than a proper web server, but the effect is much the same.
      - 9dev 4y ago
        That is very much not standard practice for PHP since about 10 years by now. Applications have a designated web root directory and an entry point that boots the application - as php is serverless by design - which is sometimes placed inside the web root by convention, but that is neither a requirement nor a security risk. By now, stateful application servers are also powering modern php deployments: They also listen to a socket, and keep parts of the application in memory, next to an event loop.
- antod 4y ago
  Generally very much like Rails with a running process that could be standalone or with a web server interface module depending traffic or other requirements.

Aeolun 4y ago

I don’t know, my servers are generally configured to serve nothing more than the index.php file and anything in the /public directory. I don’t serve up the entire content repository.