On 04/02/10 23:19, James Bensley wrote:
When a client browses a page on your web server with these tags in the page the web server see's the tags it processes the code before serving the client the page. This is not a native language of a web server or browser.
I've just scanned this thread so apologies if someone already covered this but it seems to be the main point of confusion.
The web server does *not* interpret <?php tags.
What happens is that the web server is told to pass any file with .php extension (or, if you configure it, any file at all, or any file with .php or .html, or ....).
It is then PHP that scans for <?php .. ?> and processes it. If there are no <?php tags in the script, PHP still parses it, but outputs the file exactly as it reads it.
Therefore there doesn't need to be a "standard" for things like this; the standard is to define which parser parses which files, then let the parser do it's job. With a Perl script, the script is run "as is" so it needs to be a valid perl script in itself, from the first line. PHP starts parsing a file as raw output and only processes the sections it needs to, which means it is possible to do simple tasks in PHP very simply (where you have large sections of raw HTML you don't need to use the script language commands to print/echo/write/whatever the HTML to the output).
So, look in the web browser configuration for the lines which tell it which files to send to (eg) PHP, and that's all you need to understand in this context. You can easily show this: create a file which PHP tags in it and save it as a .html file, then view the page in the browser (and "view source") - you'll see the PHP tags in the code that the browser receives. Re-configure the server to parse .html files with PHP, restart the server, then refresh the browser, and you'll see that the code has gone and PHP has parsed it.