Web Programming - nogsantos/study-zce-php-certification-codes GitHub Wiki

A file can be uploaded through a "multi-part" HTTP POST transaction. From the perspective of building your file upload form, this simply means that you need to declare it in a slightly different way:

<form enctype="multipart/form-data" action="index.php" method="post">
   <input type="hidden" name="MAX_FILE_SIZE" value="50000" />
   <input name="filedata" type="file" />
   <input type="submit" value="Send file" />
</form>

The MAX_FILE_SIZE value is used to define the maximum file size allowed (in this case, 50,000 bytes); note, however, that this restriction is almost entirely meaningless, since it sits on the client side—since any moderately crafty attacker will be able to set this parameter to an arbitrary value, you can’t count on it preventing any attempt to overwhelm your system by sending files that are so large as to deplete its resources.

Limit the amount of data uploaded by a POST operation by modifying a number of configuration directives, such as post_max_size, max_input_time and upload_max_filesize.

Once a file is uploaded to the server, PHP stores it in a temporary location and makes it available to the script that was called by the POST transaction (index.php in the example above). It is up to the script to move the file to a safe location if it so chooses—the temporary copy is automatically destroyed when the script ends.

$_FILES superglobal array
The element will, itself, be an array with the following elements:

• name The original name of the file
• type The MIME type of the file provided by the browser
• size The size (in bytes) of the file
• tmp_name The name of the file’s temporary location
• error The error code associated with this file. A value of UPLOAD_ERR_OK indicates a successful transfer, while any other error indicates that something went wrong (for example, the file was bigger than the maximum allowed size).

POST transaction indicates that you intend to modify data (i.e.: you are sending information over to the server).
A GET transaction, on the other hand, indicates that you intend to retrieve data instead.

Turning on compression for any given page is easy, and because the browser’s Accept headers are taken into account, the page is automatically compressed for only those users whose browsers can handle the decompression process:

<?php
ob_start("ob_gzhandler");
?>

Placing this line of code at the top of a page will invoke PHP’s output buffering mechanism, and cause it to transparently compress the script’s output.
You can also enable compression on a site-wide basis by changing a few configuration directives in your php.ini file:

zlib.output_compression = on
zlib.output_compression_level = 9

Notice how this approach lets you set the compression level. Since these settings can be turned on and off without changing your code, this is best way of implementing compression within your application.

<?php
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Thu, 31 May 1984 04:35:00 GMT");
?>

<?php
$date = gmdate("D, j M Y H:i:s", time() + 2592000); // 30 Days from now
header("Expires: " . $date . " UTC");
header("Cache-Control: Public");
header("Pragma: Public");
?>

To set a cookie on the client, you can use the setcookie() function:

<?php
setcookie("hide_menu", "1");
?>

Accessing Cookie Data
Cookie data is usually sent to the server using a single request header. The PHP interpreter takes care of automatically separating the individual cookies from the header and places them in the $_COOKIE superglobal array:

<?php
if ($_COOKIE['hide_menu'] == 1) {
   // hide menu
}
?>

Cookie values must be scalar; of course, you can create arrays using the same array notation that we used for $_GET and $_POST:

<?php
setcookie("test_cookie[0]", "foo");
setcookie("test_cookie[1]", "bar");
setcookie("test_cookie[2]", "bar");
?>

There is no way to "delete" a cookie—primarily because you really have no control over how cookies are stored and managed on the client side. You can, however, call setcookie() with an empty string and a negative timestamp, which will effectively empty the cookie and in most cases the browser will remove it:

<?php
setcookie("hide_menu", false, -3600);
?>

Sessions are started in one of two ways. You can either set PHP to start a new session automatically whenever a request is received by changing the session.auto_start configuration setting in your php.ini file, or explicitly call session_start() at the beginning of each script. Both approaches have their advantages and drawbacks. In particular, when sessions are started automatically, you obviously do not have to include a call to session_start() in every script. However, the session is started before your scripts are executed; this denies you the opportunity to load your classes before your session data is retrieved, and makes storing objects in the session impossible. In addition, session_start() must be called before any output is sent to the browser, because it will try to set a cookie by sending a response header.

In the interest of security, it is a good idea to follow your call to session_start() with a call to session_regenerate_id() whenever you change a user’s privileges to prevent "session fixation" attacks.

Once the session has been started, you can access its data in the $_SESSION super-global array:

<?php
// Set a session variable
$_SESSION['hide_menu'] = true;
// From here on, we can access hide_menu in $_SESSION
if ($_SESSION['hide_menu']) {
   // Hide menu
}
?>