PHP bandwidth (time to load a PHP page) and protection

[Flame_N]

Hello to everyone, I am new to this forum and I hope you guess can answer one or two questions...

 

First I wanted to ask whether the size of the PHP code reflects on the time it takes to load a page? I suppose the only thing that matters is how fast the server will handle your request? I know PHP only returns html code to the client but, if the PHP file is (for an instance) 500KB it doesn't mean that it will load slow? The client only waits for the server to return html right? So... the time it takes to load a page is the time the server needs to handle your request and the time you download the hmtl from it?

 

I wanted to know this so that I could know whether it matters to make big scripts or try to optimize them.

 

Second question. It may sound dumb but, I wanted to hear this from professionals. Can someone see the content of you php file? (I'm pretty sure they don't buy I want to hear people say it  ). However if there is such a way, what should I do for protection against this.

 

[per1os]

You can only see the contents of the file if it is downloaded via FTP or via SSH.

 

As for the size of the script, it does matter little. What does matter is the output. However if you have a lot of processes going on like string manipulation and loops inside that 500KB file that will slow it down because php does have to process etc.

 

Optimization is always good. But yea as long as your php 500KB page does not due insane amounts of logic with loops etc, you should be fine.

[GingerRobot]

The size of the file has no real reflection on the time it will take for the file to load. It depends entirely on what the contents of your php file are. To illustrate this, imagine if you had a loop which was doing something simple but than ran a million times and nothing else in your program, it would take a while to execute, but the file size would be small.

 

As for your second question, no. All a user can see is the output produced by the php file. The only way someone could view your php files would be if they had access to your ftp server. That is, of course, as long as your files are being parsed as php files. Therefore, it is usually not recommended to name files with extensions other than .php - although apache can be configured to parse other file extension types as php files(for example, occasionaly people name files to be included with the extension .inc), its often said to be a security risk if you rely on that.

 

Edit: See i was beaten to it by frost, but two explanations are better than one, right?

[Flame_N]

Thanks for answering so fast guys. I understood your answers completely.

[roopurt18]

I want to add that it is possible for people to view the content of your scripts if you program carelessly.

 

As long as your server is configured correctly, it will be impossible for someone to see your PHP source with a request like:

http://www.yoursite.com/file.php

 

However, let's say you had files in the directory:

/home/usr/downloads/

 

And you had a script downloads.php located at:

/home/usr/public_html/downloads.php

 

downloads.php

<?php
  $fp = fopen("/home/usr/downloads/" . $_GET['file'], "r");
  if($fp){
    // Change headers to reflect the type of file about to be sent
    fpassthru($fp);
    fclose($fp);
    $fp = null;
    exit();
  }else{
    echo "Error opening file";
  }
?>

 

So if you had a file:

/home/usr/downloads/cool_song.mp3

 

Someone may download it with:

http://www.yoursite.com/downloads.php?file=cool_song.mp3

 

However, since your downloads.php fails to properly authenticate requests and determine if a user actually has access to the file, someone could do this:

http://www.yoursite.com/downloads.php?file=../public_html/database_credentials.php

 

Now the file being sent to the person making the request is the PHP file containing your database user name and password.  Since the file is being opened and dumped by the PHP script and not by the web server, the visitor will see the actual file contents.

 

Always authenticate, validate, and filter user input.